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.
  • From your question, it seems that for you, low level and GC are related. If this is the case, what do you really mean by low level? Aug 14, 2012 at 7:27
  • 1
    close to hardware.
    – samual
    Aug 14, 2012 at 7:32
  • 2
    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?
    – user7043
    Aug 14, 2012 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.
    – samual
    Aug 14, 2012 at 7:53
  • 1
    @samual: Please, edit the last comment into the question.
    – Jan Hudec
    Aug 14, 2012 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.

  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.


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 Hudec
    Apr 10, 2014 at 6:06
  • @JanHudec I'm not entirely sure a lack of ctors, dtors, operator overloading, etc. are good reasons to consider the language as 'low-level'. For example, Java lacks dtors and operator overloading, to name a few, but I don't think we would normally look at Java and think of it as a 'low-level' programming language in the same sense that a language like C is, etc.
    – code_dredd
    May 4, 2018 at 16:31

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.