> no longer changing cause old code has to work, but
> growing... which seems worse
It should be mentioned that the "features" that Rust has yet to implement are largely not of the nature of "wholly new concepts that will drastically change the language", but tweaks to existing features to make them more performant and more ergonomic. Such features include lessening the restrictions on the borrow checker, making it possible to return unboxed closures constructed in a lower stack frame, and improvements to user-defined smart pointer types to make them equal to first-class constructs (such as the ability to do `Rc<Trait>`). "Growing" here means refining the language as it exists, not succumbing to featuritis.
> the entire userbase is on a 6 week upgrade cycle -- 8 or
> 9 upgrades a year.
I don't see how this would be the case. If you write a lib for Rust 1.0, the intent is that it will continue to work for all users on Rust 1.1, and 1.2, and 1.3, and so on. No need for the lib author to explicitly upgrade, and hence no need for lib consumers to upgrade.
> I consider the idea that the channels will not fracture
> the community to be very naive.
Nobody is expecting the entire Rust ecosystem to transition to stable overnight. Rust 1.0 presents a very conservative foundation upon which you might want to base your code. If you do, you are rewarded with future stability for all 1.x (and also means that even unstable users will be able to use your code without breakage). This means that the stable Rust ecosystem will gradually accumulate over time. This gradual transition process is fully expected and encouraged.
Rust 1.0 does not mean "the language is done and perfect". It means "we know you're tired of breaking changes, so we've set aside all these enhancements that we were planning on adding so that we can achieve stability sooner, with the expectation of landing those features backward-compatibly at some later date." Rust could easily spend years and years and years in an unstable state, seeking perfection, and there are some in the community who still wish that were the plan. But as someone who's been using Rust since 2011, I'm in agreement with the core team: stability now, evolution over time.
> "Growing" here means refining the language as it exists, not succumbing to featuritis.
In no world does "we expect that pace of change to accelerate" mean "we expect subtle refinement of the language". Refinement or polishing generally isn't something that "accelerates change".
Rust 1.0 does not mean "the language is done and perfect". It means "we know you're tired of breaking changes, so we've set aside all these enhancements that we were planning on adding so that we can achieve stability sooner, with the expectation of landing those features backward-compatibly at some later date." Rust could easily spend years and years and years in an unstable state, seeking perfection, and there are some in the community who still wish that were the plan. But as someone who's been using Rust since 2011, I'm in agreement with the core team: stability now, evolution over time.