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

221–230 of 232 posts

Re: The simplicity of single-file Golang deployments

#221

Post by cxr »

pjc50 wrote: post #216
cxr wrote: post #213

Earlier quoted context omitted.

> I kind of miss cgi-bin. If we're ever to get back to a place where random "power users" can knock up a quick server to meet some computing need they have, easy deployment has to be a big part of that. Can we make it as easy to deploy as to post on Instagram? I'd be happy with a future that takes some cues from literate programming, where if you want to deploy some application, the way you do it is to upload a copy…

> the way you do it is to upload a copy of the software manual/specification. This should be sufficient to "teach" the server how the application should behave. i.e. a program. I've actually worked with someone who had a system for compiling the "human readable" side of the h265 specification to executables. This he compared against the "reference implementation" provided in C. As a result he filed a large number of…

> i.e. a program

If you want to think of it that way (as a way to be dismissive), sure. But I don't know anyone who when asking if some program foo has a manual would accept foo.git as an acceptable answer wrt the spirit of the question.

There's also the not so small matter of packaging/distribution. It's the entire point of the linked post. Stuff like PDF or ebook formats are well understood to be self-contained, which is what makes them something that you can trivially hand-off to someone else with about the same ease as a real book (e.g. attaching it to an email). Software deployments tend to work differently. That should change.

> Writing an unambiguous specification is hard work regardless of whether you do it in C or in English or something else

Right. And programmers already have to contend with this. But when I float this idea around, people like to point this out, as if it's not merely hard, but impracticably hard—to the point of the suggestion being ludicrous. And yet (to repeat myself but not to belabor the point), it's not as if they get to escape this by following current practices; that's something that programmers _already_ have to contend with.

Re: The simplicity of single-file Golang deployments

#222

Post by acatton »

ed25519FUUU wrote: post #196
acatton wrote: post #59

Earlier quoted context omitted.

I'm not the author of the post, so I can't tell you what the author does. What I do in my projects is that I tell varnish-cache to cache assets in "/static/..." forever. And I have a "curl -X PURGE " as part of the "ExecStartPre=" of my go binary. • https://varnish-cache.org/docs/trunk/users-guide/purging.htm... • https://www.freedesktop.org/software/systemd/man/systemd.ser...

Clever solution! Why not make it part of the startup of your binary?

Sorry to reply a day later. GP here, it's a simple separation of concern. IMHO the binary should not be aware that it is cached and/or how it's deployed. I separate "business logic" from "devops", and I consider purging the cache to be "devops". This is why I let systemd do it.

Of course, at the end it's a question of preference. People might disagree.

Re: The simplicity of single-file Golang deployments

#223

Post by [deleted] »

drewg123 wrote: post #163
1vuio0pswjnm7 wrote: post #150

Earlier quoted context omitted.

IME, using musl, compiling static binaries written in C is as easy as it was before glibc changes and as it has always has been on NetBSD. I compile static binaries written in C every day on Linux. I never encountered any problems compiling static binaries on BSD.

Can you link something substantial, like Firefox, statically on NetBSD?

[deleted]

Re: The simplicity of single-file Golang deployments

#224

Post by asalahli »

brigadier132 wrote: post #145
asalahli wrote: post #135

Earlier quoted context omitted.

Parent is saying those crates themselves are reinventing the wheel, not talking about using a crate

So by that logic Golang reinvented the wheel by creating a new programming language when java already existed

Yes. Is reinventing the wheel always a bad thing, though? Not if you ask me, not if the new wheel has novel characteristics and performs better in some aspects.

Re: The simplicity of single-file Golang deployments

#225

Post by lenkite »

cxr wrote: post #214
lenkite wrote: post #117

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/2…

You, and any other non-Golang programmer, could visit the golang.org site, download the latest release, untar it, write a hello-world service, and run "go build". It will take about that many steps and about 5 minutes, and you'll have your single-file binary ready for deployment. Can you compare doing the same thing with Java? How many more steps does it take, assuming that you don't already have a standard Java dev…

"How much more effort does it take just to go from "typical Java setup" to "setup that actually lets you do what this article describes"? "

5-6 minutes extra. 3 more steps. You are making a mountain out of a mole-hill. Sorry to burst your bias-bubble, but Java deployment is damn easy nowadays.

If you are leveraging a cloud build-pack, single file native exe deployments like Go's are un-optimal since they are slower - no intelligence to perform differential updates like the way you get for a Java fat-jar or tar-ball.

Re: The simplicity of single-file Golang deployments

#226

Post by cxr »

lenkite wrote: post #225
cxr wrote: post #214

Earlier quoted context omitted.

You, and any other non-Golang programmer, could visit the golang.org site, download the latest release, untar it, write a hello-world service, and run "go build". It will take about that many steps and about 5 minutes, and you'll have your single-file binary ready for deployment. Can you compare doing the same thing with Java? How many more steps does it take, assuming that you don't already have a standard Java dev…

"How much more effort does it take just to go from "typical Java setup" to "setup that actually lets you do what this article describes"? " 5-6 minutes extra. 3 more steps. You are making a mountain out of a mole-hill. Sorry to burst your bias-bubble, but Java deployment is damn easy nowadays. If you are leveraging a cloud build-pack, single file native exe deployments like Go's are un-optimal since they are slower -…

> 5-6 minutes extra. 3 more steps.

That's greater than zero. So you're already failing—and that's on top of the handicap already afforded to you for the initial setup.

