This gets pointed out by somebody in the comment section under every Rust update. The trope that Rust is getting harder to use is tired, and not really based in reality.
And while its fine for high level scripting languages like Python, because the whole idea is to abstract a lot of the functionality into the syntax, the issue with Rust is that its trying to be the next C and be applicable for writing critically important pieces of software like parts of the linux kernel. You absolutely must have a locked down language set for this. The reason C is still used for the kernel isn't because of circumstances, its specifically because there is very few ambiguities in the core language.
Which of the features in Rust 1.63 adds a divergent way of doing something you could already do?
> The reason C is still used for the kernel isn't because of circumstances, its specifically because there is very few ambiguities in the core language
What are some ambiguities in the core Rust language?
You don't need a "locked down" language to build an OS. In fact Linux just upgraded the version of C they use to C11. Time always marches forward, my friend.
The first is a new library function that takes a closure as the parameter. This function has existed for as long as Rust has been 1.0 in the crossbeam library, it's just now also in std.
The second change is a new api type.
The third change is a library change to increase flexibility of that library.
The fourth is arguably a bugfix, where existing syntax could not be used in an edge case.
The fifth is unifying the compiler implementations so that some types of patterns now work in code using the oldest compatibility mode that previously only worked in more current modes.
I'm not sure it would be realistic to totally stop adding features to the standard library, or to stop making existing syntax work the way a Rust user would expect. I would hope that any actively maintained language does things like these.
You might have a point though in a few releases when GATs are stabilized. I'll keep an eye out for your username complaining about that release ;)
but it's also true that there are quite a few threads that are conceptually simpler than GAT and are just left unfinished.
and there is a very serious push (or pushback with regards to GAT) to keep those promises.
https://github.com/rust-lang/rust/pull/96709#issuecomment-11...
For example, it seems as though "Word".contains(char::is_ascii_lowercase) should work, because after all "Word".contains(char::is_lowercase) works and char::is_ascii_lowercase exists and does what you expect, the same but for ASCII only.
However, for compatibility reasons char::is_lowercase takes a char, while char::is_ascii_lowercase takes a reference to a char, and so you can't just pass it to contains() and will need to write a closure to pass to contains to do ASCII instead.
Writing the closure is ugly, but it's nowhere close to how awful a compatibility break would be so even a million things like this (and so far maybe I can think of a dozen) aren't worth it.