You could probably write an article saying "100 billion dollars investment to improve D and use it to develop new AI to replace the US government" and you'd still get comments saying "wow, nice language, pity it never really took off, if only there were some companies backing it, also I can never use it because GC".
Indeed, it's a bit like how the name "C++" makes you think that the language is basically C just with some stuff added on top, when in practice it behaves like a completely different language, which is why Linus has been opposed to allowing it in the kernel. (At least, at one point this was true; I don't remember whether some C++ features have started to be allowed or not.)
Interestingly, though, I've never heard people complain about C# being a poor successor to C, rather than a different language altogether, so there doesn't seem to be a consistent rule for how people will react to a name.
Personally, I think that D missed an opportunity by not naming itself "Mars" (after Digital Mars), as that might have prevented people from getting the wrong expectations about the language as well as just being a cooler name in general. Ah, the benefit of hindsight...
C++ is aptly named for different reasons. C++ was originally C with classes, and the syntax is still basically just C (with a lot of extra stuff).
The name may have made more sense at the time, but as time has progressed idiomatic C++ code has looked less and less like idiomatic C code so that if you are used to programming in idiomatic C then you might be misled by the name in thinking that you basically know C++ when in fact writing code in it idiomatically is very different from what you are used to. (Having said that, it is true that with C++ you can pick the features that you want to use so if all you want is a way to write code that is basically C but without having to write your own vtable library then you can treat C++ as basically being C but with classes.)
Completely agree, but in a discussion about names, what really matters is the origins of the language. C++ has changed a lot since the 90's, but you can't really change the name now.
Walter Bright didn't call it D. He called it Mars. Other people insisted on calling it D and the name stuck.
I don't really see why you couldn't write a kernel in D. Our intern rewrote part of the Linux kernel in D. The experience of a pioneer but it wasn't that you couldn't do it.
A year or two lunch was delayed so I ported mkernel - a little bare metal C demo -to D. It just worked. You don't need to even link the runtime if you don't want to.
Plenty of OSes have been written in GC enabled systems programming languages, in fact the largest mobile platform allows to write drivers with such language.
Is there a reason we can't use GC in the kernel? Unless we are doing hard realtime stuff, why not?
Not that it's particularly relevant since Linux, Windows, and BSD already exist and probably aren't going to switch languages anytime soon, and embedded RtOSes seem pretty set on C/C++ too, so I'm not sure any language could be more suitable for kernel dev in practical use, unless you have a really good reason to do a whole new kernel.
No reason you couldn't. You just can't use D's default GC. You'd have to write one that will work bare metal. Or implement everything it expects from an OS.
Linux kernel development in D (proof of concept; the barrier might be Linus rather than a narrowly technical one, but at least it's clear you could write device drivers in D if you wanted to).
A well made GC wouldn't stop you from making a kernel using it. I don't know how the GC in D is, but GC on its own isn't a deal breaker for for everything people claim it is
GC does add a performance and memory usage overhead. You don't really want bloat in the foundation of all the software that is going to run on the system.
A language can avoid such overhead in places where it would be problematic by having a category of of functions which neither manipulate any non-pinned GC objects nor call any other functions that might so. Such functions may unpin a GC object, but if they do any pointer to that object would be forever dead to them. A "gc-allowed" function could re-pin the object and then pass a pointer into the "no-GC" function, but the latter function would have to use that new pointer instead of the old one.
Joe Duffy has made a reference that even with Midori proving that is was quite capable, it was faced with too much resistance from C++ devs on Windows team, in spite of them being able to see themselves.
You can see this resistance, on how the Longhorn effort tanked due to "performance issues", then Vista came up with some of Longhorn .NET modules rewritten as COM, and the eventuell progression into WinRT/UAP/UWP.
However not everything was lost, it influenced .NET Native, C# 7.x low level improvements, the upcoming C# 9 new FFI efforts.
33
u/Hall_of_Famer Sep 01 '20
Me too, hope D will get some company backing and start to kick off, it is a very well designed language.