5 ms·

Why is Go so popular in the industry at the moment? What's the decision process for choosing Go?

ebikelaw 8y ago
I doubt anyone can answer this for you, but why shouldn't it be? It is a very sensible language and toolchain. When writing source, it is easy to write tests and testable code and to run the tests as part of your build. At build time, it's fast and it produces easy-to-deploy statically-linked applications. At runtime, it's pretty fast and compact ... compared to python, Go is most of the way to C++-level performance.
- noncoml 8y ago
  > why shouldn't it be? 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.
- dozzie 8y ago
  > I doubt anyone can answer this for you, but why shouldn't it be [popular in the industry at the moment]? 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).
  - ebikelaw 8y ago
    Can you remember even one? I'm interested. I've used Go at Extremely Large Scale (tm) and never thought it was terribly troublesome.
    - dozzie 8y ago
      Sure I can remember. Checking libraries the binary uses ("why this cURL fails on HTTPs? oh, it's linked against GnuTLS, that explains everything"), injecting your own library, intercepting a function (maybe syscall, or rather its libc wrapper), tracing function's execution (ltrace). All these things merely annoy if you used to have them but now you don't and it's hard to remember them all, but there's a lot of them. 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.
      - ebikelaw 8y ago
        All those things sound like antipatterns to me. If your application is supposed to fetch HTTPS pages then there should be an integration test for that, so you would never have to debug it in production. Having shared objects on the machine actually makes this impossible because your tests are running with different libraries than in production. Shared libraries on a machine are a non-hermetic input to your build and are to be avoided. In addition, runtime shared objects (especially of something performance-critical like crypto) inhibit all of the most important compiler optimizations like inlining. The savings from sharing text segments is small in my experience. As for ltrace, there's a million ways to trace function calls these days, like uprobe or perf.
        dozzie 8y ago
        > All those things sound like antipatterns to me. If your application is supposed to fetch HTTPS pages then there should be an integration test for that [...] 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).
gphat 8y ago
Hello! I'm the original author of Veneur @ Stripe and continue to work on it with a host of marvelous teammates. 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 https://github.com/tummychow) and Aditya Mukerjee (https://github.com/chimeracoder 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. :)

I doubt anyone can answer this for you, but why shouldn't it be? It is a very sensible language and toolchain. When writing source, it is easy to write tests and testable code and to run the tests as part of your build. At build time, it's fast and it produces easy-to-deploy statically-linked applications. At runtime, it's pretty fast and compact ... compared to python, Go is most of the way to C++-level performance.

noncoml 8y ago
> why shouldn't it be? 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.
dozzie 8y ago
> I doubt anyone can answer this for you, but why shouldn't it be [popular in the industry at the moment]? 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).
- ebikelaw 8y ago
  Can you remember even one? I'm interested. I've used Go at Extremely Large Scale (tm) and never thought it was terribly troublesome.
  - dozzie 8y ago
    Sure I can remember. Checking libraries the binary uses ("why this cURL fails on HTTPs? oh, it's linked against GnuTLS, that explains everything"), injecting your own library, intercepting a function (maybe syscall, or rather its libc wrapper), tracing function's execution (ltrace). All these things merely annoy if you used to have them but now you don't and it's hard to remember them all, but there's a lot of them. 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.
    - ebikelaw 8y ago
      All those things sound like antipatterns to me. If your application is supposed to fetch HTTPS pages then there should be an integration test for that, so you would never have to debug it in production. Having shared objects on the machine actually makes this impossible because your tests are running with different libraries than in production. Shared libraries on a machine are a non-hermetic input to your build and are to be avoided. In addition, runtime shared objects (especially of something performance-critical like crypto) inhibit all of the most important compiler optimizations like inlining. The savings from sharing text segments is small in my experience. As for ltrace, there's a million ways to trace function calls these days, like uprobe or perf.
      - dozzie 8y ago
        > All those things sound like antipatterns to me. If your application is supposed to fetch HTTPS pages then there should be an integration test for that [...] 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).

gphat 8y ago

Hello! I'm the original author of Veneur @ Stripe and continue to work on it with a host of marvelous teammates. 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 https://github.com/tummychow) and Aditya Mukerjee (https://github.com/chimeracoder 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. :)