5 ms·

The number 1 selling point of something written in Go is that it's much easier to package. The result of a compilation is a standalone binary that can be copy-p

by rakoo 11y ago

The number 1 selling point of something written in Go is that it's much easier to package. The result of a compilation is a standalone binary that can be copy-pasted everywhere, as long as the architecture matches what was input at compilation time. This means: - no more having to deal with dependencies at packaging time, which makes packagers' job simpler because all they have to care is the one and only standard way to retrieve dependencies and build the binary. (Much like the standard way of doing things in C would be ./configure && make && make install, with the added bonus point that the dependencies are also taken into account). This also means that there's a higher chance that the software will be packaged in the distribution of your choice, because the bar is lower - no more having to deal with dependencies at runtime, because each binary has everything it needs inside of itself. In practice this means "scp as a deploying method". It's an even lower common denominator than packages. > If it doesn't come with a proper daemon mode (correct forking, PID file support, proper file or syslog logging), sample config file, man page, or an init file, that's even worse. This is orthogonal to the choice of programming language, though. On top of that, I believe the application shouldn't deal with forking, it's the job of your supervision system to deal with daemons. All an application has to do is log whatever happens on STDERR and let the system handle that.

veeti 11y ago
> This also means that there's a higher chance that the software will be packaged in the distribution of your choice, because the bar is lower Static linking and bundling of dependencies is a no-no in most distributions. If anything, the Go model is a headache for package maintainers to deal with.
pmelendez 11y ago
> no more having to deal with dependencies at runtime So, it is the same that linking the libraries statically? C and C++ has done that like since forever.
- StavrosK 11y ago
  Hey, if you said "written in C", I would be similarly excited about its ease of deployment.
- rakoo 11y ago
  Very true, I had python and ruby in mind. What Go makes different still is that static linking is mandatory.
- FooBarWidget 11y ago
  Have you ever actually tried producing a statically linked C/C++ binary? I've been programming in C/C++ for 10+ years. Static linking is a huge pain. My latest efforts have led me to create holy build boxes inside carefully controlled Docker-based environments just to be able to produce binaries that work on every Linux. With Go you can just run a single command to cross-compile binaries that work everywhere. Minimal setup required, no expert knowledge required.
  - pmelendez 11y ago
    > Have you ever actually tried producing a statically linked C/C++ binary? Many times actually, I prefer to deploy just one file whenever I can. > just to be able to produce binaries that work on every Linux That's a Linux design/decision thing. Linux binary compatibility is ... well ... challenging. In Windows is not hard at all (Not sure how is it in MacOS since I have worked mostly for iOS in Apple's world).
    - nl 11y ago
      That sound like pretty strong agreement, unless you are just targeting Windows?
IgorPartola 11y ago
How exactly do you not have to worry about dependencies? Does the Go SDL include every routine you could possibly need and is always 100% correct and bug free? If you build your static binary today and tomorrow there is a vulnerability in your libssl dependency of choice, don't you now have to recompile and redistribute a new binary? Seems like a terrible and insecure way to do things. Instead of a distro developer worrying about security updates, you have signed up to do that yourself. As for logging, there are loads of logging libraries that support both stdout and file logging. My policy is to support both for my project and it has been almost no burden so far (in Python and in C). Not everything is containers, and having a feature like logging does not mean it cannot be used in a container.
- rakoo 11y ago
  > If you build your static binary today and tomorrow there is a vulnerability in your libssl dependency of choice, don't you now have to recompile and redistribute a new binary Technically there's only one ssl library you should use, it's the standard one. This doesn't change your overall point that when a part of the program must be upgraded, the whole binary must be upgraded as well and re-deployed, which I totally agree with. If your software is a server that you host yourself and you have full control over the deployment chain, as is the mindset behind Go, then re-deploying a dependency or re-deploying a binary is more or less the same. Regarding logging, I'm really partial to the approach advertised by 12 factors (http://12factor.net/logs http://12factor.net/logs): let your software handle the business, let the supervisor handle the software's lifecycle, and handle the logfiles outside of the software, because there are factors specific to the hosting machine that in my opinion shouldn't be the concern of the software.
  - IgorPartola 11y ago
    Not sure what you mean by standard ssl library. There's OpenSSL, GNU TLS, LibreSSL, and a number of other implementations. If you mean the one that comes with the OS, then wouldn't that by dynamic linking? Re-deploying the binary, and getting the updated binary are two different things. When OpenSSL has a vulnerability, they announce it after the fix is out, distro maintainers release updated packages, I run `apt-get update && apt-get upgrade` or equivalent. It is on OpenSSL and the distro maintainers to release the update, and on me to apply the update. When we are talking about static linking, it's now suddenly on the software developer to release a new binary or on me to rebuild the binary I have from source. Now I have to keep track of (a) which dependencies each project uses, and (b) which vulnerabilities come out. Not being familiar with Go, does it have such dependency tracking framework where I can update all packages where dependencies have been updated? Of course once I know that I need to perform an update, it doesn't matter if I run `apt-get upgrade` or `go build foo`. As for logging, I advocate doing both. I really should make a separate blog post about it, but here's what I expect a well-behaved daemon to do: - Always start in foreground and log to stdout (otherwise it seems like it exited without any output) - Use the -d and --daemon flags to go into background - Use the -p and --pid options for specifying the PID file - Use the -l and --log options for specifying the log file location (if not specified or is - use stdout) - If uses a config file, use -c or --config for the location of the configuration file. Default to standard OS location. This way all possible modes are supported (running under a supervisor process, in a container, as a stand-alone daemon, or in the foreground while in development/testing/experimentation), and it is very easy, even in C to write software that meets these requirements.

