1. 18

  2. 3

    I’ve been finding Go really useful for sysadmin tools in my own deployments. While I haven’t been migrating any existing tools (mostly Python and Perl), I have been using it for almost all new tool development and haven’t run into many major pain points yet. I miss some of the libraries in PyPI or CPAN, but the advantages in ease of deployment and maintainable development have made up for it,

    1. 3

      Isn’t the disadvantage that you don’t get security patches on your dependencies without a recompile?

      1. 3

        You also don’t get security patches on your dependencies without an interpretation of Python/Perl/[dynamic language]…

        You have to download the dependency updates with both, with Go you just need to recompile at the same time. You could even write a really simple script to do that for you, too…

        1. 3

          Well, to get the security patches in the non-Go case, you would have to update the dependencies on all the hosts to which the tool is deployed. With Go, you would only have to update the dependencies on your dev machine, recompile, and redistribute the binaries. Those sound equally complex to me. The Go way of doing it is probably easier if you had an automated system in place to push the newly compiled tool to the servers. Plus, there might be breaking changes in the updates, and it’s easier to fix this once on your dev machine than worrying about whether all of the servers to which you are deploying have the correct version of the dependencies.

          1. 3

            Those sound equally complex to me.

            Security patches are much more streamlined in dynamically linked binaries. Let’s use a C binary using shared system libraries vs a Go binary as an example, both using a SSL library. A bug is found in libssl and patched.

            The security maintainer subscribed to CVE notifications compiles a shared library and pushes it out. Downstream machines automatically install security updates. The C program is patched relatively quickly.

            With Go / statically linked binaries, each developer has to be aware of the libssl vulnerability and recompile against the new library. Vigilant maintainers do this for packages they’re in charge of and file a bug report downstream.

            What was originally a single responsibility for updating security bugs is now distributed among maintainers and developers.

            1. 2

              Good explanation. Also, there is a possibility of a bug being pushed downstream with the C shared library. It’s a classic tradeoff between static and dynamic linking.