What degree of low-level programming can be achieved with Languages like Go?

Question

Go and D provide garbage collection, and yet they claim to be system programming languages. What degree of low-level programming can be achieved with languages having garbage collection?

For low-level programming, I mean close to the hardware or being able to:

1. Runs directly in limited memory, with no latency, and performs well. An example would be operating system kernels.
2. It runs on a software base, but still has to perform well. An example would be system utilities.

Answer 1

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.

1. 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.

2. 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.

Answer 2

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).