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

141–150 of 232 posts

Re: The simplicity of single-file Golang deployments

#141

Post by jrockway »

tomcam wrote: post #107
zer00eyz wrote: post #31

Earlier quoted context omitted.

I'll bite! We used to ship software, on discs, and we didn't have the Internet to update it. There is plenty of software out there that works via your linux distress package manager. Note that this isn't everything you can get from your package manager. Plenty of things that are available are broken or miersable to get working unless you get the container/vm version.

I remember those days well. It really meant you had to be careful with bugs and documentation. It is not clear to me that the we are winning with daily or multiple times daily release schedules at this point.

Were people careful with bugs and documentation? I remember the Internet blowing up one day because every Windows install was sending every IP on the Internet a virus, and there was nothing anyone could do about it. (And yes, Unix also had similar worms, though they largely predate me!) Word used to crash and corrupt your entire novel. There was no online banking. I'm not sure the rose-colored glasses are a realistic take on changing software quality.

Today, the tools are available to move quickly and maintain quality. You probably do what was months of manual testing every time you save a file, and certainly every time you commit a set of changes. There are fuzz testers to find the craziest bugs that no human could even imagine. There are robots that read your PR and point out common errors. HN really likes to pan on software quality, but "I don't like this feature" is not a bug per se, just a company you don't like. There are a lot of those, but there are more lines of code than ever, and a lot more stuff works than 30 years ago. I think we, as a field, are getting better.

Re: The simplicity of single-file Golang deployments

#142

Post by candiodari »

crote wrote: post #126
tomcam wrote: post #91

Earlier quoted context omitted.

> Indeed. If you think of the docker image itself as an executable format like PE or ELF, this becomes clearer. But I don’t, because a docker image will not run without docker. A standalone, executable file can be distributed and deployed all by itself. A docker image cannot.

A standalone executable doesn't remain a standalone executable for very long, though. You need something to handle its lifecycle and restart it when it dies. You need something to handle logging. You need something to jail it and prevent it from owning your system when it has a bug. You need something to pass it database credentials. You need something to put a cpu/mem limit on it. Not to mention that most executable…

That used to be apache and mod_* (mod_php, mod_python, mod_ruby, ...)

I've always wondered if it is possible to extend this system. Mod_docker?

Re: The simplicity of single-file Golang deployments

#143

Post by candiodari »

jacobr1 wrote: post #95
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?

For anybody comfortable with the compiling the single-file binary ... it doesn't gain you anything. For a class of "power-end-users" it provides a mechanism to build sandboxed apps on a multi-tenant system. I think the spiritual successors split though between PAAS/heroku-like systems and "low-code" platforms.

It gains you multi-tenancy on the serving end, making infrastructure very cheap.

Re: The simplicity of single-file Golang deployments

#144

Post by Rapzid »

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…

.Net too, also same prob with decade old worldview about .Net

One thing that hasn't changed is that C# > Java ;P

Re: The simplicity of single-file Golang deployments

#145

Post by brigadier132 »

asalahli wrote: post #135
brigadier132 wrote: post #90

Earlier quoted context omitted.

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

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

Re: The simplicity of single-file Golang deployments

#146

Post by candiodari »

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.

Of course Visual Basic 2.0 and Delphi 1.0 both had embeddable filesystems. Even updateable embedded filesystems (which worked because the exe would really be a zip files. Zip files are indexed from the end of the file. So you can prepend the actual executable code and that would work. Zip files are updateable ...)

I believe after a while you also had sqlite-inside-the-exe things.

Re: The simplicity of single-file Golang deployments

#148

Post by coldtea »

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.

>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

Not even, as it's trivial to cross compile on Golang. Then you just offer 3-4 arch binaries, and they download the one that matches their platform.

Re: The simplicity of single-file Golang deployments

#149

Post by mike_hearn »

vips7L wrote: post #42
somehnguy wrote: post #36

Earlier quoted context omitted.

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…

> From what I understand Java does have facilities to bundle jlink, jpackage, and if you need something complex you can use conveyor: https://hydraulic.software/index.html

Or even if you need something simple :-) Sending little apps to friends is easy now just like it once was, the difference is that the friends don't need to know what runtime you use. Also not only for Java: Electron, Flutter and anything else works too.

We have an internal version of Conveyor that can be used to push servers as well. It bundles the jvm, makes debs with auto-scanned dependencies, systemd integration is automatically set up, it's easy to run the server with the DynamicUser feature for sandboxing and it uploads/installs the packages for you via ssh. We use it for our own servers. There seems to be more interest these days in running servers without big cloud overheads, so maybe we should launch it? It's hard to know how much demand there is for this sort of thing, though it gets rid of the hassle of manually configuring systemd and copying files around.

Re: The simplicity of single-file Golang deployments

#150

Post by 1vuio0pswjnm7 »

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.
Post reply on HN