Re: A Case for Oxidation: A potential missed opportunity for D
On Friday, 29 June 2018 at 09:25:08 UTC, Mike Franklin wrote: Please allow me to bring your attention to an interesting presentation about choosing a modern programming language for writing operating systems: https://www.youtube.com/watch?v=cDFSrVhnZKo It's a good talk and probably worth your time if you're interested in bare-metal systems programming. The presenter mentions D briefly in the beginning when he discussed how he made his choice of programming language. He shows the following (probably inaccurate) matrix. Lang| Mem Safety | Min Runtime | Strong Type Syst. | Performance C || x | | x C++ || x | | x C# | x | | x | D | x | | x | x Go | x | | x | x Rust| x | x | x | x Java| x | | x | x Haskell | x | | x | Cycle | x | x | x | x It appears the deal-breaker for D was the lack of "minimal runtime". Of course D has -betterC and, with 2.079, a way to use some features of D without the runtime, but he also goes on to discuss the importance of memory safety in his application of the language. I hope we'll see something competitive with DIP25, DIP1000, and the `scope` storage class, namely *memory safety without a runtime*. I'm currently waiting for 2.081 to reach LDC and GDC, and then I have a few ideas I'd like to begin working on myself, but I never have a shortage of ideas, just a shortage of time and energy. Enjoy! Mike This just isn't true. I've written a fair amount of a linux distro in D without druntime/phobos or even the standard C library. https://github.com/marler8997/maros
Re: A Case for Oxidation: A potential missed opportunity for D
On 2018-06-29 12:55, kinke wrote: I'd love to hear some reasons for -betterC from a competent guy like yourself. I simply don't get what all the fuzz is about and what people expect to gain from losing druntime (and language features depending on it) and non-template-only Phobos. I understand the separate 'minimal runtime' need for bare metal (no Type- and ModuleInfos etc.), but I can't help myself in seeing betterC as, nicely put, worseD. I acknowledge that it seems to attract wide-spread interest, and I'd like to understand why. You can potentially do a lot at compile time (which you cannot do in C or C++) while at the same time have a requirement of not using a runtime. There's a talk, I think at a Dconf, where the speaker was using D on bare metal. He used CTFE to parse a PDF file with the specification for op codes or something similar. The CTFE code generate some table or other code for the op codes. This resulted in the code always being up to date with the specification. I've written a tiny plugin for an application where I used a tiny part of the D runtime. I didn't link with it but instead inlined the functions I needed directly in the plugin. For example, array copying. There are several nice features that can be used without the runtime, like: * Strings and arrays carry their length * foreach * Array slicing * Compile time features -- /Jacob Carlborg
Re: A Case for Oxidation: A potential missed opportunity for D
On Friday, 29 June 2018 at 11:47:51 UTC, Jonathan M Davis wrote: However, if you're trying to use D from a C or C++ application, the fact that you have to deal with starting up and shutting down druntime definitely causes problems. Good point, thanks.
Re: A Case for Oxidation: A potential missed opportunity for D
On Friday, 29 June 2018 at 11:31:17 UTC, Radu wrote: There technical and political reason here. BetterC offers a clean no-overhead strictly enforced subset of the language. This is great for porting over existing C code base and also for creating equivalent libs in D but without worrying that you carry over baggage from the D run-time. It also serves as a good tire 1 target when porting D to other platforms. WebAssembly is one of those odd platforms were D could shine, and having betterC greatly easy the effort of porting it over (even though so far nobody stepped out to do this). C is a beast and its hardcore programmers will not touch anything that has typeinfo, gc or classes. Selling betterC to them (this includes teammates) is a lot easier, you can show them the assembly on godblot.org and they see no extra fat is added. @safe is the added bonus and the final nail in the coffin to ditch C. But ultimately betterC is also a sign of the design failure on both dlang and druntime in the way that it wasn't conceived to be modular and easier to use in a pay-as-you-go fashion. Until the GC and typeinfo is truly optional and reserved only for the top layers of the standard library betterC is the best we have. Okay, thanks for the rationale. If it's mainly about Type-/ModuleInfos bloat and the GC, the compiler fed with -betterC could also * continue to elide the Type-/ModuleInfo emission, * additionally error out on all implicit druntime calls to the GC, * still link in druntime and Phobos. That should make more things work, incl. the above slice copy and (manually allocated) extern(C++) classes.
Re: A Case for Oxidation: A potential missed opportunity for D
and non-template-only Phobos.
unless they are using betterC (undefined reference to
'_d_arraycopy')?
Are you sure about this?
//flags: -betterC -noboundscheck
extern(C):
void main()
{
import core.stdc.stdlib;
int[] x = ( cast(int*) malloc( int.sizeof * 10 ) )[0 .. 10];
int[] y = ( cast(int*) malloc( int.sizeof * 10 ) )[0 .. 10];
import std.algorithm : map;
x.map!( x => x * 2 );
x[] = y[];
}
//compiles and works ok.
Re: A Case for Oxidation: A potential missed opportunity for D
On 29/06/2018 11:36 PM, kinke wrote: On Friday, 29 June 2018 at 11:24:52 UTC, rikki cattermole wrote: It is a language feature yes, and it doesn't define /how/ it gets implemented. That's besides my actual point though (and I haven't even mentioned missing class support, which is everything but helping with developing against existing C++ codebases). It was besides mine as well. My question is: what do people expect to gain by not linking in druntime and Phobos? Is there a feeling the binaries are unnecessarily bloated (-> minimal runtime)? Is it making cross-compilation harder (LDC has the ldc-build-runtime tool for that)? Is it the cozy feeling that the GC won't used at all? ... Simple, it isn't there to prevent technical issues, it is to remove mental barriers. There is a field dedicated to researching this, called Human Computer Interaction (HCI) and so far, it seems to have been what was needed for its users. You and I do not suffer this block. But many do, and it is as hard and concrete to them as not having actual proper shared library support is to me.
Re: A Case for Oxidation: A potential missed opportunity for D
On Friday, June 29, 2018 10:55:27 kinke via Digitalmars-d wrote: > On Friday, 29 June 2018 at 10:00:09 UTC, Radu wrote: > > While not necessarily targeting bare metal, I'm very interested > > in a working version of @safe dlang. I believe that dlang with > > betterC, @safe, C/C++ inter-op and dip1000 will be huge for > > replacing C/C++. > > I'd love to hear some reasons for -betterC from a competent guy > like yourself. I simply don't get what all the fuzz is about and > what people expect to gain from losing druntime (and language > features depending on it) and non-template-only Phobos. I > understand the separate 'minimal runtime' need for bare metal (no > Type- and ModuleInfos etc.), but I can't help myself in seeing > betterC as, nicely put, worseD. I acknowledge that it seems to > attract wide-spread interest, and I'd like to understand why. I completely agree that -betterC means -worseD, and in general, I see no reason to mess with it if I can avoid it. However, if you're trying to use D from a C or C++ application, the fact that you have to deal with starting up and shutting down druntime definitely causes problems (as does the GC - not because of performance but due to the fact that you then have non-D code interacting with GC-allocated memory, and that gets complicated). It's far easier to have C/C++ code call D code that has a C API and doesn't require an additional runtime. The result is definitely worse than just using D, but if you're stuck with having C/C++ and are trying to use D from within that environment, -betterC gives you a way. I'm honestly not sure that using a stripped down D is enough better than using C/C++ to be worth it (especially if you're stuck using D like C when you could be using C++ instead), but there's certainly an argument to be made for it. The other place that -betterC has real value is when porting a C/C++ application to D. By porting portions of it to -betterC, you can do the porting piecemeal, and then once the porting is complete, you can ditch -betterC and use proper D. In contrast, if you tried to go straight to full-on D, you tend to have to port large portions of the program at a time (perhaps even the entire thing), which is much harder to do. In such a case, -betterC is really just a stepping stone and not something that you'd want to use normally. However, if you don't need to hook D into an existing C/C++ application (be it to add functionality or to actually port the code), then personally, I think that -betterC is definitely just -worseD and an utter waste of time. But some folks (especially those who are really biased against the GC) do seem to leap at the idea as if it fixes D. - Jonathan M Davis
Re: A Case for Oxidation: A potential missed opportunity for D
On Friday, 29 June 2018 at 11:24:52 UTC, rikki cattermole wrote: It is a language feature yes, and it doesn't define /how/ it gets implemented. That's besides my actual point though (and I haven't even mentioned missing class support, which is everything but helping with developing against existing C++ codebases). My question is: what do people expect to gain by not linking in druntime and Phobos? Is there a feeling the binaries are unnecessarily bloated (-> minimal runtime)? Is it making cross-compilation harder (LDC has the ldc-build-runtime tool for that)? Is it the cozy feeling that the GC won't used at all? ...
Re: A Case for Oxidation: A potential missed opportunity for D
On Friday, 29 June 2018 at 10:55:27 UTC, kinke wrote: On Friday, 29 June 2018 at 10:00:09 UTC, Radu wrote: While not necessarily targeting bare metal, I'm very interested in a working version of @safe dlang. I believe that dlang with betterC, @safe, C/C++ inter-op and dip1000 will be huge for replacing C/C++. I'd love to hear some reasons for -betterC from a competent guy like yourself. I simply don't get what all the fuzz is about and what people expect to gain from losing druntime (and language features depending on it) and non-template-only Phobos. I understand the separate 'minimal runtime' need for bare metal (no Type- and ModuleInfos etc.), but I can't help myself in seeing betterC as, nicely put, worseD. I acknowledge that it seems to attract wide-spread interest, and I'd like to understand why. There technical and political reason here. BetterC offers a clean no-overhead strictly enforced subset of the language. This is great for porting over existing C code base and also for creating equivalent libs in D but without worrying that you carry over baggage from the D run-time. It also serves as a good tire 1 target when porting D to other platforms. WebAssembly is one of those odd platforms were D could shine, and having betterC greatly easy the effort of porting it over (even though so far nobody stepped out to do this). C is a beast and its hardcore programmers will not touch anything that has typeinfo, gc or classes. Selling betterC to them (this includes teammates) is a lot easier, you can show them the assembly on godblot.org and they see no extra fat is added. @safe is the added bonus and the final nail in the coffin to ditch C. But ultimately betterC is also a sign of the design failure on both dlang and druntime in the way that it wasn't conceived to be modular and easier to use in a pay-as-you-go fashion. Until the GC and typeinfo is truly optional and reserved only for the top layers of the standard library betterC is the best we have.
Re: A Case for Oxidation: A potential missed opportunity for D
On 29/06/2018 11:17 PM, kinke wrote:
On Friday, 29 June 2018 at 11:04:30 UTC, rikki cattermole wrote:
It greatly simplifies development against existing C/C++ codebases.
How so? By telling people you can express C++:
void cpy(char *dst, const char *src, size_t size)
{
for (size_t i; i < size; ++i)
dst[i] = src[i];
}
elegantly and safe like this in D:
void cpy(void[] dst, void[] src) { dst[] = src[]; }
unless they are using betterC (undefined reference to '_d_arraycopy')?
Just to highlight one lost language feature.
It is a language feature yes, and it doesn't define /how/ it gets
implemented.
In fact the spec[0][1] implies that it generates highly optimized
assembly, not go and call a function.
[0] https://dlang.org/spec/simd.html
[1] https://dlang.org/spec/arrays.html#array-copying
Re: A Case for Oxidation: A potential missed opportunity for D
On Friday, 29 June 2018 at 11:04:30 UTC, rikki cattermole wrote:
It greatly simplifies development against existing C/C++
codebases.
How so? By telling people you can express C++:
void cpy(char *dst, const char *src, size_t size)
{
for (size_t i; i < size; ++i)
dst[i] = src[i];
}
elegantly and safe like this in D:
void cpy(void[] dst, void[] src) { dst[] = src[]; }
unless they are using betterC (undefined reference to
'_d_arraycopy')? Just to highlight one lost language feature.
Re: A Case for Oxidation: A potential missed opportunity for D
On 29/06/2018 10:55 PM, kinke wrote: On Friday, 29 June 2018 at 10:00:09 UTC, Radu wrote: While not necessarily targeting bare metal, I'm very interested in a working version of @safe dlang. I believe that dlang with betterC, @safe, C/C++ inter-op and dip1000 will be huge for replacing C/C++. I'd love to hear some reasons for -betterC from a competent guy like yourself. I simply don't get what all the fuzz is about and what people expect to gain from losing druntime (and language features depending on it) and non-template-only Phobos. I understand the separate 'minimal runtime' need for bare metal (no Type- and ModuleInfos etc.), but I can't help myself in seeing betterC as, nicely put, worseD. I acknowledge that it seems to attract wide-spread interest, and I'd like to understand why. It greatly simplifies development against existing C/C++ codebases. To some people (for their given use cases) this can be a very good thing. Removing barriers for adoption is a very noble but more importantly wise thing to do, and we should all aim to do it.
Re: A Case for Oxidation: A potential missed opportunity for D
On Friday, 29 June 2018 at 10:55:27 UTC, kinke wrote: Phobos. I understand the separate 'minimal runtime' need for bare metal (no Type- and ModuleInfos etc.), but I can't help myself in seeing betterC as, nicely put, worseD. I acknowledge I *completely* agree. However, I have nothing against betterC as long as people like me, who do enterprise software, are guaranteed to see "-betterD" option (here I actually mean - as long as the "regular" D is improving)...
Re: A Case for Oxidation: A potential missed opportunity for D
On Friday, 29 June 2018 at 10:00:09 UTC, Radu wrote: While not necessarily targeting bare metal, I'm very interested in a working version of @safe dlang. I believe that dlang with betterC, @safe, C/C++ inter-op and dip1000 will be huge for replacing C/C++. I'd love to hear some reasons for -betterC from a competent guy like yourself. I simply don't get what all the fuzz is about and what people expect to gain from losing druntime (and language features depending on it) and non-template-only Phobos. I understand the separate 'minimal runtime' need for bare metal (no Type- and ModuleInfos etc.), but I can't help myself in seeing betterC as, nicely put, worseD. I acknowledge that it seems to attract wide-spread interest, and I'd like to understand why.
Re: A Case for Oxidation: A potential missed opportunity for D
On Friday, 29 June 2018 at 09:25:08 UTC, Mike Franklin wrote: Please allow me to bring your attention to an interesting presentation about choosing a modern programming language for writing operating systems: https://www.youtube.com/watch?v=cDFSrVhnZKo It's a good talk and probably worth your time if you're interested in bare-metal systems programming. The presenter mentions D briefly in the beginning when he discussed how he made his choice of programming language. He shows the following (probably inaccurate) matrix. Lang| Mem Safety | Min Runtime | Strong Type Syst. | Performance C || x | | x C++ || x | | x C# | x | | x | D | x | | x | x Go | x | | x | x Rust| x | x | x | x Java| x | | x | x Haskell | x | | x | Cycle | x | x | x | x It appears the deal-breaker for D was the lack of "minimal runtime". Of course D has -betterC and, with 2.079, a way to use some features of D without the runtime, but he also goes on to discuss the importance of memory safety in his application of the language. I hope we'll see something competitive with DIP25, DIP1000, and the `scope` storage class, namely *memory safety without a runtime*. I'm currently waiting for 2.081 to reach LDC and GDC, and then I have a few ideas I'd like to begin working on myself, but I never have a shortage of ideas, just a shortage of time and energy. Enjoy! Mike While not necessarily targeting bare metal, I'm very interested in a working version of @safe dlang. I believe that dlang with betterC, @safe, C/C++ inter-op and dip1000 will be huge for replacing C/C++. Not long ago I tried to create a library in dlang that is coded betterC and @safe. The idea is to have the library core in dlang and automatically generated C and C++ wrappers at compile time for allowing the library to be used from those languages or others capable to link to the C API. Unfortunately bugs in betterC and dip1000 stopped progress (most of where fixed already). So waiting for LDC to catch up and give it a try again. Also looking fwd to be able to use C++ classes in betterC. I think if my library, or others, can make it, we could have a strong showcase on why dlang is better on so many levels. The key is focusing on fixing betterC and @safe (dip1000) and keep quality standards high. I think you did a great job already in fixing many of the issues, so thanks!
Re: A Case for Oxidation: A potential missed opportunity for D
On Friday, 29 June 2018 at 09:25:08 UTC, Mike Franklin wrote: He shows the following (probably inaccurate) matrix. Sorry, I messed up typing out that matrix. Here are a few corrections, but you can just see the real think the video here: https://youtu.be/cDFSrVhnZKo?t=260 Lang| Mem Safety | Min Runtime | Strong Type Syst. | Performance C || x | | x C++ || x | | x C# | x | | x | D | x | | x | x Go | x | | | x Nim | x | | x | x Rust| x | x | x | x Java| x | | x | x Haskell | x | | x | Cyclone | x | x | x | x Mike
A Case for Oxidation: A potential missed opportunity for D
Please allow me to bring your attention to an interesting presentation about choosing a modern programming language for writing operating systems: https://www.youtube.com/watch?v=cDFSrVhnZKo It's a good talk and probably worth your time if you're interested in bare-metal systems programming. The presenter mentions D briefly in the beginning when he discussed how he made his choice of programming language. He shows the following (probably inaccurate) matrix. Lang| Mem Safety | Min Runtime | Strong Type Syst. | Performance C || x | | x C++ || x | | x C# | x | | x | D | x | | x | x Go | x | | x | x Rust| x | x | x | x Java| x | | x | x Haskell | x | | x | Cycle | x | x | x | x It appears the deal-breaker for D was the lack of "minimal runtime". Of course D has -betterC and, with 2.079, a way to use some features of D without the runtime, but he also goes on to discuss the importance of memory safety in his application of the language. I hope we'll see something competitive with DIP25, DIP1000, and the `scope` storage class, namely *memory safety without a runtime*. I'm currently waiting for 2.081 to reach LDC and GDC, and then I have a few ideas I'd like to begin working on myself, but I never have a shortage of ideas, just a shortage of time and energy. Enjoy! Mike
