Just saw this on Twitter, looks really neat! What’s your take on it?
4 Likes
Idea is neat, but I think that in 90% of deployment cases it is not really needed. Of course, it will make some stuff clearer for the newcomers (big pro), but in long term I think that “regular tarballs” aren’t problem at all (as this project is exactly that - tarball with auto decompress) as most of deployment tools can handle unpacking for you anyway.
I doubt that it will become part of classic server deployments as well. E.g. I’m using rsync instead of sending a tarball, which makes updates even quicker.
I much rather see this useful for cli stuff. Also it’s something to point people two who keep complaining about the lack of binary deployment options 
2 Likes
Im excited about this for two very non-web-app-deployment scenarios.
- Desktop elixir apps with Scenic could be fun
- CLIs. I write a lot of CLI apps for devopsy/sre-ish tasks and I pretty much us go for this when bash becomes a nightmare. I’d love to not have to switch mental models and try to write some CLIs w/ escript in a single team-sharable binary.
5 Likes
I’m excited about this, and have an immediate use case. I’m doing a browser automation project, and want whatever thing does my browser automation to run directly on the user’s computer so that they can do browser automation stuff in their local network. Right now I’m writing an electron app that runs puppeteer. When this drops I could potentially package my app into a binary and deliver it directly to the user, and bring up the local chrome instance, and the remote debugger interface and do everything local on the users machine.
I have at least 1 customer who has major restrictions on using any sort of cloud software without a long chain of approvals.
1 Like
Hi it is not my project so best to remove my tweet there IMO
Please direct your praise towards the following individuals
1 Like
From the repo:
Creating cross-platform binaries
Bakeware binaries include the Erlang runtime but there are still dependencies on the host system. These include the C runtime and other libraries referenced by the Erlang runtime and any NIFs and ports in your application. Luckily, the binary ABIs of many libraries are very stable, but if distributing to a wide audience, it’s useful to build on a system with older library versions. Python has a useful pointers in their packaging guides.
If I am understanding correctly this doesn’t solve completely the issue of compiling for cross-platform as it’s solved in Rust or Go. Am I am missing something?
Yes but nowadays it is quite easy to spin up a virtual machine to run your target OS or rent a machine from Amazon that has your target architecture… and bake there.
Why bother cross-compiling 
I agree its easy but faraway from the user experience of Rust and Go.
Plus you need to be sure that the individuals machine has the correct dependencies.
So, cross-compilation remains an unsolved problem for the BEAM. It’s easier but is not solved, unlesss I am missing something.
Anyway, it awesome to have this project to be some steps closer 
