The simplicity of single-file Golang deployments • Hacker News Board

Re: The simplicity of single-file Golang deployments

#91

Post by tomcam » Wed, Mar 22, 2023, 4:45 PM UTC

pjc50 wrote: post #35

masto wrote: post #14

When I was stuck doing a web application in Java 15 years ago, I hated everything about it except for the deployment story, which boiled down to a single .war file being pushed to the server. When we upgraded to Perl, I liked that system so we designed deployment around "PAR" files in a similar way, bundling all of the dependencies together with the application in the CI build process, and I wrote a tiny bit of infra…

> I don't see what's special or better about compiling everything into a single binary, apart from fetishizing the executable format. Indeed. If you think of the docker image itself as an executable format like PE or ELF, this becomes clearer. Rather than targeting the OS API, which has completely the wrong set of security abstractions because it's built around "users", it defines a new API layer. > "I can deploy by…

> Indeed. If you think of the docker image itself as an executable format like PE or ELF, this becomes clearer.

But I don’t, because a docker image will not run without docker. A standalone, executable file can be distributed and deployed all by itself. A docker image cannot.

Re: The simplicity of single-file Golang deployments

#92

Post by pjmlp » Wed, Mar 22, 2023, 4:46 PM UTC

traceroute66 wrote: post #61

drewg123 wrote: post #34

The fact that it produces a single static binary is one of the nicest things about golang. This used to be easy with C (on BSD & Linux) a long time ago, but then everything started to depend on various shared libs, who then depend on other libs, then things started to even dlopen libs behind your back so they didn't even show up in ldd, etc. Sigh.

[flagged]

