No, it's just that a prolific rust contributor made a blog post and then a follow up and things have been heated in the community a bit (I lurk a bit).

The fuss isn't over what the syntax should be, but whether it should be changed at all. The proposal isn't even an RFC, just a blog post and some discussion threads. I think the proposal made good points about the ergonomics of error handling. I think the community might just be a little stir crazy with the quarantine, and talking about a syntax change that upends the much loved Result idiom rustled some feathers.

FWIW it is a purely syntactical change that adds sugar, the underlying mechanism does not change. The "hacks" for not having exceptions are strictly superior to having exceptions, at least in my opinion because the error monad is both opt-in on the caller side and opt-out on the callee, it does not include non local returns (errors don't cause the program to jump up the stack, like C++ exceptions, or any need to pass down the exception handler or pass up a continuation), they support all sorts of wonderful combinators that exceptions don't play nicely with, and unless explicitly disabled by a binary author the stack will always unwind and RAII patterns observed. The issues with exceptions are well documented.

Not it didn't. Rust error handling is glorious comparing to exceptions.

Rust community is just full of perfectionist and we love to argue endlessly about how to improve stuff even more, which is very refreshing. In many other PLs people just keep their heads down and crawl in the mud.

I think that's mostly because the end desire is to have them forced to be dealt with like java's checked exceptions, which most people have a problem with. It's hard to make forcing handling something easier for the developers, but I would argue its better than having unknown failure modes in functions you call.

Perhaps in terms of verbosity/tedium, but at least they don't have the problem of silently breaking functions between the exception thrower and catcher.