3 ms·

Go produces static binaries, so it isn't really needed for production environments would be my guess. Devs tend to install upstream tools instead of the out of

Go produces static binaries, so it isn't really needed for production environments would be my guess. Devs tend to install upstream tools instead of the out of date RHEL tools too.

jake_the_third 8y ago
> Devs tend to install upstream tools instead of the out of date RHEL tools too. and system administrators tend to install packaged tools instead of upstream tools that aren't tested to play well with the rest of the system. Perhaps installing directly from upstream makes sense for Go, but the servers I maintain either run distro-packed software or custom software. Too many bad experiences with upstream packages to trust on production.
- Skunkleton 8y ago
  That was my point. If you are deploying a golang based application, there is nothing to install other than the binary produced by the dev team.
- ulzeraj 8y ago
  Go applications do not need golang itself installed like a python or ruby. You can create the binaries on any machine and just ship the executable and it’s assets if applicable. The binary is static and contains everything it needs to run. Using grafana and influxdb as an example which might be familiar to sysadmins those packages do not need golang installed.
cyphar 8y ago
This isn't true. Yes, Go packages are all statically compiled into a single binary (so you don't have a separate .so for each import path) but the actual binaries haven't been statically linked by default (or at all in some cases) for a very long time. For instance -- Go has to link to glibc, and glibc doesn't provide proper support for static compilation (you _can_ do it but it's not actually supported in the RHEL sense by glibc upstream). And even when you force Go (through several magic incantations) to give you a static binary, networking and similar code will still use NSS (which uses dlsym and thus still requires dynamic libraries on the host to be installed).

Go produces static binaries, so it isn't really needed for production environments would be my guess. Devs tend to install upstream tools instead of the out of date RHEL tools too.

jake_the_third 8y ago

> Devs tend to install upstream tools instead of the out of date RHEL tools too. and system administrators tend to install packaged tools instead of upstream tools that aren't tested to play well with the rest of the system. Perhaps installing directly from upstream makes sense for Go, but the servers I maintain either run distro-packed software or custom software. Too many bad experiences with upstream packages to trust on production.

Skunkleton 8y ago
That was my point. If you are deploying a golang based application, there is nothing to install other than the binary produced by the dev team.
ulzeraj 8y ago
Go applications do not need golang itself installed like a python or ruby. You can create the binaries on any machine and just ship the executable and it’s assets if applicable. The binary is static and contains everything it needs to run. Using grafana and influxdb as an example which might be familiar to sysadmins those packages do not need golang installed.

cyphar 8y ago

This isn't true. Yes, Go packages are all statically compiled into a single binary (so you don't have a separate .so for each import path) but the actual binaries haven't been statically linked by default (or at all in some cases) for a very long time. For instance -- Go has to link to glibc, and glibc doesn't provide proper support for static compilation (you _can_ do it but it's not actually supported in the RHEL sense by glibc upstream). And even when you force Go (through several magic incantations) to give you a static binary, networking and similar code will still use NSS (which uses dlsym and thus still requires dynamic libraries on the host to be installed).