3 ms·
> compiler bugs... its fair to ignore those when discussing the language in the abstract When the language is defined as whatever the compiler does, as it is i
by torstenvl 3y ago
> compiler bugs... its fair to ignore those when discussing the language in the abstract
When the language is defined as whatever the compiler does, as it is in the case of Rust, I'm not so sure.
If there were a Rust standard with multiple compliant compilers, I'd be more convinced, but Rust isn't there yet.
(And TRF's trademark policy may well prevent it from ever getting there.)
- saagarjha 3y agoHaving more implementations doesn’t really help you avoid bugs in the one you’re using.
- deleted 3y ago[deleted]
- nullc 3y agoNot entirely true. When there are multiple implementations disagreements between them in normative behavior prove one or the other (or the language itself) has a bug. This means you can run randomized tests in your software, hash the results, and the hash should be the same between compilers (and across platforms). That's an option that doesn't exist when there aren't multiple, and even if you won't use the potential personally other people using it will eliminate bugs in the compiler. The csmith program was used to find an incredible amount of bugs in gcc and clang. This approach can also be applied to many pieces of ordinary code too. Prior poster's point is also that when there is only one the language is the compiler and it's not useful to talk about them in isolation. I don't fully agree with that in theory since the language is supposed to be stable-ish while bugs in the compiler will get fixed. So to the extent that something in rust is a footgun due to the language we might be stuck with it, but if its due to a compiler bug it will probably be fixed.