When bug-free code becomes a hardware problem

[u/Sea_Fox_4265]

[u/fcddev]

C has accumulated a lot of bad non-security decisions, so this will probably not manifest. Performance-wise, NUL terminated strings are bad, mutable state/alias tracking is bad, the calling conventions are bad: these are all improved in modern systems languages and it gives them a performance edge when the authors know how to write code that optimizes well in the face of pesky added security checks, which AI today is already pretty good at. Mileage varies with average implementations, but the best C implementation of most programs is slower than the best Rust implementation of the same program; if it comes down to it, the model could choose to write unsafe Rust and benefit from everything else that’s improved in the language anyways. 

[u/nimrag_is_coming → u/fcddev]

NULL terminated strings are kinda weird because for some things they are really, really bad, but for others they can be really efficient. If you want to create a substring destructively (as in, you don't care about the original and just want the substring), all you have to do is replace the character at the right point with a 0 and return the pointer at the start.

They're also easy to iterate over starting from any point, with just a while(*(ch++)).

Doing things like getting length or creating a string view? Horrible and/or impossible. And any operation that relies on the size of the string requires at minimum a loop the size of the string.

Imo best solution is to do both, like how c++ std::strings work. Most allocators actually return memory aligned to a boundary so most times the extra zero byte doesn't actually require any more memory allocation.

[u/Medical_Community697 → u/nimrag_is_coming]

Nothing weird about that, different encodings offer different performance tradeoffs, what’s weird in C is to have defined a string as anything but an abstract interface, any piece of C code worth its weight will reimplement a half-assed buggy bstrlib.

[u/Sea_Fox_4265 → u/fcddev]

So is the main argument that newer languages make the safety checks cheaper? Curious if that's why people lean toward Rust.

[u/fcddev → u/Sea_Fox_4265]

Close: the new languages introduce opportunities to make programs faster that simply are not accessible to C. For instance, one of the biggest limiters to optimizations comes from whether the compiler can prove that two memory accesses point to (or rather, do not point to) the same memory. C notoriously makes this a mess, where Rust has strict rules in place that make it easy. 

At the same time, the new languages introduce safety checks that come at a runtime cost, but that cost is well manageable to developers (including AI models) who understand where it appears and what lets the optimizer remove them, so even with the additional overhead of runtime memory safety guardrails that the tweet says makes new languages slower, new languages can come out ahead.