I have the exact same feeling. There's a lot wrong with Go, but it makes up for its problems by having very nice tooling (though of course there's problems with that too).
I have the exact same feeling. There's a lot wrong with Go, but it makes up for its problems by having very nice tooling (though of course there's problems with that too).
But the fact is, in a world where we as developers often are learning and working in a new language every year or two, time-to-productivity and proficiency in a given language is one of the most important, if not the most important, metrics for a language. And Golang knocks this out of the park with its obvious syntax and great tooling. You can bring in a new junior programmer onto your Golang stack and have then turning out useful pull requests in a week or two, which I can't say for languages like Rust.
I _hate_ much of Golang's engineering, but for collaborative programming I think anyone would agree that it's a highly productive language.
Now for a new product that I might sell as traditional installed software, Go makes some sense here since it simplifies install. My clients wouldn't need to install and maintain the VM.
In the end I wonder why switch to a new stack just because? I understand learning the languages to see if they are better tools. I understand learning for the sake of learning. But why bet a business on a new language just because it's cool?
Standing up the app is also instantaneous. Spring boot apps with hibernate often take at least ten seconds. In prod this doesn't matter. But a cheap app start means integration tests are cheap. An fs hook runs both unit and integration tests every time the code changes.
ps. all the things people hate about go are true
If I write a Go server, I'm unhappy if it takes more than 0.2 seconds to start.
My dropwizard server contains almost all possible batteries: ssl, logging, http filters, static content, metrics, DB connection pooling, static content serving, all kinds of URL parameter parsing and URL routing, DI framework, ORM, thread pooling. I think it just inspects and initializes all this data structures in memory, load libraries and classes, etc.
Why should they?
One can always deliver everything together.
Not much different than static linking.
Also there are AOT compilers and with Java 9 we are getting a linker to create customized JREs.