[ElectronCharge]

I'm surprised the author of this article thinks Go is a "system language".

Go uses GC, and therefore can't be used for hard real time applications. That's disqualifying as I understand it.

C, C++, Rust, Ada, and Mojo are true system languages IMO. It is true that as long as you can pre-allocate your data structures, and disable GC at runtime, that GC-enabled languages can be used. However, many of them rely on GC in their standard libraries.

[Jtsummers]

The Go creators declared it a systems language and it's stuck around for some reason.

Their definition was not the one most people would have used (leading to C, C++, Rust, Ada, etc. as you listed) but systems as in server systems, distributed services, etc. That is, it's a networked systems language not a low-level systems language.

[jandrewrogers]

I think the broad consensus (and I agree with it) is that a systems language cannot have a mandatory GC. The issue with GCs isn’t just latency-optimized applications like hard real-time. GCs also reduce performance in throughput-optimized applications that are latency insensitive, albeit for different reasons.

Anything that calls itself a “systems language” should support performance engineering to the limits of the compiler and hardware. The issue with a GC is that it renders entire classes of optimization impossible even in theory.

[code_martial]

You can preallocate your data structures and control memory layout in Go.

Also, despite GC there’s a sizeable amount of systems programming already done in Go and proven in production.

Given how much importance is being deservedly given to memory safety, Go should be a top candidate as a memory safe language that is also easier to be productive with.