5 ms·

> 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 ki

> 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.

dljsjr 6y ago
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.
pjmlp 6y ago
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.
- oblio 6y ago
  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).
  - pjmlp 6y ago
    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.
    - oblio 6y ago
      > 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-have-a-linker/ https://www.joelonsoftware.com/2004/01/28/please-sir-may-i-h... (which I agree with)
      - pjmlp 6y ago
        > 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.
        oblio 6y ago
        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.
        pjmlp 6y ago
        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.
- gouggoug 6y ago
  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.
  - pjmlp 6y ago
    Not everyone is blessed with such connections, without data caps.
    - simias 6y ago
      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.
- simias 6y ago
  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.
  - eeZah7Ux 6y ago
    > 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.
mpoteat 6y ago
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.
zelly 6y ago
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.
- pjmlp 6y ago
  Not if plugins come into play, unless you want to go OS IPC for that.
- DougBTX 6y ago
  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.
  - nickjj 6y ago
    > 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.
- deleted 6y ago
  [deleted]

dljsjr 6y ago

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.

pjmlp 6y ago

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.

oblio 6y ago
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).
- pjmlp 6y ago
  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.
  - oblio 6y ago
    > 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-have-a-linker/ https://www.joelonsoftware.com/2004/01/28/please-sir-may-i-h... (which I agree with)
    - pjmlp 6y ago
      > 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.
      - oblio 6y ago
        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.
        pjmlp 6y ago
        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.
gouggoug 6y ago
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.
- pjmlp 6y ago
  Not everyone is blessed with such connections, without data caps.
  - simias 6y ago
    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.
simias 6y ago
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.
- eeZah7Ux 6y ago
  > 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.

mpoteat 6y ago

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.

zelly 6y ago

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.

pjmlp 6y ago
Not if plugins come into play, unless you want to go OS IPC for that.
DougBTX 6y ago
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.
- nickjj 6y ago
  > 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.
deleted 6y ago
[deleted]