Very neat. Would like to see more languages targeting single binaries. This is one reason (I believe) that has made Go so popular.
Here's one for Lua: https://github.com/ers35/luastatic
Warp – self-contained, single binary applications
91–100 of 157 posts
Re: Warp – self-contained, single binary applications
#92Earlier quoted context omitted.
It can be a little tricky to do things right here. There are a few things of note: 1. The .dockerignore file can be used to prevent use of your `node_modules` folder during `docker build`, even if you have something like `COPY . .` in your Dockerfile.. This can let you create a new `node_modules` folder from your lockfile as part of the docker build process to create an image for testing/deployment. 2. You can mainta…
Thanks for the suggestions! I had to check, but we do both of those things. To make sure that node_modules aren't overwritten, we mount an empty named volume to the node_modules directory. I guess mounting the named volume directory somehow causes the node_modules directory from the base image to appear inside of the bind-mounted directory. We do the same thing for venvs as well. We use venvs inside of the Docker con…
Named volumes are hacky to no end and you shouldn't be using them to make sure it's empty; you should be using `.dockerignore` or being careful about what you copy in.
The pipenv bit is probably more reasonable, and I'm afraid I haven't used it enough to be sure what rough edges are likely there.
Re: Warp – self-contained, single binary applications
#93Latest .net core 3 apparently supports single-bibary packaging. It has been a often-requested feature for at least 2 years. https://github.com/dotnet/corefx/issues/13329 (The last comment referring to warp is indicative)
.Net Core 3 wont be out until next year. The current .Net Core 2.x runtime has had this feature since it came out though (last year?). (Hello world + runtime is like 100 MB and several hundred files)
For what it's worth, the IlLinker can get Hello World down to 20MB and as many files:
https://github.com/dotnet/core/blob/master/samples/linker-in...
If you use some extra options to disable crossgen and link System.Private.CoreLib, you can get the size down to 10MB, at the expense of startup time:
Re: Warp – self-contained, single binary applications
#94It'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…
Typing me some Nim and shaking my head.
Passing -static to the linker, I get neat, robust, non-dynamic executables, typically in the low MB or even kB size-range.
const varname = staticRead"filename" embeds a given resource at compile time - to make the project completely selfcontained if need be, and just for the hell of it.
I know you can do this in several other languages, but the Nim way is - unsurprisingly - the most ready-made, obvious and transparent one I've come across.
Re: Warp – self-contained, single binary applications
#95It'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…
We passed through a period where shared libraries were a great way to save storage and memory, but now dependency management has become such an incredibly headache that it's driving us back to monolithic binaries.
Re: Warp – self-contained, single binary applications
#96I 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…
> I think it’s funny to use java as an example when jar files have been around forever.
?
Jar files are not a self-contained, single binary (executable).
I can't
curl -o binary http://example.org/binary
./binaryRe: Warp – self-contained, single binary applications
#97Very 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).
Python can do something similar albeit far simpler via packaging as an executable zipfile. Just structure everything you need in a directory and zip up with __main__.py in the root. All resources are available as an in-memory binary stream, including individual source .py files. Of course if you want to package something like a C library, you need to unpack that to disk to be able to access it with ctypes.
Re: Warp – self-contained, single binary applications
#98Earlier quoted context omitted.
This solves some of the app packaging pain that goes into building desktop apps. Not sure how this works but it probably bundles dependencies into the binary a la static linking. Docker mocks the OS and virtualizes, its a very different approach I'm stoked for anything that eases the pain of desktop deployment that isn't Electron. Right now the cross-platform story is... complicated
But it seems like it continues one of the pain point of Electron: Shipping hundreds of MBs in the same dependencies for every single app.
Indeed, but it's either that or you deal with the dependencies at deploy, or you write your software to not have any dependencies.
Re: Warp – self-contained, single binary applications
#99I 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…
> I think it’s funny to use java as an example when jar files have been around forever. ? Jar files are not a self-contained, single binary (executable). I can't curl -o binary http://example.org/binary ./binary
In reality, you can't do that with these either. You have to have the runtime installed before your example works.
It's really not much better than running a fat jar that contains all of its dependencies.
curl -o binary.jar http://example.org/binary.jar
java -jar binary.jar
Re: Warp – self-contained, single binary applications
#100Earlier quoted context omitted.
This. A .jar file could be anything. Is it a library or an executable? When I run it, do I need to make sure its dependencies are on my classpath? What're the java command line flags I need? Do I have the right version of java on this machine? There's something to be said for an entirely self-contained native binary, at least as an easy on-ramp for users.
You can build "fat jars" that contain all dependencies. IMO, this is how most Java apps should be deployed.
You still have issues of needing a JVM. The JVM is not a small runtime considation. I'm in the process of converting to GO since I have more time than money. 1 JVM in Docker uses 512 MB to sit still. A Go version is around 16.