Graydon Hoare

I disagree with you here - unless you want all the rust programmers to switch to a new language, there *need* to be changes and updates, and perhaps even entirely new paradigms. A stagnant language is a dead language, imo. Does Rust want to be C++/OCaml, or C/SML?

If you are asking me and not Rust-at-large, I’d say the latter. Disagree with characterization of change vs. death. That’s an analogy from natural language drift that doesn’t apply here. Lots of widely used and liked languages are effectively frozen.

I agree with your desire to stop adding complexity, but I also think not being frozen is still part of rust's appeal

Pretty directly disagree here. Any churn beyond a very narrow sense of “completing things promised long ago” is doing more harm than good wrt. industrial use.

I don't think that this is an opinion which is supported by the available evidence - Java and C++ are continuously evolving, and you don't see enterprise giving up on them. The most important thing is the commitment to making old code continue to work, not stifling innovation.

Others: C, Python, ObjC, PHP, Go, R, SAS, Sh, Matlab, Ruby, VB, Delphi, PL/SQL, Erlang, yes Cobol, Lua, ABAP, Fortran… Open a job board outside silicon valley, people hire for stable languages. Even within those changing, most codebases lock to an old standard (eg. C++03)

I only really know about three of those languages - yes, C isn't evolving. Python is evolving pretty quickly, though, and COBOL is still evolving at a slower, but still reasonable pace. There was a giant paradigm shift in 2002 - I don't see banks giving up on it b/c of that ;)

I’m sympathetic to that feeling, but there’s some stuff that is really important, like async/await. I/O story isn’t complete without it.

I know. The story there is so long and awful I wouldn’t dare commemt (cf. “three runtimes”); and I know there’s a need to finish const-eval and macros since these were on the table from day one and never finished. The rest I’d put on ice. Wait a few years. Measure twice.

("Approaching an asymptote" is a nice way to put it! Sounds like the same thought which I tend to think as, "not growing the feature space, just filling holes in it".)

(Or the bounding box of the feature space, maybe I should say...)

Narrator: “The feature space was non-Euclidean and each feature had a surprising Minkowski dimension.“

The various planned breaking changes to the language in the name of ergonomics are damn scary.

Like what?

Module changes, `mut` being implicit in some circumstances, argument-bound lifetimes, the `T throws E` proposal (not planned yet though, fortunately), etc…

Most of these are simplifications though, honestly.

I don’t share the concern. I remember lots of similar concerns around things that were totally uncontroversial now; e.g. “none.” vs. “None”

Or capture clauses. This is actually a very similar situation to capture clauses, and it ended up not mattering at all.

That's because we have `move` for closures that capture. That's completely unrelated to reading code and not even knowing if a value was moved or not. I do know from my own experience that I rely on all those visual cues a lot. "none" vs "None" is entirely offtopic.