5 ms·
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 disq
by ElectronCharge 8mo ago
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.
- code_martial 8mo agoYou 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.
- Jtsummers 8mo agoThe 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 8mo agoI 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.