I have heard many times that languages with a garbage collector aren’t great for system programming. Today I saw a book titled “Hands-On System Programming with Go”.
Is Go or any other garbage collected language good for system programming? What are the pros and cons of using a garbage collected language for system programming?
Is the development of Docker (which is developed in Go) considered as system-programming? Or does system programming only mean developing things like Kernel and other low level things etc.
I think it’s because of the overhead impacting memory and performance. Languages like C and Rust operate much closer to the metal, so trade convenience and features for speed and performance.
I don’t have much experience here so maybe @OvermindDL1, @NobbZ, @Qqwy or others can offer a better explanation
It’s not necessarily overhead in some terms. Some GC’s try to keep memory low, often using things like stop-the-world collection or eating up another thread needlessly to keep it down. Some GC’s try to keep pauses minimal (like Go) so their memory can grow unbounded in many situations (and low pause is not no-pause). Python is interesting as most of its memory allocation is handled by smart pointers so they get evicted immediately, but it still has a loop scanner that runs on occasion for when people make memory loops. Many/most GC languages also don’t let you control when memory is released, or even from where you can get the memory in the first place, which is extremely important on some arch’s.
In short, GC’s just add some cost to a program that you generally don’t want on system languages. As well as GC’s only handle the resource known as ‘memory’, other resources like file or socket handles, PIN access, etc… still have to be done either manually, or if the language allows some kind of finalizer then you can let the resource be GC’d “eventually”, which is really bad on some resources.
Having a language that can handle any resource with no runtime cost is preferred.
