[threeseed]

What is with Go supporters ? I don't understand why if I don't use Go then I am not solving real world problems and instead building over engineered monstrosities. Working in the enterprise features like exceptions and generics makes it easier to ensure consistency across the platform and our 20+ developers.

[tagrun]

> What is with Go supporters ? I don't understand why if I don't use Go then I am not solving real world problems and instead building over engineered monstrosities.

What is with you? The article is talking about languages, not the category of problems people are trying to solve using those languages. (In principle, NASA could have written the Mars rover code in brainfuck).

> enterprise features like exceptions and generics

What is an "enterprise feature"? Sounds like a Java-world word though.

I also don't understand how generics and exceptions "ensure consistency across the platform".

[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.

[oakwhiz]

>What is an "enterprise feature"?

I think what the grandparent poster meant to say was:

>Working in the enterprise, features like exceptions and generics make it easier [...]

[shadowmint]

come on, thats a bit hyperbolic isnt it?

There are plenty of go fanboys out there who will rage about go getting any kind of criticism, but this was a really thoughtful take on why go is a good practical language despite the problems.

[jbergens]

They probably mean that you are solving problems, real world and other, but you don't really need features like generics to do the "real world" part. Their proof is in things they have done, projects they have completed. If more projects and developers tried to use Go they might also find that a lot of projects can work with Go. Regarding the 20+ developers I am pretty shure Google has Go projects with many developers. I also think they were clearly targeting enterprise projects. Google is a huge enterprise with huge programming projects.

[zackbloom]

I can give you insight into my perspective. Go has made programming better. It is genuinely easier to build reliable things in Go than in Java or C or Python (from my experience). I didn't know that, until I invested a good amount of time building things with it, souly because everyone seemed so enthusiastic.

It's fine to say for economic or organizational reasons you're not moving to Go, but don't say it's because you need exceptions or generics unless you've spent a serious amount of time trying it the other way.

[anonymoushn]

Whoa now, one of the few good things about Go is that it doesn't have exceptions.

[Pxtl]

That incessant repetition of error-handling boilerplate shown in the article is not an argument in favor of this approach.