3 ms·

That post doesn't have any concrete promises about what stability actually means. Furthermore I don't see that in practice. To be able to say you're stable you

That post doesn't have any concrete promises about what stability actually means. Furthermore I don't see that in practice. To be able to say you're stable you have to have a spec and stick to it over a number of years. Is there one? Unit tests in rustc don't count because contributors just regularly delete or change those. I still see statements coming out from other contributors describing regular regressions and breakages to the core language happening even in the last few months: https://www.pietroalbini.org/blog/shipping-a-compiler-every-six-weeks/ https://www.pietroalbini.org/blog/shipping-a-compiler-every-... https://blog.ryanlevick.com/rust-2020/ https://blog.ryanlevick.com/rust-2020/ Disclosure, I don't work on Rust or any other language, I just keep an eye on it out of interest. I give it another few years before these big regressions stop happening. Please keep at it and don't take any of my statements as being discouraging.

jcranmer 7y ago
Compilers are big, complex programs, which means they of course have bugs in them. If you think rustc is unstable because of a half-dozen regressions in the last release cycle, then gcc must seem to you to be a dangerously rickety piece of software: https://gcc.gnu.org/bugzilla/buglist.cgi?cf_known_to_fail_type=allwords&cf_known_to_work_type=allwords&chfield=%5BBug%20creation%5D&chfieldfrom=6w&chfieldto=Now&order=Importance&query_format=advanced&short_desc=regression&short_desc_type=allwordssubstr https://gcc.gnu.org/bugzilla/buglist.cgi?cf_known_to_fail_ty... That query lists all regressions filed in the last 6 weeks, and there are nearly 150 of them.
- cycloptic 7y ago
  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.

jcranmer 7y ago

Compilers are big, complex programs, which means they of course have bugs in them. If you think rustc is unstable because of a half-dozen regressions in the last release cycle, then gcc must seem to you to be a dangerously rickety piece of software: https://gcc.gnu.org/bugzilla/buglist.cgi?cf_known_to_fail_type=allwords&cf_known_to_work_type=allwords&chfield=%5BBug%20creation%5D&chfieldfrom=6w&chfieldto=Now&order=Importance&query_format=advanced&short_desc=regression&short_desc_type=allwordssubstr https://gcc.gnu.org/bugzilla/buglist.cgi?cf_known_to_fail_ty... That query lists all regressions filed in the last 6 weeks, and there are nearly 150 of them.

cycloptic 7y ago
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.