I’m jealous of this coming from C#. They kind of have it but not really.
The simplicity of single-file Golang deployments
191–200 of 232 posts
Re: The simplicity of single-file Golang deployments
#192Re: The simplicity of single-file Golang deployments
#193Earlier quoted context omitted.
Can you link something substantial, like Firefox, statically on NetBSD?
Compiling Firefox on NetBSD (dynamically) takes longer than compiling the kernel, maybe even longer than compiling an entire base system. It's been a long time since I tried it but it just took far too long so I lost interest. Granted, the computers I use have limited resources. Anyway, I gave up on graphical browsers many years ago. It seems I prefer "unsubstantial" programs.
Graphical web browsers from "tech" companies (and their partners, like Mozilla) are too large, too complex, too difficult for the user to control. IMHO.
Re: The simplicity of single-file Golang deployments
#194Static binaries and automatic code formatting (no debates on code format whatsoever) are two incredible qualities of Go that should be copied to every new language but for whatever reason are mostly left out.
And I’m not taking about “making a static binary in $LANG is easy, just follow these 7 steps…” trust me it’s nothing like Go then.
Re: The simplicity of single-file Golang deployments
#195Earlier quoted context omitted.
Where does the word Rust appear in the article?
In the comments about every article including Go, generally.
I can't speak for Go-centric articles in general, but for this one in particular, the only one (as of now, after 14 hours of comments) bringing up Rust is this single person with (apparently) a weird chip on their shoulder.
Re: The simplicity of single-file Golang deployments
#196Earlier quoted context omitted.
OP here, How are you doing caching without a mod time? https://github.com/golang/go/issues/44854 Are you re-naming or hashing for cache clearing?
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?
Re: The simplicity of single-file Golang deployments
#197From 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 a…
You can do that without ever touching the system libraries?
Re: The simplicity of single-file Golang deployments
#198I feel like i'm taking crazy pills (at a low dose) when i read this stuff. I deploy Java applications. In a runnable condition, they aren't a single file, but they aren't many - maybe a dozen jars plus some scripts. Our build process puts all that in a tarball. Deployment comprises copying the tarball to the server, then unpacking it [1]. That is one step more than deploying a single binary, but it's a trivial step,…
Without any prior knowledge you can run my little go program on your computer.
Can that be said about your program with other people?
Re: The simplicity of single-file Golang deployments
#199I feel like i'm taking crazy pills (at a low dose) when i read this stuff. I deploy Java applications. In a runnable condition, they aren't a single file, but they aren't many - maybe a dozen jars plus some scripts. Our build process puts all that in a tarball. Deployment comprises copying the tarball to the server, then unpacking it [1]. That is one step more than deploying a single binary, but it's a trivial step,…
We also install the JRE separately, but each app is a single executable (by Java) jar, which stands up a jetty instance when run. We also add a yml for configuration. It's a much better packaging & deploy story than frontend code or python.
Java comes the closest of any of the languages to Go’s static binary.
Re: The simplicity of single-file Golang deployments
#200Earlier 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…
For 20 years that AOT compilers for Java exist, even if only available in commercial JDKs at enterprise prices (PTC, Aonix, Aicas, Excelsior, J/Rockit, Websphere RT). That alternative would be jlink, and GraalVM / OpenJ9 as free beer AOT.
GCJ was a thing for a while, but was never really production-ready.