I had always assumed (perhaps naively) that not many people used D and that it was a bit esoteric…? Not to offend anyone. Kind of like F.
Should developers be investing time into learning D?
Are there specific parts of the ecosystem you worry about not being mature?
As for it being a bit esoteric, yes, it's not a very widely known language, though I'm not sure why. I fell in love with it in 2018, and it has thoroughly spoiled me for writing C.
It will just plain copy certain types on assignment though so perhaps that's what you meant.
On a more serious note, I’m skeptical D would take. It seems like Rust has captured mind share and already has ongoing substantial work integrating it into the kernel (+ it’s the first and only non C language in kernel mainline). Given that context, I don’t see the motivation that works spur a similar level of support from kernel maintainers.
Dlang has had significant work poured into it, and the project has delivered a quality language with safety in mind. I don't mean to be defensive, but these threads always seem to ask the same question, it's boring at this point.
Naturally the whole issue is that there is no big movement regarding writing OSes in D for that to matter anyway.
Better luck using TinyGo, Java, .NET or Oberon in bare metal workloads (where runtime plays the OS role), as there are a couple of products for them, than D.
This implies comparing them, so I understand your point now.
D has had "dcompute" since 2017, for native execution on GPUs and other accelerators. People have been writing D for microcontrollers since at least 2011, possibly earlier. D is fairly mature in the systems space.
> I’m skeptical D would take.
Maybe, maybe not. Some languages "click" better than others for individual programmers. It's good to have options.
> it’s the first and only non C language in kernel mainline
Do you foresee it being the only non-C language used in the kernel forever?
It's possible that maybe the maintainers are just trying out Rust to see if it can be wrangled into the kernel to start the migration process. So now may be the right time to explore other languages.
Once a next language is "chosen" then yes, I do think that there will be only 1 language for the kernel itself (modulo the very long transition time to convert all components so you'll have C + 1 other language). I wouldn't be surprised if at some point the kernel decided they're not going to accept any more C drivers because driver code is a lot more variable in quality and lower in oversight and testing. Core kernel code will take a longer time as even now that's out-of-scope for most such efforts.
Do you see it differently?
The first one (syntax similarity to the C programming language) is obviously a valid reason to prefer D over Rust for Linux kernel programming (which mostly uses a dialect of C). The other two (interoperability with C programs and high performance generated code) are a necessity for a programming language to be considered for Linux kernel programming (and Rust scores highly on both). So the first criteria would favor D, while the other two would be neutral between D and Rust.
(There probably are other criteria, outside these three, which favor Rust over D, given that Rust support has already been tentatively merged into the Linux kernel.)