by rakoo 11y ago

veeti 11y ago

> This also means that there's a higher chance that the software will be packaged in the distribution of your choice, because the bar is lower Static linking and bundling of dependencies is a no-no in most distributions. If anything, the Go model is a headache for package maintainers to deal with.

pmelendez 11y ago

> no more having to deal with dependencies at runtime So, it is the same that linking the libraries statically? C and C++ has done that like since forever.

StavrosK 11y ago
Hey, if you said "written in C", I would be similarly excited about its ease of deployment.
rakoo 11y ago
Very true, I had python and ruby in mind. What Go makes different still is that static linking is mandatory.
FooBarWidget 11y ago
Have you ever actually tried producing a statically linked C/C++ binary? I've been programming in C/C++ for 10+ years. Static linking is a huge pain. My latest efforts have led me to create holy build boxes inside carefully controlled Docker-based environments just to be able to produce binaries that work on every Linux. With Go you can just run a single command to cross-compile binaries that work everywhere. Minimal setup required, no expert knowledge required.
- pmelendez 11y ago
  > Have you ever actually tried producing a statically linked C/C++ binary? Many times actually, I prefer to deploy just one file whenever I can. > just to be able to produce binaries that work on every Linux That's a Linux design/decision thing. Linux binary compatibility is ... well ... challenging. In Windows is not hard at all (Not sure how is it in MacOS since I have worked mostly for iOS in Apple's world).
  - nl 11y ago
    That sound like pretty strong agreement, unless you are just targeting Windows?

IgorPartola 11y ago

How exactly do you not have to worry about dependencies? Does the Go SDL include every routine you could possibly need and is always 100% correct and bug free? If you build your static binary today and tomorrow there is a vulnerability in your libssl dependency of choice, don't you now have to recompile and redistribute a new binary? Seems like a terrible and insecure way to do things. Instead of a distro developer worrying about security updates, you have signed up to do that yourself. As for logging, there are loads of logging libraries that support both stdout and file logging. My policy is to support both for my project and it has been almost no burden so far (in Python and in C). Not everything is containers, and having a feature like logging does not mean it cannot be used in a container.

rakoo 11y ago
> If you build your static binary today and tomorrow there is a vulnerability in your libssl dependency of choice, don't you now have to recompile and redistribute a new binary Technically there's only one ssl library you should use, it's the standard one. This doesn't change your overall point that when a part of the program must be upgraded, the whole binary must be upgraded as well and re-deployed, which I totally agree with. If your software is a server that you host yourself and you have full control over the deployment chain, as is the mindset behind Go, then re-deploying a dependency or re-deploying a binary is more or less the same. Regarding logging, I'm really partial to the approach advertised by 12 factors (http://12factor.net/logs http://12factor.net/logs): let your software handle the business, let the supervisor handle the software's lifecycle, and handle the logfiles outside of the software, because there are factors specific to the hosting machine that in my opinion shouldn't be the concern of the software.
- IgorPartola 11y ago
  Not sure what you mean by standard ssl library. There's OpenSSL, GNU TLS, LibreSSL, and a number of other implementations. If you mean the one that comes with the OS, then wouldn't that by dynamic linking? Re-deploying the binary, and getting the updated binary are two different things. When OpenSSL has a vulnerability, they announce it after the fix is out, distro maintainers release updated packages, I run `apt-get update && apt-get upgrade` or equivalent. It is on OpenSSL and the distro maintainers to release the update, and on me to apply the update. When we are talking about static linking, it's now suddenly on the software developer to release a new binary or on me to rebuild the binary I have from source. Now I have to keep track of (a) which dependencies each project uses, and (b) which vulnerabilities come out. Not being familiar with Go, does it have such dependency tracking framework where I can update all packages where dependencies have been updated? Of course once I know that I need to perform an update, it doesn't matter if I run `apt-get upgrade` or `go build foo`. As for logging, I advocate doing both. I really should make a separate blog post about it, but here's what I expect a well-behaved daemon to do: - Always start in foreground and log to stdout (otherwise it seems like it exited without any output) - Use the -d and --daemon flags to go into background - Use the -p and --pid options for specifying the PID file - Use the -l and --log options for specifying the log file location (if not specified or is - use stdout) - If uses a config file, use -c or --config for the location of the configuration file. Default to standard OS location. This way all possible modes are supported (running under a supervisor process, in a container, as a stand-alone daemon, or in the foreground while in development/testing/experimentation), and it is very easy, even in C to write software that meets these requirements.