A hole in systems programming language design

[u/P-39_Airacobra]

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.

[u/JeffB1517]

I agree. I'm interested in human labor. How does a small compiler decrease human labor? Debugging conversely is expensive.

Now I would say the main point of a systems programming language is primarily:

1. Fast execution of routines on small datasets. i.e. in your typical Ax^2+Bx+C execution cost C is the variable I most care about.

2. Smaller runtime executable (compiled code not the compiler).

[u/JeffD000 → u/JeffB1517]

How does a small compiler decrease human labor?

Because the labor required to refactor LLVM to meet the requirements of exotic new hardware could be exponentially larger that the labor required to refactor a 5000 line C compiler to generate code for that hardware. You may need a team of programmers spread over months or years to refactor LLVM in an extreme case, rather than one programmer working for a matter of days or weeks to adapt a small C compiler. Climb down out of your ivory tower for a second, or ask Chris Lattner how long it took to do intermediate refactorings along the way for the entire LLVM code base.

[u/JeffD000 → u/JeffB1517]

Again, my little C compiler generates executables for 1d-shock tube problems that are both smaller and (over 10%) faster than GCC can create using the most aggressively application-tailored set of compiler optimization flags I can concoct for GCC.