2 ms·

I think we're not seeing "eye to eye" because you're not actually responding to my comment! You seem to be responding to something else. I said "it's really a b

I think we're not seeing "eye to eye" because you're not actually responding to my comment! You seem to be responding to something else. I said "it's really a bug in the design of Rust itself" and you agree. My point is that you said > Nobody claims that other compilers must also have the exact same bugs. And that's true! But it's not relevant. Most people say other compilers should have 1) the same underlying type theory as rustc 2) almost complete source-compatibility with rustc If, say, "rustd" satisfies 1) and 2), then it's guaranteed to have many of the same memory vulnerabilities as rustc. The only way to fix these vulnerabilities is to break 1) or 2), which is an awfully steep price.

vlovich123 3y ago
FWIW C and C++ also have plenty of compiler-specific and language errata due to unsoundness issues in the spec / implementation bugs following the spec. I don't really follow how an alternate Rust compiler would solve this since a language errata needs to be fixed at the language level & would impact all conforming compilers unless this alternate Rust compiler basically forked the language, in which case the Rust trademark is good as it lets people disambiguate between the forks. If it's a design issue, the Rust team is doing pretty good on that front I think in terms of exploring new ways of represting the type system (e.g. Polonius & the Trait solver work that's moving forward). Also, even if it somehow a new compiler somehow improved soundness without forking the language, especially for a language as complex as Rust, at best you're just picking an alternate set of bugs. AFAICT the Rust team follows best practices in terms of developing the code & managing the people working on it, so it's hard to imagine an alternate compiler team would outperform their progress until the Rust project itself stagnates. Also, any successful fork would likely start with rustc as the basis anyway (the struggles and slow-going GCC is having reimplementing Rust within GCC should exemplify why a separate frontend isn't helpful).

vlovich123 3y ago

FWIW C and C++ also have plenty of compiler-specific and language errata due to unsoundness issues in the spec / implementation bugs following the spec. I don't really follow how an alternate Rust compiler would solve this since a language errata needs to be fixed at the language level & would impact all conforming compilers unless this alternate Rust compiler basically forked the language, in which case the Rust trademark is good as it lets people disambiguate between the forks. If it's a design issue, the Rust team is doing pretty good on that front I think in terms of exploring new ways of represting the type system (e.g. Polonius & the Trait solver work that's moving forward). Also, even if it somehow a new compiler somehow improved soundness without forking the language, especially for a language as complex as Rust, at best you're just picking an alternate set of bugs. AFAICT the Rust team follows best practices in terms of developing the code & managing the people working on it, so it's hard to imagine an alternate compiler team would outperform their progress until the Rust project itself stagnates. Also, any successful fork would likely start with rustc as the basis anyway (the struggles and slow-going GCC is having reimplementing Rust within GCC should exemplify why a separate frontend isn't helpful).