Isn't this resolved by passing `--locked` to `cargo`? If you don't want it to resolve deps, don't let it. This isn't bit rot.
This lament seems similar to "I can't compile this Rust code (using an older version of rustc)".
Also, in this case specifically, --locked would be a no-op. Rust doesn't automatically upgrade dependencies unless you either change your Cargo.toml, or run cargo update to change your Cargo.lock. The author didn't change any dependencies, none of their versions changed, and so --locked wouldn't have changed that the failure happened.
Shows what I know!
So -- it's type inference of a new rustc and an old dep? That's much more interesting.
Failure #1: The language deployed a non-backward compatible change. Failure #1b: and their ecosystem thinks that's OK.
Failure #2: users only saw the need to upgrade the dependency because the language broke that dependency first. So unless they had some other reason to update the given dependency ahead of the compiler upgrade, they would be hit by the problem no matter what.
Failure #3: downplaying The importance of the breakage by implying the blast radius would've been smaller if the victim of the first two failures was a lesser known dependency.
I can't see any success - of the release process or in any other way.
And finally, framing a failure as success is one central problem I have with Rust ecosystem's toxic positivity. In any other healthy community the answer would be "OK, we made a mistake, let's run a post-mortem and do better", or even plain embarrassment - but Rust's ecosystem is the only one in which there's a failure in the joint of two releases processes and claim it as a "success story for [one of the] release process".
My hope, as bigger games adopt Rust (US Gov, MS, Linux etc) these attitudes will change.
It is going on since some years with no change in sight.
I've spent more time writing Hacker News comments about this than I did dealing with it.
I guess I'm trying to understand how this is particular to Rust. Isn't this something that can happen in any language which uses type inference? I wonder how other languages resolve. It may be fair to say -- "if you rely upon type inference, the algo isn't guaranteed not to change" as a caveat on backwards compatibility.
> And finally, framing a failure as success is one central problem I have with Rust ecosystem's toxic positivity.
Yeesh. The rending of garments is just too much.
Oof in Julia this never happens.
Sounds to me that rust isn't ready for production.