Thread overview | |||||||||||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
|
June 29, 2018 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 |
June 29, 2018 Re: A Case for Oxidation: A potential missed opportunity for D | ||||
---|---|---|---|---|
| ||||
Posted in reply to Mike Franklin | 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 |
June 29, 2018 Re: A Case for Oxidation: A potential missed opportunity for D | ||||
---|---|---|---|---|
| ||||
Posted in reply to Mike Franklin | 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!
|
June 29, 2018 Re: A Case for Oxidation: A potential missed opportunity for D | ||||
---|---|---|---|---|
| ||||
Posted in reply to Radu | 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.
|
June 29, 2018 Re: A Case for Oxidation: A potential missed opportunity for D | ||||
---|---|---|---|---|
| ||||
Posted in reply to kinke | 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.
|
June 29, 2018 Re: A Case for Oxidation: A potential missed opportunity for D | ||||
---|---|---|---|---|
| ||||
Posted in reply to kinke | 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)...
|
June 29, 2018 Re: A Case for Oxidation: A potential missed opportunity for D | ||||
---|---|---|---|---|
| ||||
Posted in reply to rikki cattermole | 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.
|
June 29, 2018 Re: A Case for Oxidation: A potential missed opportunity for D | ||||
---|---|---|---|---|
| ||||
Posted in reply to kinke | 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 |
June 29, 2018 Re: A Case for Oxidation: A potential missed opportunity for D | ||||
---|---|---|---|---|
| ||||
Posted in reply to kinke | 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.
|
June 29, 2018 Re: A Case for Oxidation: A potential missed opportunity for D | ||||
---|---|---|---|---|
| ||||
Posted in reply to rikki cattermole | 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? ...
|
Copyright © 1999-2021 by the D Language Foundation