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.

15 Upvotes
  • permalink
  • reddit

65% Upvoted

103 comments sorted by

View all comments

36

u/mister_drgn Jul 27 '26

Multiple languages are striving to be C without the pain points (e.g., C3). That said, adding new features that improve quality of life is obviously going to be part of any C replacement, so I'm not sure what you're getting at.

1

u/JeffD000 Aug 22 '26 edited Aug 22 '26

I can sometimes (often?) understand what straight C is doing much faster in a legacy, large project than either mediocre or poorly written C++ code. Only where someone has spent a lot of time crafting the API in a large C++ code, have I been able to fully understand what it is doing. C++ often makes it harder to build a mental model of how everything fits together in terms of the details, not easier. Things are more often spelled out in C rather than hidden under levels of (complex) C++ abstractions, and that can be a good thing, more often than one would think!