> Java went three years, from December 1998 to February 2002

Oh hell no.

Sun was widely criticized for that boneheaded move, and for the whiplash everyone experienced in Java 5 when they changed that policy too fast.

The mass of changes in 5 left a lot of tools and thus people stuck in 1.4 for years. I started on a project a bit before 6 came out. It was processing data and I couldn’t use the collections API, because it had to run on an embedded system and Aicas was taking their sweet time catching up with all those changes. Four years later I was still using arrays for everything.

One problem with not changing at all for a long time is that everybody forgets what it means to change. Teams stop planning for it, developers get too used for things being they way they got to know over the years.

Then you get huge pills like Java 8 which took forever to be adopted in large corporations.

I have witnessed most of Java history play out, starting with Java 1.3 in 2000.

Looking back, I wish we had regular change cadence where new features are being slowly added at a regular pace so the versions don't feel like a completely new language and developers have time to digest the new possibilities.

It is interesting when you spend multiple years on various projects, each being in a state of migrating from 1.6 to 8. Or coming to interviews and the first question being asked is "Which version of Java are you working on right now?".

Similar problem with Ada. 2012 standard came and for a long time only AdaCore supported it... Now going for 202x I'm thinking only advocating small changes that don't reduce ease of reading code...

`match` ergonomics don't affect already working code.

Ok-wrapping isn't a change that's been made. At best it's a hypothetical change that one person wanted to have a calm, rational discussion about with the community. Instead we get this.

> What i find annoying about Rust's changes is that some of them are so trivial - they change the language for such small improvements. async/await is not in that category, for sure. But Ok-wrapping actually is. The need to Ok-wrap results is a minor annoyance at most. Ditto a bunch of the problems solved by match ergonomics changes.

So what? Then don't use them. The whole point of full backward compatibility is that you don't have to use new features. This perceived need to always use the newest feature is only in the head of some developers.

Neither in the blog post nor here do I see any reason to not make the experience better for people who want it. Even if it's just a "minor" (very subjective, I love the match ergonomics enhancements) annoyance that's fixed by it.

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.

> I believe there is a larger group of Rust programmers

Is there ? This is a genuine question - I've tried rust back in 2013 and have been following it from the outside not using it for anything serious since I haven't had a use case. My impression is that it's still a niche language with and their user base seems to be very involved and engaged. It don't have the impression that there are a lot of companies that are "just doing their job with Rust and not making a lot of noise about it" - if a company is using Rust for something it's probably writing an engineering blogpost about it and the guy who spearheaded it is probably active within the community. I'm just basing this on the amount of Rust posts vs the amount of Rust use/job postings in those quiet, doing their thing companies.

But that's my point - I knew about every one of those except discord just by following Rust marginally. Also Microsoft and Google etc. reported using it for various bits and peaces.

My impression is that if a company does something in Rust there's going to be blogposts about it and the engineers involved are active community members.

OP argued that there is a silent majority working along on Rust as is and getting caught unexpectedly with the changes - I'm just not seeing that.

It's a legitimate question. I can't be sure there is such a silent majority. I do know there are a dozen people using Rust at my company, none well-known, and we haven't blogged about it or publicised it.

> My impression is that if a company does something in Rust there's going to be blogposts about it and the engineers involved are active community members.

You must recognise that this is pure availability bias, right?

>You must recognise that this is pure availability bias, right?

I'm comparing to stuff I hear from local dev community and job postings - but again this is just my impression - I'd like to see some actual stats on this .