4 ms·
> The issue is the opposite of --locked Shows what I know! So -- it's type inference of a new rustc and an old dep? That's much more interesting.
by mustache_kimono 2y ago
> The issue is the opposite of --locked
Shows what I know!
So -- it's type inference of a new rustc and an old dep? That's much more interesting.
- steveklabnik 2y agoYes, this is Rust 1.80.0 not being able to compile code that worked with 1.79.0. The vast, vast majority of the time, you don't need to worry about that, but every once in a while, something like this happens. There are limited times when it's permissible, and often steps are taken to limit the blast radius. The only reason people are noticing this is because time is such a popular dependency. And the fact that it was noticed and fixed before release is a success story for that release process, as users didn't have to wait for a fix, and could get their code fixed immediately.
- ucirello 2y agoI am not sure any of what you described can be declared a success in any sense. 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.
- hulitu 2y ago> 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.
- steveklabnik 2y agoYou can make an abstract argument as much as you'd like, but Rust toolchain upgrades cause the least churn of any ecosystem I've worked with in the past 25 years of being a software developer. That includes C projects. I've spent more time writing Hacker News comments about this than I did dealing with it.
- mustache_kimono 2y ago> Failure #1: The language deployed a non-backward compatible change. 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.
- bdjsiqoocwk 2y ago> The vast, vast majority of the time, you don't need to worry about that, but every once in a while, something like this happens Oof in Julia this never happens. Sounds to me that rust isn't ready for production.
- ArtixFox 2y agoNothing happens in julia
- iknowstuff 2y agoLmao