If only they would decide what to do with plugin package, not use SCM paths for packages and decide to eventually support enumerations instead of iota dance (Pascal style would be enough.

Maybe 10 more years.

Re: The simplicity of single-file Golang deployments

#93

Post by twic » Wed, Mar 22, 2023, 4:51 PM UTC

I feel like i'm taking crazy pills (at a low dose) when i read this stuff.

I deploy Java applications. In a runnable condition, they aren't a single file, but they aren't many - maybe a dozen jars plus some scripts. Our build process puts all that in a tarball. Deployment comprises copying the tarball to the server, then unpacking it [1].

That is one step more than deploying a single binary, but it's a trivial step, and both steps are done by a release script, so there is a single user-visible step.

The additional pain associated with deploying a tarball rather than a single binary is negligible. It simply is not worth worrying about [2].

But Go enjoyers make such a big deal of this single binary! What am i missing?

Now, this post does talk about Docker. If you use Docker to deploy, then yes, that is more of a headache. But Docker is not the only alternative to a single binary! You can just deploy a tarball!

[1] We do deploy the JDK separately. We have a script which takes a local path to a JDK tarball and a hostname, and installs the JDK in the right place on the target machine. This is a bit caveman, and it might be better to use something like Ansible, or make custom OS packages for specific JDKs, or even use something like asdf. But we don't need to deploy JDKs very often, so the script works for us.

[2] Although if you insist, it's pretty easy to make a self-expanding-and-running zip, so you could have a single file if you really want: https://github.com/vmware-archive/executable-dist-plugin

Re: The simplicity of single-file Golang deployments

#94

Post by iambvk » Wed, Mar 22, 2023, 4:54 PM UTC

rangerelf wrote: post #69

candiddevmike wrote: post #54

Earlier quoted context omitted.

From what I have seen in major OSS projects like systemd and PostgreSQL, nothing seems to support static linking, to the point where some contributors get annoyed when you ask for it. Seems like the C/C++ ecosystem will stay dynamically linked, even with a lot of the industry shifting towards statically linked, fat binaries as disk space is pretty cheap. I wonder how much simpler Linux packaging would be if everythin…

Simpler but small updates, like say openssl, become massive distro updates. There's a reason why everyone went with shared libs when they became stable.

A system with shared libraries also needs an update for the security fixes. There is no avoiding the update step. However, the only difference is the size of the update. If update process is robust, size of the update shouldn't matter, isn't it?

Re: The simplicity of single-file Golang deployments

#95

Post by jacobr1 » Wed, Mar 22, 2023, 5:00 PM UTC

mrkeen wrote: post #56

pjc50 wrote: post #35

Earlier quoted context omitted.

> I don't see what's special or better about compiling everything into a single binary, apart from fetishizing the executable format. Indeed. If you think of the docker image itself as an executable format like PE or ELF, this becomes clearer. Rather than targeting the OS API, which has completely the wrong set of security abstractions because it's built around "users", it defines a new API layer. > "I can deploy by…

What does cgi-bin get you? What does it run on? If I already have a single-file web server, do I need to introduce extra cgi-bin technology also?

For anybody comfortable with the compiling the single-file binary ... it doesn't gain you anything. For a class of "power-end-users" it provides a mechanism to build sandboxed apps on a multi-tenant system. I think the spiritual successors split though between PAAS/heroku-like systems and "low-code" platforms.

Re: The simplicity of single-file Golang deployments

#96

Post by eddsh1994 » Wed, Mar 22, 2023, 5:03 PM UTC

marcosdumay wrote: post #25

masto wrote: post #14

When I was stuck doing a web application in Java 15 years ago, I hated everything about it except for the deployment story, which boiled down to a single .war file being pushed to the server. When we upgraded to Perl, I liked that system so we designed deployment around "PAR" files in a similar way, bundling all of the dependencies together with the application in the CI build process, and I wrote a tiny bit of infra…

> I don't see what's special or better about compiling everything into a single binary, apart from fetishizing the executable format. When you distribute your software to other people, it cuts the step of installing the correct interpreter... at the cost of requiring the correct computer architecture. It is very likely a gain.

> it cuts the step of installing the correct interpreter... at the cost of requiring the correct computer architecture.

Obviously this depends on the product but I'd give anything to worry about interpreters over the correct computer architecture in the M1/M2 Intel Embedded world.

Re: The simplicity of single-file Golang deployments

#97

Post by simiones » Wed, Mar 22, 2023, 5:05 PM UTC

twic wrote: post #93

I feel like i'm taking crazy pills (at a low dose) when i read this stuff. I deploy Java applications. In a runnable condition, they aren't a single file, but they aren't many - maybe a dozen jars plus some scripts. Our build process puts all that in a tarball. Deployment comprises copying the tarball to the server, then unpacking it [1]. That is one step more than deploying a single binary, but it's a trivial step,…

Related to [1], I thought modern Java deployment style is to bundle the required modules of the JDK with your app, rather than any concept of a "deployed JDK".

As it is, the difficulty of deploying a JDK + your app is much more than a single static binary, Go-style.

Re: The simplicity of single-file Golang deployments

#98

Post by SkyPuncher » Wed, Mar 22, 2023, 5:06 PM UTC

danwee wrote: post #9

How does one handle zero downtime deployments with single-file golang binaries? I remember I tried this setup some time ago and I couldn't successfully manage cleanly to accomplish no downtime when deploying a new version of my service. The reason was mainly port reuse. I couldn't have the old and the new version of my service running on the same port... so I started to hack together something and it became dirty pre…

I've always run services behind a proxy. Spin up a new server with the code (works for any type of deployment). Validate it's up. Switch the proxy from the old to new server.

Re: The simplicity of single-file Golang deployments

#99

Post by doodpants » Wed, Mar 22, 2023, 5:08 PM UTC

tomcam wrote: post #89

tptacek wrote: post #72

Earlier quoted context omitted.

Please don't start random language fights.

Directly addressing the topic of a upvoted article is starting random language fights?

The article is about Go, and while the article mentions other languages for comparison, Rust is not one of them. So traceroute66's comment comes across as starting a Rust vs. Go fight where not appropriate.

Re: The simplicity of single-file Golang deployments

#100

Post by x0x0 » Wed, Mar 22, 2023, 5:08 PM UTC

twic wrote: post #93

I feel like i'm taking crazy pills (at a low dose) when i read this stuff. I deploy Java applications. In a runnable condition, they aren't a single file, but they aren't many - maybe a dozen jars plus some scripts. Our build process puts all that in a tarball. Deployment comprises copying the tarball to the server, then unpacking it [1]. That is one step more than deploying a single binary, but it's a trivial step,…

I'm taking the same crazy pills.

We did this deployment pattern with a jar in, like... the early 2000s? It's trivial (well, maybe an annoying couple hours to config, but it's a config once and then done) in maven to build a megajar and add every single thing you need into one large jar. All resources, dependencies, etc.

And then deployment is, indeed, an rsync.