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

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

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!

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.

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.

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)...

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.

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

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.

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? ...