But...the issue is packaging/distributing a CLI built with Elixir. Comparatively to building a CLI in something like Rust, there is a lot of overhead that comes with a VM-based language and framework. Especially if you want to target multiple OS and processor architectures (or distributions). Not to say that it is impossible, just maybe not as simple. It is one thing to run Mix tasks, or access the Owl API from REPL, it is another to run an Owl-based app on macOS, Linux and Windows and get it there.
It still has limitations (the biggest one is the requirement for the os&architecture to match between the builder and the deployment target) — but the result is a standalone binary which not only embeds the VM and preloads the app's bytecode, but even "trims" the stdlib to only ship the required functions.
Right, so the moral of the story centers on the target user of the CLI tool. If you're building something for the Elixir community - game on I suppose, though there is still the complexity of build-env per OS/arch.
I wonder where WASM/container enters the discussion.
> Firefly compiles Elixir applications faster and more efficiently than the BEAM can, and introduces WASI targeting to run applications in resource-constrained environments.
Containers are already solved, its trivial to build and boot a mix release - but whether that's appropriate for a CLI tool depends on the complexity of the tool I guess, but not too far from flatpaks etc no?
Undeniably it's not going to be as convenient, but the divide isn't what it used to be. BEAM apps can be compiled to a binary, and as long as that binary was compiled for the platform, that should be good enough.
I'm doubtful I'll see it used much outside the BEAM community, but then again it's been a "successful despite a lack of mass usage" community for awhile.
But...the issue is packaging/distributing a CLI built with Elixir. Comparatively to building a CLI in something like Rust, there is a lot of overhead that comes with a VM-based language and framework. Especially if you want to target multiple OS and processor architectures (or distributions). Not to say that it is impossible, just maybe not as simple. It is one thing to run Mix tasks, or access the Owl API from REPL, it is another to run an Owl-based app on macOS, Linux and Windows and get it there.