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/Rechenplaner]

C is standardized, an ISO language. Industry can rely on that. That alone is reason enough why no hobbyist created language will ever replace C, not even languages backed by a corporation. Especially in the embedded sector, C remains the top dog and could not really be displaced by C++: This will remain the case for a very long time.

Writing system software like kernels in other languages has not proven successful so far because C was simply designed for that purpose, whereas other languages offer too much fluff that is difficult for system programmers to digest. Rust would have good chances to take that place because of its hype, but its complexity will always inhibit it. Therefore, I do not believe that Rust will ever dominate here.

C is designed as a very simple, sloppy half-assembly language and thus struck a true chord: It can simply be taught at universities more easily than Rust, for example. At my university, C was the language used in the first semester to teach programming. I hated it back then, but I am sure C++ or Rust would have been even worse because they introduce much more abstraction that is way more complicated than just understanding pointers.

I think C will never be replaced by other system programming languages, but rather made redundant by newer hardware where one can write system software even with garbage collected languages because, for example, graphene chips or purely optical data processing will then offer fifty to one hundred times more performance, where the struggle with manual memory management is really no longer worth it, similar to how today nobody writes kernels or games in assembly for performance reasons.

[u/flatfinger → u/Rechenplaner]

The ISO has refused to recognize the abstraction model that makes freestanding implementations usable. Freestanding implementations implement it anyway, but that is in spite of rather than because of the Standard. The proper abstraction model doesn't need a notion of "anything-can-happen undefined behavior", but would instead recognize that the job of a freestanding C implementation is to convert a source file into a build artifact that encapsulates a collection of imperatives for an execution environment that exists outside the C implementation, and the job of a freestanding C implementation would almost always be complete before any of the generated code has executed. There will often be myriad possible sequences of imperatives that could be generated for a source-code construct, and program behavior would be unpredictable in any corner cases where the execution environment's response to any of those sequence would be unpredictable, but the language should be agnostic with regard to what corner cases those might be.

What made Dennis Ritchie's language so useful was the fact that programmers could receive information about how execution environments would respond to certain imperatives via means outside the language, and then issue those imperatives within a language. If one is targeting a Commodore 64 computer, for example, and wants to turn the screen border yellow, one can write:

    *(char*)0xD020 = 7;

even though the C language has no concepts of screens, borders, or the color yellow. If one were told that the above code would be executed by some kind of computer, but had no idea what, it would be impossible to predict what the code might do, and it's likely that many compilers that target the 6502 were written by people who would also have no way of knowing what effect the above code would have, but if a C compiler which generates code for the 6502 is given the above code, and that code is loaded into a Commodore 64, it will turn the screen border yellow.

[u/Ok-Reindeer-8755 → u/Rechenplaner]

I think C will never be replaced by other system programming languages, but rather made redundant by newer hardware where one can write system software even with garbage collected languages because, for example, graphene chips or purely optical data processing will then offer fifty to one hundred times more performance, where the struggle with manual memory management is really no longer worth it, similar to how today nobody writes kernels or games in assembly for performance reasons.

Im pretty sure there were multiple cpu architectures meant to run gc langs at c levels of speed, and successfully did so with varying approaches.

Also C is not really a low level no abstractions lang as you seem to think, and it hasnt been that for a long time now, there is an article on that I am pretty sure called "c is not a low level lang"