Hacker News Reader

Comment by Hokusai | Hacker News Reader

> A lot of languages are doing single static binary deploys now

As a developer for more than 30 years, I find that statement quite interesting. When I was a kid I was very happy to find a way to compile Basic to an executable like I was doing in Pascal and C++. For me is the standard way of thinking about applications.

Is it a common experience to actually have to ship many files for one application? I thought that it was just common for the web as it fits how HTML evolved not for anything else.

View on HN

Same here, the static linking hype feels real strange, given that was the only option we used to have back in the day, and having access to dynamic linking on 16 bit platforms felt like liberating.

PHP, JavaScript, Python, Ruby, even Java and C# didn't (don't?) have a mainstream way to create a single binary with unused code and unused dependencies removed.

Dynamic linking was cool because you could use system dependencies which people don't want to use because you can't rely on them, especially for cross platform apps and also for efficiency, RAM (which people stopped caring about) and, disk space (this boat sailed a loong time ago) and compilation (we have 10000x as powerful computers now).

Java has had static linking support since around 2000, for embedded deployments.

C#, yes it has been mostly dynamic.

PHP, JavaScript, Python, Ruby, don't count, they are scripting languages, bundled with an interpreter.

Still, Python and Perl bundlers exist since around 2000 as well.

Compiled languages like Basic, Pascal, Modula-2, Ada, Eiffel, Modula-3, C, C++, Haskell, OCaml, SML, .... all started in days where static linking was the main option.

> Java has had static linking support since around 2000, for embedded deployments.

Yeah, but for non-embedded deployments i.e. 99% of Java code out there?

> Still, Python and Perl bundlers exist since around 2000 as well.

I don't know the Perl one, but the Python ones definitely aren't mainstream. They're finicky and relatively hard to use and definitely not distributed with the Python distribution, which would make them ubiquitous and well supported.

> Compiled languages like Basic, Pascal, Modula-2, Ada, Eiffel, Modula-3, C, C++, Haskell, OCaml, SML, .... all started in days where static linking was the main option.

Every language in the olden days had static compilation support :-))

That's why we had articles such as these: https://www.joelonsoftware.com/2004/01/28/please-sir-may-i-h... (which I agree with)

> Yeah, but for non-embedded deployments i.e. 99% of Java code out there?

100% of commercial JDKs have support for AOT compilation, what you are getting nowadays on OpenJDK is the free beer version of it.

> I don't know the Perl one, but the Python ones definitely aren't mainstream.

They surely were mainstream on Windows back in .com days, specially via py2exe and ActiveState tooling.

> Every language in the olden days had static compilation support :-))

Many of which are still mainstream languages.

I know you're aware of this, but 70% of the languages in your list are niche languages and especially for web development they weren't that popular.

It was (is?): PHP, Javascript, Java, Python, Ruby, C# or nothing.

Especially the dynamic languages are extremely popular, primarily with smaller companies and startups.

The whole point of my discussion doesn't have anything to do in which field the languages are popular.

Zope and AOL Server teached me that those dynamic languages are really only good for OS scripting tasks anyway, but that isn't the subject of this thread.

It is the point of the thread :-)

For many developers, maybe the majority, those languages are their objective reality. They haven't used anything else, they might not ever use anything else.

So things which extend the range of their tools are very much appreciated.

They're not going to shun their existing programming languages because other people don't like them and they're not going to switch to OCaml or to commercial Java compilers, either ;-)

Ruby has some options too, one of them being ruby-packer. Here's[0] how I used it to generate single executables.

[0] https://nts.strzibny.name/making-a-ruby-executable-with-ruby...

I imagine dynamic linking solved a problem for a long time that no longer is: binary size.

With internet speeds of today and immense storage sizes, the main attractiveness of dynamic linking vanished.

Not everyone is blessed with such connections, without data caps.

Even then, in general code size is not a significant part of an application's size, various assets are. I'm working on a 10k lines rust application with 74 direct and indirect dependencies and the resulting static binary is less than 3MB in size (less than 1MB xz-compressed). That would've been a significant amount of storage in the 90s but it's almost negligible nowadays.

And given that shared libraries need to be installed and updated separately and they have to ship the entire code of the library (whereas a static binary can be link-time-optimized to get rid of unused code) it might not always be a win in terms of total bandwidth.

I don't really see the hype, I think it's just the intersection of a few factors:

- Languages like Rust which have an ecosystem that evolves very quickly (and uses complex symbol mangling schemes that would break all the time) wouldn't fare very well with dynamic linking in the first place. What good is dynamic linking if you need a different version of your .so file for every binary?

- Dynamic linking is not quite as useful today a it was in the past. Code size is not usually very significant, either on cold storage or in RAM. Actually for RAM it's cache usage that matters most, and static linking can usually be more efficient here through LTO.

- Over the past ~2 decades a new generation of developer arrived and many of them (in my experience) barely use "low level" compile-to-machine-code languages. They often specialize in scripting languages or languages that require a framework. Some of these developers are now learning Go or Rust and for them the idea of shipping a single ELF binary that packages the entire app might be seen as a novelty or maybe even as an innovation.

> Dynamic linking is not quite as useful today a it was in the past

Linux distributions need to be able to backport security fixes to shared libraries, test them and deliver updates to all users quickly.

With static linking it becomes practically impossible.

Containers changed the game. 99% of Deno/Go/Rust server software will be running on containers in practice. You're no longer deploying to a system running other programs which may share pages. It's a container, not a process. Dynamic linking in a container is just a vestigial useless step.

Not if plugins come into play, unless you want to go OS IPC for that.

Interesting, that’s the opposite of my experience. Containers allow bundling up lots of dynamic dependencies together so that they can be installed as a single unit. Static binaries can just be deployed as a single file, no need for containers.

> Static binaries can just be deployed as a single file, no need for containers.

Sure but most web apps are more than a single binary. There's generating static files, a database, background worker / cache, and more. Then there's wanting to be able to develop that project as a whole on Windows, macOS and various Linux distros as well as deploying it to a specific distro of Linux (most likely). Then there's the distribution of the binary across a network in a reasonable way.

Docker and its ecosystem of tools solves all of those problems once your app is containerized. And if you want to go 1 step further and run a distributed system with load balancers and friends, container orchestration tools let you solve this problem at a level above your application.

And the best part is you can do all of that in the same way with any tech stack.

The issue I see with this approach is that library code is duplicated among applications. In the limit, this is how you get every Electron app bundled with Chromium.

It's a little more complicated, but modern Node development is a huge step forward to the old days of sadly attempting to get the LINPACK header configuration correct in your C project.

In the case of the above listed languages, it's not just that the application is compiled to a single executable, it's that they're statically linked/truly self-contained. The only thing they dynamically link against is the OS's standard library. So there's no "DLL hell" either.

Reply on news.ycombinator.com