What do you mean by close to hardware? Being able to work with the hardware? Being able to run on a lot of hardware without further support? Being restricted to the level of abstraction hardware supports directly? Or something entirely else?
–
delnanAug 14 '12 at 7:41

2

by close to hardware, i mean 1) my software runs direcly on the limited memory, with no latency, and performs well, example os kernels. 2) it runs on a software base, but still have to perform well. Example System utilities.
–
samualAug 14 '12 at 7:53

1

@samual: Please, edit the last comment into the question.
–
Jan HudecAug 14 '12 at 9:31

2 Answers
2

I am not sure about go, but D clearly specifies which constructs may access the garbage collector (down at the end here; I actually think I saw a more detailed explanation on the site, but can't quickly find it). So you can choose where gc can and can't operate.

Runs directly on the limited memory, with no latency means (hard) real time. Which means you can't use even C++'s new and delete nor C++ exceptions nor many other features of C++ or even C. The D subset that you can use in these cases is well defined and thanks to custom new/delete even quite capable.

Most OS kernels don't do hard real time at all and do soft real time ("with sufficiently rare latency") only in interrupt service routines. Many parts of an operating system could easily use a mark&sweep style collector and be more performant than current systems that usually reference-count. It would require carefully crafted two-phase parallel collector, but it's doable.

As for runs on a software base, but still have to perform well, while garbage collector always implies somewhat increased memory use, the performance is usually comparable and often even superior to explicit memory managed programs. That's because the individual operations under garbage collector are usually simpler and because the allocation patterns tend to result in better cache utilization.

Combined with the fact that despite all the research that went to decent memory allocators most standard C libraries in the wild still have malloc that plainly sucks, there is no handicap for Go or D here.

I know this answer is late to the party, but I have a bit more to add.

Go is significantly higher-level than C/C++/D: it has no manual memory management, has a significant runtime environment, and uses more memory in general. You wouldn't want to write a kernel in Go because you'd have to port the (large) runtime to kernel space first. If you did, you'd probably run into some difficult-to-resolve performance issues as Go is not as CPU-friendly as C.

I believe D is meant mainly as a replacement for C++. C++'s role has largely been as a user-level systems/library programming language. Partly, this is because C was already dominant in the kernel when C++ started becoming popular. The other part is that the C++ runtime, while mostly limited to the memory allocator, has to be ported to the kernel as well. There have certainly been many C++ projects in kernel space, but it is not dominant there.

D has positioned itself to be an excellent library-writing language, and limited its in-kernel usefulness by requiring a larger runtime than C++ (or certainly than C). If you strip it down a bit (no GC, no standard libraries, no thread-scoped variables, some significant unsafe code segments, ...) you can make it run in the kernel easily, but then you're getting rid of many of its improvements over C++.

However, its performance characteristics and the ability to write low-level code are excellent and (more or less) match those of C or C++. I would especially recommend it for user-level projects, but there are some great things it can add to a kernel project as well (even if some of its nicest features aren't easily accessible there).

Go is a curious mix of higher and lower level. It is higher level in that it does not have explicit memory management at all, but it is lower because it lacks most tools for making things happen implicitly like constructors, destructors, operator overloading, any kind of metaprogramming etc.
–
Jan HudecApr 10 '14 at 6:06