3 ms·

Would you like to address the arguments in my post instead of going "Na-ah, you're wrong, I'm right"?

by adwn 5y ago

darthrupert 5y ago
I get your point, but I'm queamish on how far you stretch the definition of the word "complex". C has these problems because it's simple, i.e. it provides a rather thin abstraction layer over machine language. Rust's corresponding layer is much thicker due to its memory requirements and historical origins.
- adwn 5y ago
  > it provides a rather thin abstraction layer over machine language. No, it doesn't, and it hasn't for quite some time – not since C compilers started exploiting undefined behavior for optimization opportunities. It used to be that if you wrote a + b where a and b are int values, the compiler would emit an ADD instruction in assembly. This isn't necessarily true anymore, because compilers are allowed to assume that signed overflow doesn't happen, which makes writing correct overflow-detection so difficult and non-intuitive. Even worse, code which was working correctly for 20 years might start exhibiting subtle bugs from one day to the next, just because you've upgraded your compiler from version 9.4.2 to 9.4.3. Undefined behavior is one major reason why writing correct C code is complex and difficult in practice.
  - jcelerier 5y ago
    > where a and b are int values, the compiler would emit an ADD instruction in assembly. This isn't necessarily true anymore, because compilers are allowed to assume that signed overflow doesn't happen, which makes writing correct overflow-detection so difficult and non-intuitive. it's the exact opposite - if you want your compiler to just emit an ADD no matter which platform you are on, then it cannot be the language that defines the semantics of "+" in the corner cases (thus UB). If you define it as overflow on 2's complement, then on a DSP with saturating arithmetic your compiler will have to emit additional instructions to detect if you are saturating and wrap instead.

Would you like to address the arguments in my post instead of going "Na-ah, you're wrong, I'm right"?

by adwn 5y ago

Would you like to address the arguments in my post instead of going "Na-ah, you're wrong, I'm right"?

I get your point, but I'm queamish on how far you stretch the definition of the word "complex". C has these problems because it's simple, i.e. it provides a rather thin abstraction layer over machine language. Rust's corresponding layer is much thicker due to its memory requirements and historical origins.

adwn 5y ago
> it provides a rather thin abstraction layer over machine language. No, it doesn't, and it hasn't for quite some time – not since C compilers started exploiting undefined behavior for optimization opportunities. It used to be that if you wrote a + b where a and b are int values, the compiler would emit an ADD instruction in assembly. This isn't necessarily true anymore, because compilers are allowed to assume that signed overflow doesn't happen, which makes writing correct overflow-detection so difficult and non-intuitive. Even worse, code which was working correctly for 20 years might start exhibiting subtle bugs from one day to the next, just because you've upgraded your compiler from version 9.4.2 to 9.4.3. Undefined behavior is one major reason why writing correct C code is complex and difficult in practice.
- jcelerier 5y ago
  > where a and b are int values, the compiler would emit an ADD instruction in assembly. This isn't necessarily true anymore, because compilers are allowed to assume that signed overflow doesn't happen, which makes writing correct overflow-detection so difficult and non-intuitive. it's the exact opposite - if you want your compiler to just emit an ADD no matter which platform you are on, then it cannot be the language that defines the semantics of "+" in the corner cases (thus UB). If you define it as overflow on 2's complement, then on a DSP with saturating arithmetic your compiler will have to emit additional instructions to detect if you are saturating and wrap instead.