Perhaps I've never hit the problems that go solves? I just don't understand why I'd learn it when it offers nothing new or unique and feels even more clunky to work in than alternatives.

Specifically for me, I know enough poorly-typed lanagues that I want to be learning and using languages that offer me a good type system to express my program in, and not just jump through hoops to get things to work with no large benefit or reduction in code (and do when I get a chance).

I get coroutines are cool, but they don't really seem to solve the problems I have with concurrency. They feel like baked-in message queues.

Go solves a very specific problem: the limitations of Python, CPP, and Java within Google. That's it. Google maintains control over the constructs within it in order to standardize its (Google's) code. When only Google's code matters, there's no rationale for things like including generics and or consensus standardization via ISO.

That's not to say Go is bad. There can be a lot of overlap between the type of problems Google designed Go to solve and the types of problems other people and organizations often have. A lot of people write systems code. A lot of people experience the limitations of Python, CPP, and Java. Not everyone of course. I mean to me, the Go ecosystem looks so much like an "enterprise" decision that it would be mocked by the very people using it if Go came from IBM or Oracle.

> the limitations of Python, CPP, and Java within Google

What Java's limitations Go solves exactly?

At the minimum, the verbosity problem. We can argue that any language is less verbose and more concise than Java.

Go is inherently not a OO language and has some excellent functional constructs which makes it easy to approach and solve certain set of problems whereas in Java you are forced to do the OO way even if the problem at hand does not require that way of solving stuffs.

Finally, Go compiles to machine code and I guess it should be way faster than Java.

> At the minimum, the verbosity problem

I don't believe a single second that Java is more verbose than Go. It's just that Go hasn't been buried under layers and layers of EE ...yet. In fact the whole "if err!=nil" boilerplate is the very definition of verbosity.

> Go is inherently not a OO language

Everytime you use interfaces you are doing OOP. And there is no choice but using interfaces when dealing with streams, which is 99% of what people use Go for.

> has some excellent functional constructs

No more than the latest Java. In fact Java has something Go definitely doesn't have which is pretty useful for functional programming: generics.

> Finally, Go compiles to machine code and I guess it should be way faster than Java.

AOT compilation is coming to Java.

I have a hard time buying that EE cruft will creep into Go -- it specifically guards against inheritance/factory/DI hell by offering a unique type system (enforcement of clean interfaces between packages).

If you try to implement Java-like design patterns in Go then you're going to have a bad time -- personally this is one of its strengths.

Many people, including Google engineers (https://github.com/google/guice) see DI as useful tool, not hell. But nothing prevents you to write your java code without DI if you don't like it.