3 ms·

I think that the people who are debating it are missing some things. It often happens that only when a second implementation is attempted, unspecified holes in

by not2b 3y ago

I think that the people who are debating it are missing some things. It often happens that only when a second implementation is attempted, unspecified holes in the documentation are exposed and standards are tightened up. Any differences in the two compilers will either mean that there's a bug in the new implementation (most likely), a bug or unclear issue in the documentation, or a bug in the mature implementation (it happens). And no, the official compiler isn't canonical by definition. If it were, it would mean it has no bugs, and if there's a crash or a wrong result that's what the language is supposed to do.

vlovich123 3y ago
Everything in engineering is trade offs. A single front end ends up in a stronger position for the community (i.e. the users of the language) because bug reports are easier (only one project to report them to), collaboration is easier/simpler for OSS maintainers (no issues where “crate foo works fine on rustc but doesn’t on gccrs” to triage/maintain), and language features come quicker (no need to synchronize/debate with other implementations). The downsides of underspecification are much smaller by comparison. As far as documentation goes that’s a red herring because gccrs is reusing the single standard library implementation which means that any documentation issues would still exist (I don’t think I’ve even once needed to lookup documentation for the compiler & language docs issues would be shared as well since rustc in this model still remains the canonical ground truth).
- not2b 3y ago
  At this point, gccrs is quite immature, so you can simply ignore it. If we get to the point where its quality is good enough, this will change, but the likelihood is that any problems found will result in improvements to documentation (if something is underspecified). There could also be optimization bugs in LLVM that aren't present in GCC, so we could find bugs in rustc that aren't in gccrs at some point, but I think that will only be significant if gccrs greatly improves. For now, anyone who finds that “crate foo works fine on rustc but doesn’t on gccrs” can just report a bug to gccrs.
  - vlovich123 3y ago
    I’m not saying that gccrs contributors should stop. If they want to invest their time & energy into it kudos. I happen to think the costs outweighs the benefits but you’re right that I can just ignore it to no ill effect right now. Where I would caution that though is when the Rust project starts needing to making accommodations to help gccrs (which is something described in the article). It’s possible that some accommodations help Rust anyway / there’s no harm, but it’s also useful to be mindful that more & more of these accommodations can start to have a negative cost over time & thus impact Rust as a whole & these costs are obnoxiously hard to quantify and because people like to get along there’s a general preference to be more accommodating. That’s the real danger that gccrs poses and the intangible benefits that you lay out are likely not that significant in the long term compared with the cost to build gccrs / modify Rust to accommodate gccrs. Of course, we’re just arguing over opinions since it’s so hard to quantify any of this.

by not2b 3y ago

vlovich123 3y ago

Everything in engineering is trade offs. A single front end ends up in a stronger position for the community (i.e. the users of the language) because bug reports are easier (only one project to report them to), collaboration is easier/simpler for OSS maintainers (no issues where “crate foo works fine on rustc but doesn’t on gccrs” to triage/maintain), and language features come quicker (no need to synchronize/debate with other implementations). The downsides of underspecification are much smaller by comparison. As far as documentation goes that’s a red herring because gccrs is reusing the single standard library implementation which means that any documentation issues would still exist (I don’t think I’ve even once needed to lookup documentation for the compiler & language docs issues would be shared as well since rustc in this model still remains the canonical ground truth).

not2b 3y ago
At this point, gccrs is quite immature, so you can simply ignore it. If we get to the point where its quality is good enough, this will change, but the likelihood is that any problems found will result in improvements to documentation (if something is underspecified). There could also be optimization bugs in LLVM that aren't present in GCC, so we could find bugs in rustc that aren't in gccrs at some point, but I think that will only be significant if gccrs greatly improves. For now, anyone who finds that “crate foo works fine on rustc but doesn’t on gccrs” can just report a bug to gccrs.
- vlovich123 3y ago
  I’m not saying that gccrs contributors should stop. If they want to invest their time & energy into it kudos. I happen to think the costs outweighs the benefits but you’re right that I can just ignore it to no ill effect right now. Where I would caution that though is when the Rust project starts needing to making accommodations to help gccrs (which is something described in the article). It’s possible that some accommodations help Rust anyway / there’s no harm, but it’s also useful to be mindful that more & more of these accommodations can start to have a negative cost over time & thus impact Rust as a whole & these costs are obnoxiously hard to quantify and because people like to get along there’s a general preference to be more accommodating. That’s the real danger that gccrs poses and the intangible benefits that you lay out are likely not that significant in the long term compared with the cost to build gccrs / modify Rust to accommodate gccrs. Of course, we’re just arguing over opinions since it’s so hard to quantify any of this.