3 ms·
While I agree with your sentiment, I think this is not true in general. The Rust compiler sometimes rejects correct programs, in which case it can be harder to
by whyever 11y ago
While I agree with your sentiment, I think this is not true in general. The Rust compiler sometimes rejects correct programs, in which case it can be harder to write it in Rust than in C.
- catnaroek 11y agoIn the absolute worst case, you can pretty much transcribe your C program into unsafe Rust, though you will be fighting the syntax, which was deliberately made cumbersome to discourage programmers from writing unsafe code. In practice, I have never seen any programs where this is the best approach. Coming up with designs that don't need unsafe code is very useful, because the safe subset of Rust is vastly easier to analyze and understand, both for humans and computers.
- pcwalton 11y ago> The Rust compiler sometimes rejects correct programs, in which case it can be harder to write it in Rust than in C. Well, the C compiler sometimes rejects correct programs too.
- crzwdjk 11y agoSometimes C compilers can't even agree on what counts as "correct"! With Rust, you can at least be reasonably sure that if your program compiles with your version of the compiler, it will continue to do so with all later versions, because they're coming from the same codebase and made by people who care about backward compatibility.
- catnaroek 11y ago> Sometimes C compilers can't even agree on what counts as "correct"! This comes primarily from the fact the C standard itself is hard to interpret right. Standard ML has less issues in this department: since the Definition is clearer and less ambiguous, implementations disagree less on what counts as correct code and what its meaning is. So having only one major language implementation isn't the only way to prevent compatibility issues.
- kqr 11y agoHard to interpret right... according to some people, there is actually no valid reading of it.[1] [1]: http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1637.pdf http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1637.pdf