6 ms·

Can't really have it all. If you want runtime assertions on your data/state, that has a cost. Nothing is stopping you from writing that logic out and having all

Can't really have it all. If you want runtime assertions on your data/state, that has a cost. Nothing is stopping you from writing that logic out and having all your inputs and outputs sanitized for "semantic invariance". But if you want the language to implicitly do that, you're gonna have overheads. Pick a different systems language in that case, and deal with the tradeoff.

kelseyfrog 29d ago
The author makes reference to making these invariants expressable via the type system, a compile time overhead, not a runtime overhead.
- jakeinspace 29d ago
  Well, sure they make reference. Borrow checkers and memory ownership concepts, like in Rust, are pretty good at giving a very low overhead improvement over bare C pointers. But they're not as flexible. Shared memory complicates ownership rules. And invariably, any Rust program that involves real hardware will require dropping down into unsafe at some points. A safer program with an unsafe kernel is an improvement, don't get me wrong. I'm not sure how a type system would "solve" arithmetic overflow / bounds dynamically, without expensive overhead (boxed types).
  - gregw2 29d ago
    Regarding the "expensive overhead of boxed types", do we just need more work at the hardware ISA level (with pointer tagging or NaN-boxing) and we need the hardware to be aware of those bits and handle them safely/properly via some minor extensions to RISC-V or Intel/AMD/Apple ISAs? Or do we have to have completely new forms of hardware datatypes?
  - zbentley 29d ago
    I don’t think you have to reach for something as invasive as a borrow checker to handle most of these conditions. Bounds checks, for example, are rarely skipped intentionally in the vast majority of C programs; rather, they’re just skipped accidentally or performed incorrectly. Combine that with the extremely common and well-known compiler optimizations for BCE present in many compiled languages, and I don’t think C programmers get to trot out performance as an excuse for the language not supporting bounds checking by default, and providing escape hatches for people who really need to avoid it. The same is true for overflow and unsafe math (tons of languages increase math and overflow safety on many paths without performance penalty, and baking that behavior into the type system with nondefault unsafe options is demonstrably tractable). Hell, the prevalence of C static analyzers that warn about the vast majority of errors in these categories is proof that more safety is possible in C. It’s not really about performance. It’s more the stubborn obsession with ABI compatibility at all costs and a pervasive lack of type system support and conventions relating to code reuse that hold C back.
    - matltc 27d ago
      Well said. I get the sense that C is kind of ossified today, and that the whole point is its compatibility benefit. I wonder what even makes it into the next C standard? I think c99 was the last meaningful one. Everything else is offloaded to the compilers, God bless them. -Weverything

kelseyfrog 29d ago

The author makes reference to making these invariants expressable via the type system, a compile time overhead, not a runtime overhead.

jakeinspace 29d ago
Well, sure they make reference. Borrow checkers and memory ownership concepts, like in Rust, are pretty good at giving a very low overhead improvement over bare C pointers. But they're not as flexible. Shared memory complicates ownership rules. And invariably, any Rust program that involves real hardware will require dropping down into unsafe at some points. A safer program with an unsafe kernel is an improvement, don't get me wrong. I'm not sure how a type system would "solve" arithmetic overflow / bounds dynamically, without expensive overhead (boxed types).
- gregw2 29d ago
  Regarding the "expensive overhead of boxed types", do we just need more work at the hardware ISA level (with pointer tagging or NaN-boxing) and we need the hardware to be aware of those bits and handle them safely/properly via some minor extensions to RISC-V or Intel/AMD/Apple ISAs? Or do we have to have completely new forms of hardware datatypes?
- zbentley 29d ago
  I don’t think you have to reach for something as invasive as a borrow checker to handle most of these conditions. Bounds checks, for example, are rarely skipped intentionally in the vast majority of C programs; rather, they’re just skipped accidentally or performed incorrectly. Combine that with the extremely common and well-known compiler optimizations for BCE present in many compiled languages, and I don’t think C programmers get to trot out performance as an excuse for the language not supporting bounds checking by default, and providing escape hatches for people who really need to avoid it. The same is true for overflow and unsafe math (tons of languages increase math and overflow safety on many paths without performance penalty, and baking that behavior into the type system with nondefault unsafe options is demonstrably tractable). Hell, the prevalence of C static analyzers that warn about the vast majority of errors in these categories is proof that more safety is possible in C. It’s not really about performance. It’s more the stubborn obsession with ABI compatibility at all costs and a pervasive lack of type system support and conventions relating to code reuse that hold C back.
  - matltc 27d ago
    Well said. I get the sense that C is kind of ossified today, and that the whole point is its compatibility benefit. I wonder what even makes it into the next C standard? I think c99 was the last meaningful one. Everything else is offloaded to the compilers, God bless them. -Weverything