Go did rise to prominence by being the programming language behind such high profile software as Kubernetes, Docker, and Prometheus. None of those are business applications and Rob Pike (ex Bell Labs guru and co-inventor of Go) gave a presentation about Go in 2015 where he explicitly identified that Go was invented for infrastructure and not business applications.
I have encountered many engineers who are excited about Go and want to adopt it for enterprise systems. In 2019. I evaluated Go for that purpose. You can read my evaluation at http://glennengstrand.info/software/architecture/microservic...
What I discovered is that Go is not any faster than Java on a light weight framework. Here is the part that may seem controversial for the folks here. The simplicity of Go did not result in simpler systems.
I found that the lack of inheritance hampered me in expressing solutions to complex business rules and data models. Many of you may disagree with that and counter argue that inheritance is a bad thing. That is most probably one reason why there is so much interest in Go. It intentionally lacks support for inheritance. I agree that inheritance can and has been misused a lot. It is an advanced programming language feature that should be used sparingly. Removing inheritance entirely reduces the expressiveness of the programming language, especially when it comes to enterprise computing.
> The simplicity of Go did not result in simpler systems.
I echo this 100%. I worked at an employer who heavily used golang. The resulting projects were honestly a mess, yet they pushed through.
What's ironic, is that they ended up reinventing the wheel on so many different things, including DI and an entire application framework. Millions of dollars spent writing and maintaining these libraries, where Java already had them ages ago.
As you point out, the modeling capability of golang is extremely subpar. It results in verbose code that is very sparse, lots of code to implement something that would have taken a few lines in a language like Java and C#, let alone something more dense like Scala.
The way interfaces are handled in golang makes it very annoying to try to find out which types implement said interface. It puts a lot of pressure on the IDE to search the entire code base, and you end up with types you don't even care about. It clearly shows that the golang authors did not have IDEs in mind when writing the language, which is just absurd as it's supposedly a language designed for "programming in the large". Anyone who used "goland" knows what I'm talking about. Try refactoring a type, and have the IDE scan the entire code base to look for comment strings, which it has to because golang has no notion of doc strings like Java or C#.
Add features like records, pattern matching, enums (the amount of code that had to be written to implement something to emulate enums was just absurd and frustrating to deal with, not to mention error prone).
The concurrency aspect of golang is decent (though it will be even better in Java). Other than that, the language doesn't really have anything going for it other than having a large brand name backing it.
> I worked at an employer who heavily used golang ... they ended up reinventing the wheel on so many different things, including DI and an entire application framework.
Sounds like they were trying to force the language to be something it's not. DI frameworks (I think what you mean) are basically incoherent in Go, dependency injection is naturally modeled with interfaces. In fact any inversion-of-control style "framework" is a mismatch to the language, it (intentionally) lacks the features that frameworks rely on to deliver benefits that outweigh their costs.
> The way interfaces are handled in golang makes it very annoying to try to find out which types implement said interface.
The desire to do this reflects a misunderstanding of interfaces.
Prior to DI frameworks we used global variables, often initialized in a package's init() method.
>The desire to do this reflects a misunderstanding of interfaces.
Generally you have a few layers: gRPC/HTTP/Kafka handler, business logic, and database or external service access. Layers are unit tested individually against mocks of the layers below. Because you're going to inject a mock, you can't depend on a concrete type, so you depend on an interface. Often when you're developing you want to know what the concrete implementation of a lower layer does, so it's useful to have "go-to-definition" see through the interface declaration to its implementations.
I think the implicit satisfaction of interfaces is very cool and I wish I had it in every language. I wouldn't give it up just to simplify the IDE's job. But the IDE having this functionality does matter.