This isn't slow.
Java went three years, from December 1998 to February 2002, without any language changes. And to be honest, even that wasn't that slow!
> Every addition to the language is bikeshedded to death
Not to death, because many of them don't die!
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.
I think the root of the problem is that the changes are driven by a small core of Rust programmers - many working on Rust itself or some of its flagship projects - who are actively involved in the discussions around Rust. They tend to view change as natural, and the cost of change as low. I believe there is a larger group of Rust programmers who are not actively involved in these discussions, and are maybe not spending 100% of their time on Rust, for who the cost is higher. But we don't hear as much from them.
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.
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?".
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.
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.
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.
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.
Or the worst of all possible worlds -- pulling in a macro-based framework
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.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.
• 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.
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.
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.
> 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?
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 .
There was a huge rush to use classes, which was sugar around the prototype system, but happened when we also got spread operators, Object.assign, and property name shorthand. We could already easily express the concept of a class far more easily than we were doing before, but because it all came out at the same time it didn't really click for the community at large and a lot of what became idiomatic didn't really feel important enough for a language update.
Ditto with generators and async functions, which while merely a very specific application of a generator is far better known. Again, not sure we needed all this extra syntax so you can say `async function foo() { await bar()`, when `co(function* foo() { yield bar()` was already available (if co were simply added to the Promise object). We're also now tying the language to a very specific implementation, when the co approach is explicit about saying what's responsible for taking control from the yielded function (a Promise).
This should be the norm for serious programming languages. Anything else is a hyperactive children's toy.
Also, I think C might be the only language to get 1.5 features/decade. Fortran has seen a lot of recent editions, and so has Java. Even x86 gets new instructions every arch bump. Are there any other languages that change as slowly as C? If not it may be too elitist to claim that there is only one language in the world that's not a child's toy.
ANSI Common Lisp has had the same spec since 1994.
(This is not a problem, because Common Lisp gives you enough high and low level power to do (almost) whatever you want in user space, instead of relying on the language designers to add a particular feature.)
To be honest, programming language design has been a solved problem since the 1950s when LISP came out.
PL design is not a problem to solve, it's the study of the way to express problems and their solutions. As long as their are new problems and ways to solve them, we'll find new ways to improve PL designs.
It also applies to the recent "Why I'm Leaving Elm" article. https://news.ycombinator.com/item?id=22821447
Part of the struggle depicted in the article is between user defined language extensions "competing" with the upstream compiler.
That's exactly a social problem that becomes a technical problem in Lisp.
Instead of starting with a fat standard library, it started with minimal one and now each release adds 2-3 functions that could have been there in 2015. But none of it is idiom-changing revolution. These are mostly convenience functions, and you don't have to use them all just because they're there.
Every addition to the language is bikeshedded to death, goes through betas, revisions, refinements, before being stabilized years later. The first experimental release of async was 4 years ago and it has landed last November. So you may hear about new features a lot and they churn in nightlies, but actual big changes reach stable rarely.
Apart from async/await, since 2015 Rust made only 2 changes to how idiomatic code looks like (? for errors, and 2018 modules), and both of them can be applied to code automatically. I maintain over 60 Rust crates, some of them as old as Rust itself. All work fine as they are, and running `cargo fix` once was enough to keep them looking idiomatic.