I think it’s interesting that Rust – which touts its backwards compatibility, the “editions” system, etc. – is already, at this still-relatively-early stage of its existence, uncovering the difficulty of “stability without stagnation”.
There are a significant number of people, and I’d expect more of them in Rusts’s core “systems programming” niche than in some other fields of programming, who not only want but actively love and embrace stagnation. Even if the language itself never forces them to upgrade, the mere fact that the ecosystem will move on and leave them behind (say, via crates they depend on no longer maintaining old releases) is offensive to them, and they’ll complain endlessly about all the “make work” they have to do to keep up, and “why can’t anything ever just be considered finished”.
I don’t know how to solve this. I suspect there isn’t a solution and that “stability without stagnation” isn’t actually an achievable goal, at least not the way many “systems programmers” would like it to be.
I think the response has shown this [a sense that Rust is “uncovering the difficulty of ‘stability without stagnation’”] is not representative of the Rust community.
I think pleasing “those systems programmers” will come by itself. When rust is 20+ years old and all big features that came in settled down. (You could say it got rusty.)
What happened with the rust governance?
Nothing fundamentally. Calls for restructuring the teams and making responsibilities clearer are old. E.g. here’s 2 posts from 2018, both focusing on that angle completely. https://yakshav.es/rust-2019-rethinking-the-team-structure/ (mine) https://without.boats/blog/rust-2019/ (boats)
That didn’t read as positive as I’d have hoped, especially regarding the governance and required workforce.
I think it’s interesting that Rust – which touts its backwards compatibility, the “editions” system, etc. – is already, at this still-relatively-early stage of its existence, uncovering the difficulty of “stability without stagnation”.
There are a significant number of people, and I’d expect more of them in Rusts’s core “systems programming” niche than in some other fields of programming, who not only want but actively love and embrace stagnation. Even if the language itself never forces them to upgrade, the mere fact that the ecosystem will move on and leave them behind (say, via crates they depend on no longer maintaining old releases) is offensive to them, and they’ll complain endlessly about all the “make work” they have to do to keep up, and “why can’t anything ever just be considered finished”.
To get a real sense of where that leads, see Daniel Stenberg’s recent post about why curl still can’t/won’t adopt C99. Something that’s literal decades old is still too new and would be moving too fast for the same kinds of programmers Rust is allegedly targeting.
I don’t know how to solve this. I suspect there isn’t a solution and that “stability without stagnation” isn’t actually an achievable goal, at least not the way many “systems programmers” would like it to be.
I think the response has shown this [a sense that Rust is “uncovering the difficulty of ‘stability without stagnation’”] is not representative of the Rust community.
I think pleasing “those systems programmers” will come by itself. When rust is 20+ years old and all big features that came in settled down. (You could say it got rusty.)
…
He’s not the first person to propose this, not even on the team, so for people with context on the project, this doesn’t raise an eyebrow.
Probably also due to things like this https://github.com/rust-lang/rust/issues/84970