[threeseed]

From the article:

"Go feels under-engineered because it only solves real problems" "and so you build real solutions rather than finding excuses to use your beautiful tools"

The implication from reading the article is that those of us that rely on those so called exotic features aren't doing so for serious business and technical reasons. And it seems to be a common thread amongst many Go users.

And generics allow you to reuse existing components much cleaner and exceptions allow you to handle errors in a consistent way across the system. You can build error handling classes but often handling errors explicitly doesn't scale.

[lowboy]

I read that to mean that other languages can solve both real and "non-real" problems, those where one can try ones tools for the inherent joy of using them, but that Go probably doesn't inspire one to do the latter and focuses solely on the real problems.

[tagrun]

> The implication from reading the article is that [...]

The implication you inferred from reading the article is that...

I think there reason is that there a misunderstanding here caused by a cultural gap. The Practice of Programming is a very good read which I feel like recommending to every programmer.

> And generics allow you to reuse existing components much cleaner and exceptions allow you to handle errors in a consistent way across the system.

Although I don't think "exceptions allow you to handle errors in a consistent way" (based on my long and still on-going experience with C++), I still don't see how exceptions and generics "ensure consistency across the platform".

> You can build error handling classes but often handling errors explicitly doesn't scale.

You don't build error handling classes in Go.

[anonymoushn]

> You don't build error handling classes in Go.

I've encountered people doing this. When I said "If I had Maybe here then I could write 1/5 as much code," someone showed me a class that maintained whether it had encountered an error, and each method would do nothing and return the previous error if so. This allowed him to write 1/5 as much code in the method that actually does stuff, just as he would in Haskell or Swift. Unfortunately the approach of reducing every function full of noisy error checking to a bunch of calls on one object is pretty bad in general...

[pjmlp]

> You don't build error handling classes in Go.

That much is true, you compare strings!

[enneff]

Or do type assertions.

[pjmlp]

Ah ok, that is a better approach.

[ahuth]

I don't see that implication at all.