I believe after a while you also had sqlite-inside-the-exe things.
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 not comfortable with the complexity of Nix, and Guix does not run on FreeBSD. And ultimately you still have to handle distribution and configuration of the base system you deploy on.
Innovation is possible, but there are a lot of expectations for any system dealing with building and deploying software. I feel that there are fundamental limitations inherited from the way UNIX OS work, and I wish we had lower level operating systems focused on executing services on multiple machines in a way similar to how mainframes work. One can dream.
> I feel that there are fundamental limitations inherited from the way UNIX OS work
There are, but the way go does deployments plays to Unix's strengths.
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.
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.
Also, disks are a horrible way to deploy software. They have all the same problems of just distributing a random tarball: What operating system is it for? What version? Where do I copy the files? How do I get the OS to automatically start the service on startup? What version of make does it use? How about which libc and cc? You can say this stuff in the README (or printed docs) but isn't something more "deployable" when it's all machine-readable and can be reasoned about automatically? This is what package managers were invented for.
Go supports embedding assets since 1.16, the author mentions embedfs in the post.
From the article: "The Go web application had all files like configurations (no credentials), static css and html templates embedded with embedfs (and proxied through a CDN)."
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?
What I do in my projects is that I tell varnish-cache to cache assets in "/static/..." forever. And when I have a "curl -X PURGE <varnish_endpoint>" 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...
Of course, at the end it's a question of preference. People might disagree.
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.
"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 for innovation here, and were over due for some change.