Very neat. Would like to see more languages targeting single binaries. This is one reason (I believe) that has made Go so popular.
By the way, if you are looking for a tool to embed resource files in Go binaries you might find these interesting:
Warp – self-contained, single binary applications
31–40 of 157 posts
Re: Warp – self-contained, single binary applications
#32Earlier quoted context omitted.
> disk is far cheaper Not in the cloud.
To be clear, you're asserting that the price of disk in the cloud is comparable to what it was decades ago?
Things are more complicated than that. (Depending on the pricing scheme, you might end up paying per gigabyte per hour, for example; which may or may not include transfer/storage of actual data; a faster "drive" could be much more expensive than a slower one, etc.)
Re: Warp – self-contained, single binary applications
#33It's fascinating how self-contained binaries are now coveted as such a desirable feature. Dozens of languages (if not more) were capable of this decades ago. In fact, some of them could generate self-contained binaries that allowed you to bundle app assets like icons and images inside the executable - no additional add-ons needed. And they were native executables, not complicated wrappers with layer upon layer of dif…
That trend suggests that previous efforts are either not discoverable or not sufficiently extensible.
Re: Warp – self-contained, single binary applications
#34It's fascinating how self-contained binaries are now coveted as such a desirable feature. Dozens of languages (if not more) were capable of this decades ago. In fact, some of them could generate self-contained binaries that allowed you to bundle app assets like icons and images inside the executable - no additional add-ons needed. And they were native executables, not complicated wrappers with layer upon layer of dif…
Yes, I remember when it was such a big deal that we could finally use dynamic libraries on Amiga OS, MS-DOS protected mode and Windows 3.x.
Even GNU/Linux made such a big deal of moving from a.out to ELF binary format, due to easier support for dynamic linking, which quite cumbersome with a.out.
Now almost 30 years later it is a big deal to support static linking, go figure.
Re: Warp – self-contained, single binary applications
#35Earlier quoted context omitted.
I wish also had this. However, containers work. Not sure why they do java though, i thought java has been happy with jars so far.
We're struggling using containers for our Python and Javascript applications. I think we're using venvs and node_modules and we oughtn't (or we shouldn't keep them in our project directory where they sometimes--but not always--get overwritten by source code volume mounts).
For Python, this works well for my team: https://www.dharmab.com/programming/python/docker/2017/07/24...
Re: Warp – self-contained, single binary applications
#36It's fascinating how self-contained binaries are now coveted as such a desirable feature. Dozens of languages (if not more) were capable of this decades ago. In fact, some of them could generate self-contained binaries that allowed you to bundle app assets like icons and images inside the executable - no additional add-ons needed. And they were native executables, not complicated wrappers with layer upon layer of dif…
> This is not take anything away from this project, just making an observation. The programming field often feels like it's in a giant loop constantly re-discovering what went before. I think part of this comes from various tradeoffs becoming more or less important at different times. Processing power goes up so you move to fat clients, then people move to battery powered devices and heavy lifting makes more sense on…
It's not really processing power so much as storage and RAM that used to be seen as the disadvantages of static binaries. The advantages of the static binary model are that it avoids "DLL hell" and makes sourcing dependencies a bit better, which are indeed laudable aims.
But nowadays it has terrible security (and to some extent reliability) trade-offs - if everything is a static binary and there's a security issue in a library, you need to upgrade every single binary depending on it, which is much less reliable and more prone to error/oversight.
As security and reliability have increased in importance, so the "cost" of the static binary route has actually gone up significantly in my view compared to 20-30 years ago. So it's a bit odd to me to see this model (and closely related ideas like flatpak etc) gaining currency. There must be better ways to manage the "DLL hell" issues than that.
Re: Warp – self-contained, single binary applications
#37Earlier quoted context omitted.
> The programming field often feels like it's in a giant loop constantly re-discovering what went before. It might feel that way, but this is driven by economics. Basically disk, memory, and bandwidth is far cheaper than it used to be so who cares if you waste a GB or so copying the same libraries all over if you don't have to solve for dependency hell?
Vendorizing libraries and static linking has become a security hell. Just an example: https://blog.acolyer.org/2017/04/03/a-study-of-security-vuln...
Your link cites "little thought to the inclusion of dependencies", _not_ static linkage, as the cause of this "hell".
Re: Warp – self-contained, single binary applications
#38Earlier quoted context omitted.
I wish also had this. However, containers work. Not sure why they do java though, i thought java has been happy with jars so far.
JARs are okay, but they still require you to have the java runtime installed in order for them to execute.
You can bundle everything together, or use a commercial JDK with AOT compilation support.
Re: Warp – self-contained, single binary applications
#39Earlier quoted context omitted.
I wish also had this. However, containers work. Not sure why they do java though, i thought java has been happy with jars so far.
JARs are fine until you need to get someone to install a JRE. Not a problem for server apps, but definitely not painless for client distributed apps.
You can bundle everything together, or use a commercial JDK with AOT compilation support.
Re: Warp – self-contained, single binary applications
#40Earlier quoted context omitted.
To be clear, you're asserting that the price of disk in the cloud is comparable to what it was decades ago?
Things are more complicated than that. (Depending on the pricing scheme, you might end up paying per gigabyte per hour, for example; which may or may not include transfer/storage of actual data; a faster "drive" could be much more expensive than a slower one, etc.)
Sorry, I'm not following. Granted pricing schemes have changed, but adjusting for that, are you claiming that disk is not dramatically cheaper than it was ~20 years ago? Not trying to be a dick, just not following your point.