4 ms·

I don't see how that's relevant. Most of those bugs are in GCC 10 which isn't released yet specifically because those regressions are all still open. Meanwhile,

I don't see how that's relevant. Most of those bugs are in GCC 10 which isn't released yet specifically because those regressions are all still open. Meanwhile, GCC 7 just got a bugfix release a few months ago. It just doesn't make sense to compare C/C++ compilers to rustc; my point is that rustc doesn't have a stable LTS release yet. The only way I could see this happening is if developers of other Rust compilers put pressure on your team to make a spec and stick to it for a number of years. Otherwise you're headed for a situation like Haskell where there is only one real compiler and it's permanently in a state of flux. Distro packaging for Haskell and its libraries is still a pretty complex task BTW.

JoshTriplett 7y ago
I feel like this is combining several different things that don't inherently need to be combined. There's active work on Rust specifications with varying degrees of formality, but I don't think that would address the problem you're describing. Specifications don't make bugs go away. There are, occasionally, regressions in rustc. We catch the vast majority of those before they hit the stable branch, but bugs do happen. We try to minimize them, and we also put out stable point releases with fixes. I also don't think that having multiple Rust compilers would affect the problem you're talking about. On the contrary, you'd then have multiple different sets of occasional bugs to deal with, and multiple implementations with differences that you'd have to cope with. Speaking personally, (and not wearing my language team hat), I personally don't see value in having multiple compiler frontends for Rust, given that rustc is Open Source. (I absolutely see value in having multiple code generation backends, but not in having multiple frontends.) Finally, regarding an "LTS" release: stable releases of Rust are supposed to be stable, not stagnant.

JoshTriplett 7y ago

I feel like this is combining several different things that don't inherently need to be combined. There's active work on Rust specifications with varying degrees of formality, but I don't think that would address the problem you're describing. Specifications don't make bugs go away. There are, occasionally, regressions in rustc. We catch the vast majority of those before they hit the stable branch, but bugs do happen. We try to minimize them, and we also put out stable point releases with fixes. I also don't think that having multiple Rust compilers would affect the problem you're talking about. On the contrary, you'd then have multiple different sets of occasional bugs to deal with, and multiple implementations with differences that you'd have to cope with. Speaking personally, (and not wearing my language team hat), I personally don't see value in having multiple compiler frontends for Rust, given that rustc is Open Source. (I absolutely see value in having multiple code generation backends, but not in having multiple frontends.) Finally, regarding an "LTS" release: stable releases of Rust are supposed to be stable, not stagnant.