The real reason it was removed in the end was just that it elevated a library concept into syntax. Today's Arc<T>/Rc<T> split isn't really possible in an @T world, for example. Shared ownership is a good concept, but you don't need special syntax to indicate it.
Rust still does this in all sorts of silly ways, such as the ! type. What's the point of wasting an entire symbol that could have plenty of alternate uses on something that's so rarely used and could easily be defined as either a library type (empty enum) or at least be given a custom keyword, such as `never`? (Introduce it over an edition boundary, if you must preserve backwards compatibility.) The fact that it involves some compiler magic is no excuse; that's why Rust uses "langitem" markers within its core library.
I certainly don't disagree that Rust has flaws, for sure. I think this particular one is pretty far down the list, though. I'm not sure what else I'd want to use ! for, and by virtue of it not being used so often means that it's much less of a pain than @T would have been, though I would also argue that 2012 Rust used ~T and @T far more than contemporary Rust does (I still remember pcwalton's mailing list post about how you didn't have to use ~ for comparing strings!) and so was even more painful at the time than would be now.
Most languages only have one kind of pointer, and they tend to use & and * as operators for them.
```
export function never(message?: string): never {
throw new Error(message ?? 'Reached an impossible state');
const [foo = never()] = dbQueryThatReturnsOne();
```
I guess it's en par with .unwrap()
I would argue as a rule of thumb, anyone who focuses on syntax over semantics has little to contribute until they write ten thousand lines in the language. Perl is a great example of how it still fails after this test passes. Rust feels a lot more like java and c++ now, and not in a good way. It could have done more to improve on basic readability than where we ended up, and people still bitch about basic tenets of the language like "lifetimes" and "not being enough like java".
I also agree that you can’t listen to everyone, but this feedback was loud and pervasive.
Of course syntax is important. Otherwise people wouldn't complain about perl or C (eg wrt lack of operator overloading). It is just important in balance with semantics. And while I understand why rust compromised on this, IMHO it was a mistake that causes confusion about rust's memory management strategy. It looks too much like java and not enough like a language built around specific memory management paradigms. This compromise has backfired.