[grepexdev]

I don't think Go is particularly esoteric to where these "gotchas" are a big problem.

In fact, I would argue that the gotchas are an intentional part of Go's design philosophy. I think it is strange to work in Go when coming from another language because of this, which leads people to think Go sucks.

[9rx]

That may be part of why they think Go sucks, but it is mostly because Go doesn't have many features to paper over poor design decisions. "Advanced" languages let you throw any old gobbledygook at them, and when you finally realize you screwed up, you can just monkey patch (or whatever feature of the day the language has) your way out of it and call it a day. Go is far less forgiving. You have to get the design right or pain will ensue. And pain does ensue for those who try it after being accustomed to having leeway in haphazard design, and thus they conclude Go sucks instead of acknowledging that their design sucks.

I mean, Go does suck. Maybe a language should be accommodating to bad designs. But still, those shouting "Go sucks" from the rooftops never seem to be willing to bring introspection into where they might have failed. It's always someone else's fault. (Something not limited to the case of Go, of course)

[ninetyninenine]

Go sucks not because it's accomodating to poor designs. It sucks because it is in itself poorly designed and that leaks over to the design of entire applications.

Why have functions return err, nil? Why even allow for a runtime error here? It's a really simple fix. You don't even have to make the language complex to support this. Instead the entire program is littered with holes and if statements you have to check in order to prevent a actual crash