You still have to understand all the new stuff to read other people’s code. And the old way, so you can read older code. And if there are other ways to do something that are or have recently been in common use, those too. You end up memorizing a bunch of crap for one actual operation.

Yep.

I think ruby (which in general I still love) has become a major offender of this. "If you don't like it don't use it" is not a good answer for exactly the reasons you explain.

I sense a goalpost moving here. The point of the blog post to which I answered to was: I have to redo all my programs to follow the "idiomatic" way.

Now we are at "other programmers could use new features, so I still have to learn them". And yes, that is true. And that will always be true as long as a language has new releases. Even if all those releases were library changes and not syntax changes/additions. The only way to stop this would be to stop all language development.

Even worse would be if someone pulled in a library... That requires much more cognitive load and doc-reading than something like try! -> ?

Or the worst of all possible worlds -- pulling in a macro-based framework

But you don't have to change your code unless it's an improvement to you. Somebody else may do it if they care, and you may accept OR reject the PR with no bad feelings.

Agreed. I know plenty of codebases still written in C++03 style and work fine. I'm still using 2015 edition Rust crates and they work fine. I won't say there's no cost to evolving idioms, but evolving idioms on this front means it's more of an affront to asthetics than it is to productivity or anything else actually important to business goals, IMO.

The one exception perhaps being async/await, in that a bunch of crates are making breaking API changes to accomidate it and bumping their major versions - because it's bloody useful and a bit more than your typical syntactic sugar - which means changing your code if you want to keep getting patches.

I can’t force other people not to use changes, which means I will always need the latest version of rustc installed if I want to be able to build a relatively complete selection of the corpus of Rust code, which in turn makes it very difficult if not impossible for rust software to be distributed in typical OS package managers.

I.e., imagine how Debian or Ubuntu could package things if the definition of C++ changed every six weeks, given that the compiler version should change as little as possible during a major OS version cycle? This is a major blocker holding Rust back from mainstream adoption, IMO.

Can't package managers distribute binaries? Besides, maybe the fact that a package can fall three years behind the stable release is a problem with package management, not the stable release.

They can, but Rust doesn't have a stable ABI, so that doesn't really work this way.

You still need to know about the feature and understand how it works or eventually you'll only understand your own code as everybody else is using stuff you haven't learned.

From my experience of trying to learn Rust (got almost halfway through the manual and then put it on hold), I would add that having all these ways of doing the same thing is also confusing from a beginner's perspective. As a noob, I have no idea what the timeline is of when feature A was introduced that does the same thing as feature B. Also, I kept having to dig around to see if feature A added any type of improvements (other than syntactic sugar) over feature B.

• try!() has been replaced by ?. You don't even need to know — the compiler will tell you.

• futures 0.1 has been replaced with std::futures.

This is it. This is the exhaustive list of A->B feature changes in the last 42 releases of Rust. Now you know them all.

Rust is aggressive with keeping everyone using the current stable release. In C++ you may need to keep track of feature history to know if something is too new or too old for your compiler/project. There's no such thing in Rust. If you know a feature exists, you can use it.

It is not fully backwards compatible between editions, though.

Editions are opt in. You don't opt in, nothing changes for your code.