There is surely some "law" in some place of the internet that says something like: "Every programming language valid construction no matter how ugly, obscure,verbose,old,etc will find its way to lots of codebases". See C++.
Yes, John Carmack has said as much, at least in the context of syntactically and semantically valid constructs that are actually bugs making it into codebases. What does that have to do with let chains and let else?
The problem are not the new traits per se. The problem is that the complexity of a language grows super-linearly with the number of things added to it. There is beauty (and productivity) in simplicity. When you need to do 2 things and there are 2 ways of doing each, now you have 4 different combinations. All languages are more or less guilty of this (even those which promise "Just 1 way to do things") but it is undeniable that Rust is joining C++ in the right side of the complexity Bell curve.
let else and let chains aren't new traits, they are syntactical features that make things that people would expect to work, Just Work™. People keep bringing up the complexity of Rust (a valid argument to be made there) but then point at some feature that is removing an arbitrary limitation from the language. And even for cases where a new feature is being added, I can point at the case of ? for error handling that was a new feature, that "complicated" the language, but that very clearly improved the ergonomics of the language for reading and writing. Should ? have been left in the cutting floor because it didn't look like anything else and was a "redundant" feature?
Let me put it another way: what Rust feature would you remove to "simplify" the language?
As I pointed here originally, you need to be very careful about what you ADD to a language, because once the cat is out of the bag there is no going back, people are going to use that stuff. That's why I dont begrudge the attitude of the golang maintainers to be very slow in introducing stuff, because it is basically an irreversible step.
I suppose every thing in Rust has a raison d'etre but you pay with complexity that versatility. I think there is space now for a modern, memory-safe, SIMPLE, systems programming language. C has the backwards compatibility problem (although I am still bullish on its future) and a language like Zig never got any traction. Hopefully the future will bring new, interesting stuff.
As far as I can tell, Go was kinda rushed, and they called it 1.0 before they get to add the generics it obviously needed. And I bet adding those generics in a way that preserves backward compatibility was a bear.
