Why is Go so popular in the industry at the moment? What's the decision process for choosing Go?
I can't speak for the industry, but here's why I chose it for this project:
* I hadn't yet written anything in Go and wanted to try it on a side project / experiment
* I knew that my eventual deploy target (if the project turned out useful) would be lots of machines and I wanted to minimize the deployment requirements. Static binaries are good for that.
* I wanted to distribute the work across many cores and felt that Go's channels would make be a useful mechanism.
* I benchmarked my initial PoC against some other implementations (Python and JVM/Scala) and found no major reason to not use Go
The contributions of Stephen Jung (https://github.com/tummychow) and Aditya Mukerjee (https://github.com/chimeracoder) elevated it from a glimmer in my eye to system you can trust across your infrastructure.
So, in summary it was a confluence of interest and convenience with a strong hint of "if I use, this, it needs to be easy to deploy" and here we are 2 years later. :)
Its build system is poor if you want to rebuild the binary from the same sources (you can't precompile the libraries used), and the statically linked binary may be nice for a one-off deployment ("fire and forget" mode), but for repeated deployments and multiple versions running at the same time it reminds me the Chinese torture "death by a thousand cuts" in what you can't do with such a binary (dozens of small things that are hard to remember, each on its own not being enough to go away from static linking, but boy, they do add up).
And then there's also sharing memory between different processes that use the same library. You don't have that for a statically compiled binary.
It's not something to regularly rely on, but something that helps in debugging and troubleshooting. Not for a programmer, but for a sysadmin.
> Having shared objects on the machine actually makes this impossible because your tests are running with different libraries than in production.
In such a case you have your deployment process broken. And if your testing and production environments differ in this matter, they differ enough bite your ass even with your statically linked binary.
> Shared libraries on a machine are a non-hermetic input to your build and are to be avoided.
This is merely stating a generic opinion. I want to see a concrete, coherent, technical argument supporting this.
> In addition, runtime shared objects (especially of something performance-critical like crypto) inhibit all of the most important compiler optimizations like inlining.
Especially crypto should not be called in a tight loop, but passed a large chunk of data. Otherwise you inhibit all of the most important defence against side channel attacks, and I guarantee that you are not competent enough to defent against that on your own.
> As for ltrace, there's a million ways to trace function calls these days, like uprobe or perf.
So let's break one of them for no good reason?
And still, lack of any of the mentioned things is merely an annoyance once you hit it, but as I said, they are numerous and add up, while the other option, static linking, provides little benefit apart from supporting broken workflows (like different environment in testing and production).
I didn't imply that it shouldn't be.
I am genuinely interested to know the thought process and why it seems to be the defacto language these days.
Your arguments are strong, thanks.