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

151–160 of 232 posts

Re: The simplicity of single-file Golang deployments

#151

Post by mike_hearn »

pjc50 wrote: post #86
mrkeen wrote: post #56

Earlier quoted context omitted.

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?

Apache supported it, back in the day before nginix existed. It gives you a single-file web page . You can then have multiple pages on the same server run by different users under different userids. It also operates on a model of one execution run per request. So CGIs that aren't currently being served consume no resources.

It still does support it. In fact I use it on our company website to handle the contact form submission. It invokes a Kotlin script which reads the form, handles the recaptcha call and sends an email. Old school but it works and doesn't require any resources except when running.

Re: The simplicity of single-file Golang deployments

#152

Post by aatd86 »

earthling8118 wrote: post #73
traceroute66 wrote: post #61

Earlier quoted context omitted.

[flagged]

From another point of view "usable" isn't a word I'd associate with Go, especially not when there is an "unlike Rust" in the phrase. I've not had any issues of the sort when building out Rust applications. At this point the only time I touch Go is if I need to modify something else someone has made-- which I avoid at all costs

Maybe AI will make it more palatable but I just can't get into Rust.

I can probably easily understand borrowing. It's mostly an issue of controlling pointer aliasing wrt mutability, especially in a multithreaded context I guess.

But that gottdarn syntax... And goroutines are too nice for the type of code I use.

I'm too spoiled with Go I guess.

Re: The simplicity of single-file Golang deployments

#153

Post by aatd86 »

synergy20 wrote: post #51
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.

very true, for Go though if you need CGO it's hard to make a single executable, otherwise it is great. I run a few Go apps, all are single executables, upgrading to new releases has never been easier. if you have a network oriented application, nothing beats golang as far as release|maintenance is concerned.

Some people are writing alternative via WebAssembly.

For instance wazero which I'm really excited about.

https://tetrate.io/blog/introducing-wazero-from-tetrate/?utm...

Re: The simplicity of single-file Golang deployments

#154

Post by tinglymintyfrsh »

neilv wrote: post #136

I'm often a fan of single source files, at the package level, including inline embedded API docs and unit tests.

That doesn't scale because it makes merging and file navigation nearly impossible, and the increased cognitive load is too much for anything real.

Encapsulate functionality and break it into logical containers.

That's what modules are.

That's what files are.

That's what functions are.

That's what software engineering is.

Re: The simplicity of single-file Golang deployments

#155

Post by tinglymintyfrsh »

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…

You don't. You can sort of emulate it with services that stateless, load-balanced, and L7 proxied.

If you want stateful zero downtime deployments, use Elixir or Erlang that has the ability to live migrate data from one version of code to the next.

Re: The simplicity of single-file Golang deployments

#156

Post by avg_dev »

I feel like I agree with the general ethos of the project. And I am also a fan of pragmatism; I think Fred Brooks referred to our trade as “toolsmiths” and I feel it is an apt word. Our work product exists solely to fill a need or to enable things that were not previously possible. I feel like I work hard not to be an idealist or to view well-written code as an end to itself.

But I must confess,

> Systemd also restarts the app daily to make sure it works properly long term

leaves me with a viscerally negative feeling. I feel like daemons should be able to run for years unless there is some kind of leak. Maybe I am wrong.

Re: The simplicity of single-file Golang deployments

#157

Post by apazzolini »

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]

Ah yes, the #1 thing golang is known for: a comprehensive stdlib. Like including a max function for integers, right?

Re: The simplicity of single-file Golang deployments

#158

Post by VBprogrammer »

pjmlp wrote: post #129
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…

Java never needed Docker, in fact the Docker / Kubernetes is now re-inventing Java Application Servers with WASM containers.

XML ruined Java.

Re: The simplicity of single-file Golang deployments

#159

Post by davemp »

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 is very likely a gain.

Distributing python has to be some of the worst experiences I’ve had in the field.

Re: The simplicity of single-file Golang deployments

#160

Post by nneonneo »

1vuio0pswjnm7 wrote: post #150
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.

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.

That’s great if your only dependency is libc. It gets progressively harder the more dependencies you need, and it becomes downright untenable the moment you run into some dependency with a dlopen-based plugin architecture.
Post reply on HN