So much of language opinion is based on people's progression of languages. My progression (of serious professional usage) looked like this:

Java -> Python -> C++ -> Rust -> Go

I have to say, given this progression going to Rust from C++ was wonderful, and going to Go from Rust was disappointing. I run into serious language issues almost daily. The one I ran into yesterday was that defer's function arguments are evaluated immediately (even if the underlying type is a reference!).

https://go.dev/play/p/zEQ77TIP8Iy

Perhaps with a progression Java -> Go -> Rust moving to rust could feel slow and painful.

Go is definitely of the “worse is better” philosophy. You can basically predict what someone will think of Go if you know how they feel about that design philosophy.

I remember that famous rant about how Go’s stdlib file api assumes Unix, and doesn’t handle Windows very well.

If you are against “worse is better” like the author, that’s a show stopping design flaw.

If you are for it, you would slap a windows if statement and add a unit test when your product crosses that bridge.

The problem is that most of the time, errors are not to be handled but only bubbled up. I've also seen it in Java with checked exceptions: the more explicit error handling is, the more developers feel they should somehow try to do _something_ with the error when the correct thing to do would actually be to fail in the most straightforward manner. The resulting code is often much heavier than necessary because of this and the stacktraces also get polluted by overwrapping.