(Even ignoring that, I'm suspicious of your numbers. Have you actually measured it? Do you have something to show that your off-the-cuff figures match what people will actually experience?)

> Sorry to burst your bias-bubble

Major irony—assuming bias on my part (where there is, in fact, none) without realizing that doing so broadcasts evidence of yours.

Re: The simplicity of single-file Golang deployments

#227

Post by lenkite »

cxr wrote: post #226
lenkite wrote: post #225

Earlier quoted context omitted.

"How much more effort does it take just to go from "typical Java setup" to "setup that actually lets you do what this article describes"? " 5-6 minutes extra. 3 more steps. You are making a mountain out of a mole-hill. Sorry to burst your bias-bubble, but Java deployment is damn easy nowadays. If you are leveraging a cloud build-pack, single file native exe deployments like Go's are un-optimal since they are slower -…

> 5-6 minutes extra. 3 more steps. That's greater than zero. So you're already failing—and that's on top of the handicap already afforded to you for the initial setup. (Even ignoring that, I'm suspicious of your numbers. Have you actually measured it? Do you have something to show that your off-the-cuff figures match what people will actually experience?) > Sorry to burst your bias-bubble Major irony—assuming bias on…

> Even ignoring that, I'm suspicious of your numbers. Have you actually measured it? Do you have something to show that your off-the-cuff figures match what people will actually experience?

What ? This is the time required to download GraalVM and then configure your project. This is a ONE-TIME setup. Strictly speaking, if you omit a build tool like maven - you don't really need it for a native binary - then it is simply one additional install - get Graal native image and compile your code to a binary using the CLI. Why would I even bother measuring this ?

The fact that you are even asking for "measurements" without providing corresponding "measurements" for the Golang setup - something the article never even bothered to mention is ludicrous. Why would one even consider the one-time cost of installing one additional tool ?

That way lies silliness - I should then consider Java superior because Go requires additional command to install godoc for example while Javadoc comes with the base JDK.

> Major irony—assuming bias on my part (where there is, in fact, none) without realizing that doing so broadcasts evidence of yours.

There is nothing ironic in pointing out your double-standards. I develop in both Go and Java. Both languages come with their advantages. The strict advantages Go has over Java is goroutines, more feature-packed stdlib and reduced memory footprint at runtime. (The goroutine advantage has also gone away now with virtual threads in Java).

But single file deployment is NOT an advantage Go holds over Java - since several years now.

Re: The simplicity of single-file Golang deployments

#228

Post by cxr »

lenkite wrote: post #227
cxr wrote: post #226

Earlier quoted context omitted.

> 5-6 minutes extra. 3 more steps. That's greater than zero. So you're already failing—and that's on top of the handicap already afforded to you for the initial setup. (Even ignoring that, I'm suspicious of your numbers. Have you actually measured it? Do you have something to show that your off-the-cuff figures match what people will actually experience?) > Sorry to burst your bias-bubble Major irony—assuming bias on…

> Even ignoring that, I'm suspicious of your numbers. Have you actually measured it? Do you have something to show that your off-the-cuff figures match what people will actually experience? What ? This is the time required to download GraalVM and then configure your project. This is a ONE-TIME setup. Strictly speaking, if you omit a build tool like maven - you don't really need it for a native binary - then it is sim…

So have you measured it or not?

> The fact that you are even asking for "measurements" without providing corresponding "measurements" for the Golang setup

I'm responding to your claim. The onus is on you to substantiate it.

> Why would one even consider the one-time cost of installing one additional tool ?

Aside from the low-hassle relative simplicity being the fundamental subject of the submitted article, there's no reason I suppose.

> There is nothing ironic in pointing out your double-standards.

There is no double-standard aside from the aforementioned handicap that benefits you, and you're moving the goalposts, besides. You specifically accused me of being in a "bias-bubble". There is no purer form of irony.

Re: The simplicity of single-file Golang deployments

#229

Post by lenkite »

cxr wrote: post #228
lenkite wrote: post #227

Earlier quoted context omitted.

> Even ignoring that, I'm suspicious of your numbers. Have you actually measured it? Do you have something to show that your off-the-cuff figures match what people will actually experience? What ? This is the time required to download GraalVM and then configure your project. This is a ONE-TIME setup. Strictly speaking, if you omit a build tool like maven - you don't really need it for a native binary - then it is sim…

So have you measured it or not? > The fact that you are even asking for "measurements" without providing corresponding "measurements" for the Golang setup I'm responding to your claim. The onus is on you to substantiate it. > Why would one even consider the one-time cost of installing one additional tool ? Aside from the low-hassle relative simplicity being the fundamental subject of the submitted article, there's no…

> I'm responding to your claim. The onus is on you to substantiate it.

Snort. I believe the original claim has been substantiated enough already - that Go holds no advantage over Java wrt single file deployment as you can achieve "single binary" in Java too if you wish.

Measurement of a one-time setup cost was a claim made by you, not by me. You gave a description and I gave a description. Demanding precise time measurement of a ballpark is where the "double standard" lies - since you never provided any to "substantiate" yours, yet demand one from me by statements like: "So have you measured it or not?" for a CLI compiler install.

But, hey, in the spirit of goodness:

    time bash 
    Finished generating 'helloworld' in 16.8s.

    ./helloworld                                                                                                                                              
    Hello, World!
Huh, so it was actually FASTER than I thought for an end to end setup. You don't even need the open JDK since graalvm already comes with it. (I mistakenly thought needing open jdk was a pre-requisite).

So, its literally just: install tool, set path and invoke compilation commands. 1-2 min end to end.

Re: The simplicity of single-file Golang deployments

#230

Post by solatic »

twic wrote: post #111
solatic wrote: post #108

Earlier quoted context omitted.

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

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

If you have a prepared image / immutable infrastructure pattern, that image is the single-file pattern. Container images are tarballs. Go isn't actually all that special here, if you compare apples to apples in containerized deployments: either you bake the standard library into the binary (which Go does), or you bake the standard library into the tarball (which the JDK forces you to do). Either way it's a single file.

Post reply on HN