This can also be done with python and pyinstaller with the one file flag.
It can bundle assets and C++ libs, as well as sign the executable (eg. signtool).
Worked well for me for a zero-install bridge app.
The simplicity of single-file Golang deployments
171–180 of 232 posts
Re: The simplicity of single-file Golang deployments
#172I 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 restar…
You can see the daily restart as a restartability test. Programs expecting to run forever may develop "bad habits"
Re: The simplicity of single-file Golang deployments
#173I 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 restar…
They should, but you don’t know if they will, and, when they suddenly crash after two years, whether they will be able to restart. Restarting daily ensures that any problems will be caught early, and that the last known-good configuration is only a day ago and not two years ago.
Restarting daily also ensures you never find entire classes of lurking bugs involving memory leaks, in-memory caches, stuff like that.
Re: The simplicity of single-file Golang deployments
#174Earlier quoted context omitted.
> The fact that it produces a single static binary is one of the nicest things about golang. Not only that it can also cross compile for different architecture and operating systems.
So I always assumed this was the case for other compiled languages. Is this something special in Golang and/or recently created languages?
I think the main thing that's different about Go compared to more old-school languages is that the Go binary distribution includes the cross-compilers right out of the box. So anybody who can run "go build" can also cross-compile their application -- and, importantly, all of its library dependencies -- for any architecture that Go supports.
On the other hand, if you want to cross-compile a C program using GCC, you need to separately build and install a complete gcc+binutils toolchain for every individual arch that you want to target. And you have to handle the dependency management yourself, which may be tricky if your dependencies' build scripts weren't designed with cross-compilation in mind.
Re: The simplicity of single-file Golang deployments
#175Earlier quoted context omitted.
Directly addressing the topic of a upvoted article is starting random language fights?
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.
I think the comparison is totally apt and illustrates why Rust and Go get compared very often. They are both languages that compile to a binary, rather than running in a managed environment.
Re: The simplicity of single-file Golang deployments
#176When 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.
Not convinced, not if you built for e.g. Java 8. I think there's a decent chance there are more people running something other than x86_64 nowadays (and that number's only going up) than people who don't have a JVM installed.
Re: The simplicity of single-file Golang deployments
#177Earlier quoted context omitted.
They should, but you don’t know if they will, and, when they suddenly crash after two years, whether they will be able to restart. Restarting daily ensures that any problems will be caught early, and that the last known-good configuration is only a day ago and not two years ago.
Restarting daily also ensures you never find entire classes of lurking bugs involving memory leaks, in-memory caches, stuff like that.
On the other hand, they also never become relevant then.
Re: The simplicity of single-file Golang deployments
#178Earlier quoted context omitted.
> I don't see what's special or better about compiling everything into a single binary, apart from fetishizing the executable format. Indeed. If you think of the docker image itself as an executable format like PE or ELF, this becomes clearer. Rather than targeting the OS API, which has completely the wrong set of security abstractions because it's built around "users", it defines a new API layer. > "I can deploy by…
> 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.
"By itself" where? You're going to toggle it in on the front panel?
If you want to run an executable you have to have some kind of service (in the broad sent) set up to receive it and run it. Same with a docker image. Those services are, if anything, more readily available and standardised for docker than they are for executables.
Re: The simplicity of single-file Golang deployments
#179From 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…
I'm unsatisfied with the current situation too, but it's a hard problem. You can either go full container (which means no BSD, and having to deal with Docker or Kubernetes and all the associated woes), or fallback to native packages which are a huge PITA to build, deploy and use. I think that Nix and Guix have part of the solution: have a way to build fully independent packages that can be easily installed. But I'm n…
IMO if you're doing containers and cloud deployment then there's no point bothering with the OS layer. It'd be better to just build unikernels and deploy those directly. Some of the stripped down base images are going in this direction, and MirageOS looks pretty impressive although I've not been able to use it for real yet.
Re: The simplicity of single-file Golang deployments
#180Earlier quoted context omitted.
> The fact that it produces a single static binary is one of the nicest things about golang. Not only that it can also cross compile for different architecture and operating systems.
So I always assumed this was the case for other compiled languages. Is this something special in Golang and/or recently created languages?
No. Some bytecode compiled languages are compiled and require at least an archive to be unzipped or at least the virtual machine pre installed.
Java is an example -- you'll want your your system java deployment to match the stuff stashed in your jar.
Erlang is compiled but usually releases bundle the VM up with the project, so you typically deliver a full directory with the VM packed in there.