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

131–140 of 232 posts

Re: The simplicity of single-file Golang deployments

#131

Post by sneak »

hsn915 wrote: post #53
sneak wrote: post #33

I still put the single file in a docker container because docker isn't complex.

This makes zero sense. I don't like cargo culting.

I deploy everything everywhere with docker, because then the only thing installed on the system is dockerd. I can deploy identically on different distributions; I don't need to know anything about the host or keep track of files on the host.

I can keep all of my build artifacts in a docker image repository with versions. I can deploy any version on any host without worrying about copying the version to the host.

Whether your deploy is 1000000 files or 1, this system has clear advantages to copying things to the base server OS and turning it into a snowflake.

Re: The simplicity of single-file Golang deployments

#133

Post by p5v »

pjmlp wrote: post #92
traceroute66 wrote: post #61

Earlier quoted context omitted.

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

Regarding the “iota dance,” I wrote my 2 cents on what could be a slightly more robust approach a couple of days ago: https://preslav.me/2023/03/17/create-robust-enums-in-golang/

P.S generic type sets make it even better. I’ll write an update to my post these days.

Re: The simplicity of single-file Golang deployments

#134

Post by [deleted] »

tomcam wrote: post #124
doodpants wrote: post #99

Earlier quoted context omitted.

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.

Doesn’t come across as starting a fight to me. Not even close.

[deleted]

Re: The simplicity of single-file Golang deployments

#135

Post by asalahli »

brigadier132 wrote: post #90
traceroute66 wrote: post #61

Earlier quoted context omitted.

[flagged]

Using a crate is the opposite if reinventing the wheel. Also are we talking about go? The language without a set implementation?

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

Re: The simplicity of single-file Golang deployments

#137

Post by nightfly »

taeric wrote: post #84
bzzzt wrote: post #62

Earlier quoted context omitted.

Packaging would be simpler, but you probably have to update the whole OS and all your installed apps when a security update for a common library is released.

Not wrong; at the same time, I'm becoming less convinced this is relevant. Seems many security updates have to do with code paths that are not used in a large number of applications. Similarly, many of them are fixes on features that even more apps didn't want/need, but they got when they updated to get the last round of security fixes. :( The docker world is a neat example of this. The stories of ${absurdly high per…

The problem is having to wait for all those applications to push updates when a vulnerability is found in a common library

Re: The simplicity of single-file Golang deployments

#139

Post by dahfizz »

iambvk wrote: post #94
rangerelf wrote: post #69

Earlier quoted context omitted.

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?

It does matter. If there is a problem with openssl, just the openssl maintainers have to push an update and everything on your system is secure.

If everything is statically linked, you need to wait for every maintainer of every single program on your system to rebuild and push an update. You're basically guaranteed that there is always _something_ missing important patches

Re: The simplicity of single-file Golang deployments

#140

Post by Rapzid »

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…

> we don't write deployable software any more

What did it use to look like exactly, this "deployable" software? Going back to the birth of web 2.0 we had Perl, PHP, Java(?), .Net Framework a few years later. These all required tons of pre-configured infrastructure on the servers to run..

> It looks strange from a platform that deploys as one single binary

It's just a tool with many uses. I CAN deploy my Asp.Net app as a self-contained(even single) file.. But the size of updates is smaller between images if I copy the app into an image that already has the .Net and Asp.Net library code in the base layers.

Post reply on HN