undefined | Better HN

0 pointsbarelysapient2y ago0 comments

100% this. Not worrying about the runtime environment is a huge improvement.

And with go embed[1], that single binary can be literally _everything_ needed by the application. Even non-go stuff can be embedded, like for example, a compiled React application.

[1] https://pkg.go.dev/embed

0 comments

3 comments · 1 top-level

closeparen2y ago· 2 in thread

That's important for CLIs. As the server-side deployment ecosystem has moved towards bundling and isolating dependencies at the OS level (ironically driven by Go projects Docker and Kubernetes) it's mattered less for backend applications. You can just SCP a Go binary around, just like you could always SCP JARs around, but a shop trendy enough to be using Go is unlikely to be doing that.

barelysapientOP2y ago

True, but SCPing a JAR around still requires a JRE of some sort of another and all that entails. Sure, containerization helps that but, in turn, it too is another dependency in the eventual execution.

Long term, I think static binaries win, probably due to advances in WASI/WASM; where the whole execution stack (as we think of it today) is thrown away and replaced.

vb-84482y ago

> That's important for CLIs

Not just CLIs, think about prometheus node_exporter or any kind of agent you need to install on a server or deploy to people's workstations or to external customers where you don't have any kind of control.

Single binary, it's definitively one of the killer feature of go.

j / k navigate · click thread line to collapse