3 ms·
> The problem is that C have practically no checks, so any safety checks put into the competing language will have a runtime cost, which often is unacceptable.
by hanneshdc 1mo ago
> The problem is that C have practically no checks, so any safety checks put into the competing language will have a runtime cost, which often is unacceptable.
This problem is overstated. There's no safety/performance tradeoff here. Rust has shown that extensive safety checks can be applied at compile time with zero runtime overhead.
For a concrete example, checking that an array access is in bounds at runtime does come with a performance penalty. However it's also possible to prove at compile time that an array index can never escape it's array bounds. And, if it's not possible to prove this statically - you should be heavily questioning the security of that code.
- 6P58r3MXJSLi 1mo ago> Rust has shown that extensive safety checks can be applied at compile time with zero runtime overhead. at the cost of developing time and workarounds overhead. > And, if it's not possible to prove this statically - you should be heavily questioning the security of that code. or that's exactly the compromise that allows you to develop that software there is no 100% safety with zero overhead it is not possible
- mejutoco 1mo agoThe claim was runtime cost > the competing language will have a runtime cost, which often is unacceptable. The problem you now mention > at the cost of developing time and workarounds overhead. Also happens with plain c and the "pay attention" method.
- 6P58r3MXJSLi 1mo ago> Also happens with plain c and the "pay attention" method. not really there are decades of well known practices to basically cover every possible scenario the point is Rust doesn't allow to write certain kinds of code or use certain patterns it's the cost of the boilerplate it's not that it is hard, it's that it is tedious and if we throw LLM at the problem, well, we're not talking about 100% safety anymore
- mejutoco 1mo ago> at the cost of developing time and workarounds overhead. Let me rephrase: you are saying that tedious following of best practices (using or not certain kinds of code or use or certain patterns) does not take extra time in c, but rust (compiler) not allowing to write certain kinds of code or use certain patterns does take extra time.
- tialaramex 1mo agoThe safety/performance trade is actually, once you think about it, obviously nonsense in principle. All correct solutions will be memory safe so only incorrect programs are unsafe. At that point it can't have better performance, the wrong answer faster is useless - I always come back to Mushroom Office: https://x.com/magdraws/status/1551612747569299458 https://x.com/magdraws/status/1551612747569299458 WUFFS provides strong concrete evidence. A WUFFS image decoder is entirely safe because that was the whole point, but it's also a lot faster because since we've proved this is safe we don't need any of these safeguards and precautions you'd want in languages which aren't sure. We cannot do anything wrong, so there's no need for the compiler to add bounds checks for example never mind Fil-C's "shadow" memory. Now, WUFFS pays a price for that, it's not a General Purpose Language. You can't write "Hello, World" in WUFFS because it doesn't have strings for the message or I/O to emit the message somewhere. But we should be clear eyed about how much we're paying when we insist we need generality. Not just safety, performance.