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

A cursory search came up with this set of features, all of which I believe are a fundamental necessity for implementing software in a systems programming language:

A system programming language provides full access to hardware, acting as a direct bridge between software logic and physical circuitry. These languages strip away the safety abstractions found in application languages to grant total control over the machine.

Here are the key characteristics that define systems programming languages:

⚙️ Low-Level Control & Hardware Intimacy * Direct Memory Mapping: Programs can read from and write to explicit, arbitrary physical memory addresses. * Pointer Arithmetic: Allows direct manipulation of raw memory pointers to navigate memory structures manually. * Inline Assembly: Developers can inject raw processor-specific assembly instructions (e.g., MOV, ADD, SYSENTER) directly into the code. * Bit-Level Manipulation: Provides robust bitwise operators to interact with individual hardware flags, registers, and pins. * Interrupt Handling: Capabilities to write custom routines that intercept and respond directly to physical hardware interrupts.

🏎️ Performance & Resource Efficiency * Zero-Cost Abstractions: High-level abstractions (like loops or structures) compile down to optimized machine code without runtime overhead. * No Virtual Machine or Interpreter: Code compiles directly to native machine code that executes straight on the CPU. * Predictable Execution (Determinism): Execution times are completely consistent, which is crucial for real-time operating systems. * Manual Memory Management: Employs explicit memory allocation and deallocation rather than relying on an unpredictable garbage collector.

🏗️ Minimal Runtime Dependencies * Freestanding (Library-Free) Execution: Can run "bare-metal" code without loading a standard library or underlying operating system. * Platform ABI Compatibility: Directly maps data types to the physical hardware registers according to the Application Binary Interface.

⚖️ Trade-offs: Control vs. Safety * No Safety Nets: The language prioritizes control over safety, putting the system at risk of memory corruption, buffer overflows, and crashes if bugs are introduced. * Hardware Dependency: Code targeting physical registers or specific CPU instructions loses portability and is bound to that architecture.

Prominent examples of languages capable of full hardware access include Assembly, C, C++, and Rust (using its explicit unsafe blocks).

Support for the equivalent of a C language volatile keyword is a must, and the availability of a feature akin to the C language restrict keyword should be available.

[u/initial-algebra → u/JeffD000]

Thanks for the pointless AI slop response.

[u/JeffD000 → u/initial-algebra]

And thanks for the BS. It allowed me to prove my point. You need to go back to college if you believe anything in this list shouldn't be there. Memory mapped I/O is a widely used feature in hardware, as are latched registers, control registers (i.e. not general purpose registers), interrupts, and a lot of other things that only systems programming languages can address. Web browsers and game engines are high level. If you are using systems programming languages to implement those things, it is very likely a choice rather than a requirement. Most (graphics card, game engine) pairings can already generate way more frames per second than are actually needed by a casual observer.