The issue with cli tools in elixir is the startup time of the BEAM is not trivial in the context of a cli tool. It takes about half a second to launch the BEAM, which means that certain classes of cli tools which require quick feedback are not going to feel very responsive. As well, releases are not as portable as you might think they are. They do bundle the Erlang runtime, but they call out to system libraries which must be the same as the ones for the OS you compiled on. In practice this means compiling on the same operating system and same version of the OS as you intend to deploy to. This makes cross compilation a lot more difficult than other languages like go, Rust, zig, etc which have a more modern cross compilation story.

That said, I do believe there is a niche for elixir apps in the console space. Similarly to a web app, if you create an interactive tui / ncurses style cli app, then the startup time becomes a negligible part of the overall runtime of your system. I have played with Ratatouille, which is a library for building these apps and I quite like it, it has some warts but it’s actually quite a nice way to build console apps. Based off of the elm architecture if you’re familiar.

I would love it if we could get the startup time of the BEAM down to the point where it wouldn’t make a difference for a cli app, but just due to the nature of the systems Erlang and elixir get chosen for I doubt that anyone will be willing to work on that any time soon.

I think of CLI tools as (mostly) falling into two (very different) categories: ‘Unixy tools’ and ‘interactive console apps’.

A Unixy tool absolutely would be (potentially) callable 100+ times (per second/minute/hour). The advantage of creating these tools as a ‘CLI’ is that they can then be combined with all of the other (existing) CLI ‘Unixy tools’, as well as being used by anything that can itself work with ‘Unixy tools’. The most recent example of these (that’s being used in an Elixir project I work on) is a tool to convert an HTML document to a PDF document.

(If there was an alternative Elixir library/app for these kinds of tools, I wouldn’t think there’s much reason not to use them (in another Elixir project), assuming all else is equal (e.g. the tools are relatively ‘good enough’ as is). It is of course often useful that these tools can also be used by all of the other Unix tools or any other programming language/environment/etc. that can also interface with them, which is almost all of them.)

‘Interactive console apps’ on the other hand are often (almost always?) NOT also ‘Unixy tools’. Tho sometimes CLI apps can work in both/either mode, e.g. some Git commands.

I don’t think Elixir is a bad language for interactive CLI apps but I found the ‘console graphics’ libraries to be pretty rough (tho I was testing them on a macOS computer and NOT a ‘regular’ Linux box). Issues like, e.g. BEAM startup time, are definitely less of an issue for these types of apps/programs.

Not sure if it matters, but OS X and BeamJit does not play well when it comes to upstart times at the moment. On my OS X laptop it takes about 0.4 seconds to run an escript doing nothing, while on my Linux machine it takes 0.1 seconds.

If you compile Erlang/OTP 24 with --disable-jit the startup time on OS X drops to 0.1 seconds as well, but then you don’t get any JIT so it all depends on what you are doing next if having the JIT is worth it or not

0.1 seconds is still a lot more than what a what a native program would do.