Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Warp – self-contained, single binary applications

github.com

Post reply on HN
Print view View original

21–30 of 157 posts

Re: Warp – self-contained, single binary applications

#21

Post by mayank »

open-source-ux wrote: post #11

It'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…

It's understandable due to RAM, disk, and network being way less of a constraint than it used to be (which necessitated dynamic linking and shared libraries), and the modern need to ship around binaries to hundreds or thousands of servers and have them run predictably everywhere.

Re: Warp – self-contained, single binary applications

#23

Post by weberc2 »

jpic wrote: post #8
w8rbt wrote: post #4

Very neat. Would like to see more languages targeting single binaries. This is one reason (I believe) that has made Go so popular.

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

Re: Warp – self-contained, single binary applications

#24

Post by weberc2 »

Koshkin wrote: post #20
weberc2 wrote: post #15

Earlier 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?

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

Re: Warp – self-contained, single binary applications

#25

Post by meddlepal »

jpic wrote: post #8
w8rbt wrote: post #4

Very neat. Would like to see more languages targeting single binaries. This is one reason (I believe) that has made Go so popular.

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.

Re: Warp – self-contained, single binary applications

#27

Post by monocasa »

matthewbauer wrote: post #18

I think it’s funny to use java as an example when jar files have been around forever. Still there are some use cases for other things where statically linking is not possible. I wonder what benefits this has over other solutions? Originally when it said multi-platform i thought it meant that one binary could run on multiple platforms like a fat binary. But i think all of the examples require you to have a specific ta…

There's something to be said for the fact that these are native binaries. Like under windows you'd be able just call CreateProcess with the file. Jars never did that and intrinsically needed an interpreter to run them.

Re: Warp – self-contained, single binary applications

#28

Post by eeZah7Ux »

weberc2 wrote: post #15
open-source-ux wrote: post #11

It'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…

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

Re: Warp – self-contained, single binary applications

#29

Post by rkeene2 »

w8rbt wrote: post #4

Very neat. Would like to see more languages targeting single binaries. This is one reason (I believe) that has made Go so popular.

Tcl is still the king of this kind of distribution with Starkits/Starpacks. Since you can virtualize the filesystem within Tcl, you can pack in all your resources as regular files and generally scripts will work without knowing that this has happened (and without hacky extracting of the archive to disk before running, or while running).

Re: Warp – self-contained, single binary applications

#30

Post by rkeene2 »

wildmusings wrote: post #9

From the README, it looks like this unpacks the application and dependencies into a local cache in the user's home directory on first run. Is it possible to instead execute the compressed application code directly and present to the resulting process a virtualized file system that decompresses the dependencies on the fly too? Then you could run the single binary without giving it any filesystem access. One way to do…

This is in fact what Tcl Starkits/Starpacks do -- all access to the filesystem goes through the Tcl VFS, which can be redirected to the script level.
Post reply on HN