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!
