Walter Bright wrote:
bearophile wrote:
Walter Bright:
But I can say that D is already not the best language to develop
non-toy
operating systems.
Why?
I have not written an OS yet, so I can't be sure. But from what I have
read
and seen D seems designed for different purposes, mostly as a
high-performance low-level application language that currently is
programmed
in a style that doesn't assume a very efficient GC.
I'd rephrase that as D supports many different styles. One of those
styles is as a "better C".
D has many features that are useless or negative if you want to write
code
close to the metal as a kernel, as classes, virtual functions, garbage
collector, operator overloading, interfaces, exceptions and
try-catch-finally
blocks, closures, references, delegates, nested functions and structs,
array
concat, built-in associative arrays, monitor, automatic destructors.
When you
write code close to the metal you want to know exactly what your code is
doing, so all the automatic things or higher level things become
useless or
worse, they keep you from seeing what the hardware is actually doing.
I agree on those points. Those features would not be used when using D
as a "better C".
So, you could ask why not use C++ as a "better C" and eschew the C++
features that cause trouble for kernel dev? The answer is that C++
doesn't offer much over C that does not involve those trouble causing
features.
D, on the other hand, offers substantial and valuable features not
available in C or C++ that can be highly useful for kernel dev. Read on.
On the other hand current D language (and C and C++) lacks other
hard-to-implement features that allow the kernel programmer to give more
semantics to the code. So such semantics has to be expressed through
normal
coding. Future languages maybe will improve on this, but it will be a
hard
work. ATS language tries to improve a bit on this, but it's far from
being
good and its syntax is awful.
I think you are giving zero weight to the D features that assist kernel
programming.
D also lacks a good number of nonstandard C features that are present
in the
"C" compiled by GCC, such low-level features and compilation flags can be
quite useful if you write a kernel. Even LDC has a bit of such features.
A non-standard feature means the language is inadequate. There is
nothing at all preventing non-standard features from being added to D
for specific tasks. There is no reason to believe it is harder to do
that for D than to C.
As for standard features D has that make it more suitable for low level
programming than C is:
1. inline assembler as a standard feature
2. const/immutable qualifiers
3. identification of shared data with the shared type constructor
4. enforced function purity
5. guaranteed basic type sizes
6. arrays that actually work
6.5. arrays that actually work and don't need garbage collection
7. scope guard (yes, even without exception handling)
Andrei
