Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

The simplicity of single-file Golang deployments

amazingcto.com

Post reply on HN
Print view View original

111–120 of 232 posts

Re: The simplicity of single-file Golang deployments

#111

Post by twic »

solatic wrote: post #108
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,…

> Deployment comprises copying the tarball to the server You must not scale servers up and down very frequently then. > both steps are done by a release script, so there is a single user-visible step... we do deploy the JDK separately Wait, so it's not really a single user-visible step. You have one user-visible step to deploy the application server, and a different user-visible step to deploy the JDK. Look, there's…

> You must not scale servers up and down very frequently then.

Indeed we don't. But i don't see why it would be a problem if we did. If you can run a script to copy a Go binary to a VM when you scale up, you can run a script to copy a tarball and unpack it. If you're scaling based on a prepared image, then you can prepare the image by unpacking a tarball, rather than copying in one file.

> Wait, so it's not really a single user-visible step. You have one user-visible step to deploy the application server, and a different user-visible step to deploy the JDK.

Oh come on! If that matters to you, change the app deployment script to run the JDK deployment script first. Bam, one step.

> Scaling up and down is much, much simpler with immutable infrastructure patterns

Sure, and as far as i can see, this is completely orthogonal to having a single-file deployment. You haven't made any case at all for why having single-file deployment is valuable here.

Re: The simplicity of single-file Golang deployments

#112

Post by sconi »

adql wrote: post #74
quaintdev wrote: post #57

Earlier quoted context omitted.

> The fact that it produces a single static binary is one of the nicest things about golang. Not only that it can also cross compile for different architecture and operating systems.

We used that to make a simple "VPN diagnostics" app for our helpdesk (app checked connectivity and config of the machine then displayed the summary page). Only thing that needed to be written per-os is how to call a browser to display the report

interesting. could you share what specifically the report had?

Re: The simplicity of single-file Golang deployments

#113

Post by cytzol »

joncfoo wrote: post #29
zer00eyz wrote: post #20

From the article: "Standing here it looks like Docker was invented to manage dependencies for Python, Javascript and Java. It looks strange from a platform that deploys as one single binary." Let me say the quiet part out loud: Docker is covering up the fact that we don't write deployable software any more. Go isn't perfect either. The author isn't dealing with assets (images anyone?). I think there is plenty of room…

Assets of any kind can be embedded in the executable and accessed via the embed.FS interface. This makes it trivial to bundle up all dependencies if desired.

Embedding your assets like this isn't always an improvement. For example, I work on a site with a Go server and static content pages, and I like that I can update one of the pages and see the change instantly without having to re-compile the entire server binary just to get the new files included.

Re: The simplicity of single-file Golang deployments

#114

Post by abtinf »

Asdrubalini wrote: post #106
traceroute66 wrote: post #61

Earlier quoted context omitted.

[flagged]

Rust's philosophy (unlike Python's, for example) consists in not including tons of stuff in the standard library, this way you can choose the best implementation for your specific use case from one of the many crates (which are super easy to install, by the way). There is no "always the best" implementation for a specific functionality, nor a legacy-but-still-officially-supported-in-std implementation that nobody use…

> legacy-but-still-officially-supported-in-std implementation

There is massive value in this.

Re: The simplicity of single-file Golang deployments

#115

Post by giantrobot »

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?

The CGI mechanism let the web server call a separate local binary passing parameters of the request as envars/stdin in a specified manner. The "cgi-bin" was just a server side directory where those CGI binaries lived.

If I understand the GP's point, they like the idea of dropping a singular binary in a directory on a server and then it's magically available as an endpoint off the cgi-bin/ path.

Re: The simplicity of single-file Golang deployments

#116

Post by lenkite »

somehnguy wrote: post #36
marcosdumay wrote: post #25

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. 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.

Exactly - I primarily write Java and fat-jars are great when developing apps for environments I control. But if I want to send an app to a friend it's a few additional steps to make sure they have the correct version of Java, paths are setup correct, etc. This isn't always trivial if they already have a different version of Java and want things to play nice side by side. Just bundle everything into a native executabl…

You can use Graal Native Image https://www.graalvm.org/22.0/reference-manual/native-image/ to produce a single native executable. Example of a Java Micro-service framework that has first class support for this is Quarkus (https://quarkus.io/). See https://quarkus.io/guides/building-native-image

For a plain Java app:

"Use Maven to Build a Native Executable from a Java Application" https://www.graalvm.org/22.2/reference-manual/native-image/g...

Re: The simplicity of single-file Golang deployments

#117

Post by lenkite »

Is this article from 2016? You can do all this with Java nowadays. I have observed a lot of folks on HN whose last knowledge about Java was from a decade plus ago pontificating about Java deficiencies that no longer exist today.

Use the GraalVM native build tools https://graalvm.github.io/native-build-tools/latest/index.ht....

"Use Maven to Build a Native Executable from a Java Application"

https://www.graalvm.org/22.2/reference-manual/native-image/g...

Re: The simplicity of single-file Golang deployments

#118

Post by lenkite »

Asdrubalini wrote: post #106
traceroute66 wrote: post #61

Earlier quoted context omitted.

[flagged]

Rust's philosophy (unlike Python's, for example) consists in not including tons of stuff in the standard library, this way you can choose the best implementation for your specific use case from one of the many crates (which are super easy to install, by the way). There is no "always the best" implementation for a specific functionality, nor a legacy-but-still-officially-supported-in-std implementation that nobody use…

"a legacy-but-still-officially-supported-in-std implementation that nobody uses anymore but still needs to be maintained with its own namespace."

The cardinality of the set of "nobody uses anymore" is usually in tens of millions.

Re: The simplicity of single-file Golang deployments

#119

Post by lenkite »

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,…

There are also some advantages towards the tarball jar encapsulating multiple jar approach - some cloud platform Java buildpacks superbly optimize the deployment process by only sending the differential jars - sometimes just the differential classes - which makes deployment 2x-3x faster than Golang single big bang executable approaches.

In our company which leverage both Java microservices and Golang microservices - the Java app deployment is much faster!

Re: The simplicity of single-file Golang deployments

#120

Post by lagniappe »

quaintdev wrote: post #57
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.

> The fact that it produces a single static binary is one of the nicest things about golang. Not only that it can also cross compile for different architecture and operating systems.

I made a cool program for Go projects that will compile all the supported OS and ARCH combos for your code. Please try it :) I use it for everything I make now.

Just do `release --name "mycoolprogram" --version "0.1.0"`

and it will output all of your labeled release binaries for every platform your code supports.

check it out! [0] You can see it at work here for this simple markdown blog generator I made, which sports 40 different platform combos [1]

[0] - https://github.com/donuts-are-good/release.sh

[1] - https://github.com/donuts-are-good/bearclaw/releases/latest

Post reply on HN