|
|
|
|
|
|
by prodigal_erik
3392 days ago
|
|
|
Java was adopted very rapidly (as soon as it ran acceptably on commodity hardware) because the industry desperately needed a safe subset of C++. The pain point addressed by Go is mostly deployment and packaging, which is why mostly devops (who have rejected OS packaging for some reason) are excited about it. |
|
|
What happened to OS packaging was mostly a result of the arcane tools around .debs and .rpms, which led to sysadmins reinventing the wheel (poorly) using symlinks, tarballs, and shell scripts.
FPM helped to a great degree, but even then, what if you want two different versions of the same application on the same machine? And if you hack your way around that, how will you manage which instance of the application gets which port?
When Docker came out, that kind of ended the idea of using OS packages for deploying in-house applications. Why bother with a packaging infrastructure that will only tie you to a certain OS?
I still think OS packages have a place, especially for system level software. Nobody ever complains about how SSH failed to install or upgrade...
But even when using containers for internal software, Dockerfiles can still be a pain to deal with for the simple reason that most languages have horrible build-chains that produce unusable outputs, which as you said Golang addresses beautifully.
However I think you're off the mark when you say "mostly devops" are excited about it. It's entire companies that are excited about it, and for one simple reason: Languages with these bad build chains and bad outputs have led to the creation of an entire teams of people to deal with it.
The realization of this is spreading, and it's going to be an interesting time.