I agree with your priorities, but I want to stress that don't think there's any reason to believe the people working on the language are confused about this. The ergonomics initiative has explicitly been about making certain things easier without introducing ambiguity or jeopardizing the safety guarantees Rust offers.
Like the OP says, the article is misguided, and if it has any effect, it will create FUD in people who have not followed the ergonomics proposals enough to know better.
I was part of a couple ergonomics discussions and I disagree.
Yes, in the end the changes don't sacrifice long-term maintainability over learnability/marketing, but that was a hard fight. And given editions will allow radical changes to the language and ecosystem every 3 years, I'm not sure how long that resistance is sustainable.
> And given editions will allow radical changes to the language and ecosystem every 3 years
This is incorrect. Editions are incredibly limited in what they can introduce (it needs to be something that it is possible for the compiler to warn for, with no false positives or false negatives). In practice this means that they're mostly limited to introducing new keywords and other little bits of trivial syntax.
An example would be the talk about removing the ability to declare reference bindings with `ref` and `ref mut` and always inherit whatever the source mode was.
Edit: There is also talk about changing the prelude, so I would assume the standard library is also fair game.
It's not a misconception, there are plenty of times in the past year that I've heard someone propose some change for the new edition only for the Rust devs to meet it with "that's not possible because we can't infallibly warn for it in the compiler, so there's no point discussing it". Furthermore, just because we can imagine things that could be broken, it doesn't mean that the Rust developers interpret that as carte blanche to break things. The history of Rust development since 1.0 has been one of careful, gradual, and conservative change. It appears that you have a lot of fear about various things that you imagine might be changed (such as ref and ref mut in patterns, which is sort of head-scratching because I've never heard anyone propose removing them, and it wouldn't make sense to remove them anyway), but I think such fears are unwarranted. I've been observing the Rust developers at work longer than almost anyone, and I've ended up with a degree of trust in their sense of taste that rivals that of any other project that I've seen. The people behind the language today are the same ones who have been behind the language for years now, so if you happen to like where their influence has led the project so far, I think it's reasonable to trust that they won't abruptly leap off the rails. :)
> It's not a misconception, there are plenty of times in the past year that I've heard someone propose some change for the new edition only for the Rust devs to meet it with "that's not possible because we can't infallibly warn for it in the compiler, so there's no point discussing it".
Do you have examples for that?
Edit: I'm not doubting you, but having precedent of things that were rejected due to breakage it causes might be helpful in some current/future discussions :)
> Furthermore, just because we can imagine things that could be broken, it doesn't mean that the Rust developers interpret that as carte blanche to break things. The history of Rust development since 1.0 has been one of careful, gradual, and conservative change.
My fear is that this is currently changing. There are a couple of threads on the internals forum currently collecting ideas of what people want changed in future epochs. To me, that's a shift to a different mode of operation. From "editions allow breakage as last resort" to "editions make breakage no longer a big issue".
> It appears that you have a lot of fear about various things that you imagine might be changed (such as ref and ref mut in patterns, which is sort of head-scratching because I've never heard anyone propose removing them, and it wouldn't make sense to remove them anyway)
The idea also seemed like a big hit in #rust-lang at the time. People were quite gleeful that `ref` could go away at some point.
I'm happy it's no longer on the table, but having to fight for the ability to destructure into mutable and immutable felt wrong.
Same thing with the modules redesign. Having to fight that hard for your existing workflows and use-cases not to be broken through multiple RFCs felt wrong as well.
Having some constructs auto-convert their final result value seems certain at this point.
> but I think such fears are unwarranted. I've been observing the Rust developers at work longer than almost anyone, and I've ended up with a degree of trust in their sense of taste that rivals that of any other project that I've seen. The people behind the language today are the same ones who have been behind the language for years now, so if you happen to like where their influence has led the project so far, I think it's reasonable to trust that they won't abruptly leap off the rails. :)
I've been following Rust since 0.10 or so, so I've been there quite a while as well. I was there for the uint wars, the battle of match ergonomics, and of course the big module rework skirmish.
I'm sure nobody is acting out of malice, my fears are more that with a certain community size, it is easy to be drowned out if you have different needs or opinions.
Interesting. I guess you’re closer to the action than I am. I didn’t participate, but liked the proposals I read (I think I saw a lot of them by way of core contributors.
Would you mind sharing some of the proposals you thought were dangerous and whether you felt like they were close to being adopted?
The interesting (and to me frustrating) part is that often good improvements (or intentions to solve actual problems) come together with far-reaching changes in an all-or-nothing kind of way. Some examples:
* I'm still of the opinion that moving `&mut T` to `&uniq T` pre-1.0 failed because it also proposed getting rid of `mut` alltogether and be mutable by default.
* Everything that relates to errors often also tends to accumulate a push to make things look more like exceptions. That applies to `?` short-ciruiting, the current discussion about limiting the scope of that short-circuiting, and anytime auto-converting final-value result types comes up. (and it currently looks like that short-circuit construct will auto convert its final value when it arrives).
* Making paths saner and modules and visibility more intuitive first started out proposing completely removing the option of being explicit about project structure, and it took multiple rounds of RFCs to keep that control.
* The match ergonomics discussions hinted at a wish by some to get rid of `ref` and `ref mut` patterns which is what allows destructuring a mutable reference into mutable and immutable bindings.
It seems to be that this is one of those fights where I (as a Rust developer) would prefer that both sides fight as hard as possible. An article like this, by suggesting that the "ergonomists" move more toward the mindset of the "safety people", could cause undue wins of the "safety people" over the ergonomists, when what should have happened is a careful compromise.
Personally I wish it wouldn't have to be a fight, but Github issues are not well suited for large scale design discussions and are bound to produce certain amounts of grief.
Like the OP says, the article is misguided, and if it has any effect, it will create FUD in people who have not followed the ergonomics proposals enough to know better.