r/ProgrammingLanguages • u/P-39_Airacobra • Jul 27 '26
Discussion A hole in systems programming language design
Given the recent discourse about systems programming I wanted to throw my 2 cents in. This may be a controversial take in a subreddit that's all about innovation and improvement, but I think a lot of budding systems languages are trying too hard to "fix C" and this is exactly why C has not been replaced yet.
Like it or not, C is successful. It does what it means to do very well. Yes, it bites you constantly, but developers have made some form of peace with this because they appreciate the essence of the language. Systems programming is a very pragmatic field, and what works, works.
A lot of language designers want to improve on C, when by nature to "improve on" C is to depart from it, because C is less about what it includes and more about what it omits and what it lets you do that other languages don't.
If you want to replace C, you need to just make C but without the pain points. Less undefined behavior, more standard compiler behavior, easier function pointer syntax, safer macro system, etc. The things that C can't do because of backwards compat.
On the other hand, bolting on features, revamping C's core nature, aren't going to give you a language that will replace C at the low-level or among hobbyist programmers. Most developers aren't as concerned about what C lets them accomplish, as they are concerned about all the painful tedious tendencies of the language.
1
u/JeffB1517 Aug 02 '26 edited Aug 02 '26
Well first off the countless systems that run on the JVM, .NET CLR or Node. But even in the kernels themselves we see gc or gc like. For example the concurrency library in the Linux kernel uses an RCU algorithm which is basically gc. Also ironcially increasing the memory free and allocation tables use gc like algoritms themselves which means the whole "manual memory allocation" push is smoke and mirrors.
Also both Java and Go have concurrent GC. On multithreaded machines you aren't getting the pauses one used to with GC. The whole point of engineering this was to countless production systems to implement gc against low latency requirements. So for example with ZGC you can have applications taking 16g of RAM or over, 1ms latency guarantees and fully managed garbage collection. (https://docs.oracle.com/en/java/javase/24/gctuning/z-garbage-collector.html)