Just a note that you can do the same now with .net: https://learn.microsoft.com/en-us/dotnet/core/deploying/sing...
The simplicity of single-file Golang deployments
161–170 of 232 posts
Re: The simplicity of single-file Golang deployments
#162The 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.
From what I have seen in major OSS projects like systemd and PostgreSQL, nothing seems to support static linking, to the point where some contributors get annoyed when you ask for it. Seems like the C/C++ ecosystem will stay dynamically linked, even with a lot of the industry shifting towards statically linked, fat binaries as disk space is pretty cheap. I wonder how much simpler Linux packaging would be if everythin…
Funnily enough I was looking at an issue in my one of personal projects last night about asking me to statically link libstdc++ - it's something I was interested in doing because I spent way too long spinning my wheels on an issue caused by loading an outdated libstdc++.so.6, but I read that statically linking can cause issues if your code loads another library that dynamically links libstdc++... which I'm pretty sure my project does (it's a pass-through between an executable and another library).
So I want to, but it sounds like if I do it might work but be fragile at best.
Re: The simplicity of single-file Golang deployments
#163The 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.
Can you link something substantial, like Firefox, statically on NetBSD?
Re: The simplicity of single-file Golang deployments
#164I 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.
Re: The simplicity of single-file Golang deployments
#165Earlier quoted context omitted.
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
That is the thing, though. For most applications, those vulnerabilities in a common library are not relevant. That is what I was talking about in saying that it is in code that isn't used by them.
You are, of course, right that it has the possibility of happening. But by and large, it doesn't happen there any more often than it does in the dynamically linked cases. And, by and large, the dynamically linked cases are often a lot more complicated to deploy. (Granted, deployment for either should be doable nowadays.)
The dream, of course, is you just patch the library and call it a day. The reality seems to usually be a circus check on every application that you have deployed to see if they are impacted anyway.
Re: The simplicity of single-file Golang deployments
#166I'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.
Sometimes it does scale.
Re: The simplicity of single-file Golang deployments
#167I 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,…
Your footnotes basically invalidate your argument. You aren't just deploying a tarball, you also have to deploy the java runtime and make sure it's compatible with your application. I agree that Go fans make too much of the single binary feature, but it does seem easier than your deployment process. Of course your process is easy for you because you built it to fit your needs. But if you imagine a new developer who h…
> you also have to deploy the java runtime and make sure it's compatible with your application.
That’s not much of a problem in practice though. The JDK is just a tarball as well. You can even combine it with your application tarball into one! (With the drawback that now you have to create one combined tarball per target platform.)
Re: The simplicity of single-file Golang deployments
#168The 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.
> 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?
Re: The simplicity of single-file Golang deployments
#169Earlier 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?
The matter isn't the binary size of the update. It is the size of the crowd of people and parties involved in the update: For a bunch of statically linked applications, you need to involve all the application people/vendors. For a bunch of dynamically linked applications depending on a shared library, you (ideally) just need to involve the one library's people/vendor.
And "involve" might mean: wait for a bunch of unresponsive external parties to produce a new binary each for a security issue they might not care about. Of course on very different timelines, etc.
Re: The simplicity of single-file Golang deployments
#170Earlier quoted context omitted.
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.
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.