Why do you think Elixir is not suited for creating CLI tools?
Huge spin-up time, not as extensive set of traditional CLI code in it so youâll end up having to write a lot more code than the usual cases, etc⊠Itâs just a bad mix of huge spin up time, not fast, and no good DSEL for system work (yet?). The BEAM is designed for long running services, not simple scripts.
4 Likes
I think it depends on the use-case of your CLI application. If itâs intended as something that is going to be called over and over again by a third-party application, I would agree with you.
But if youâre creating a standalone CLI application - whether itâs for controlling a web service or processing local files, I think a couple of milliseconds of additional starting time donât really matter and Elixir would actually be an excellent choice.
â°â†time elixir -e 'IO.puts("")' 1 â”
elixir -e 'IO.puts("")' 0.22s user 0.07s system 33% cpu 0.851 total
Almost a full second just to startup and print nothing, thatâs a long time when running fast shell commands⊠^.^;
And yes, it bugs me with how long mix commands take⊠>.>
/me wishes mix had a running mode like sbt does with a mix shell we can run commands on or prefix a set of commands with ! or so to run on file change
Hmm, that would not be that hard to make actuallyâŠ
1 Like
@OvermindDL1 That should only be an issue for CLI apps bounded by startup time. Imagine a daemon CLI app that runs forever (think Emacs daemon kind of thing), or a CLI app that kicks off long running tasks. If 1 second is nothing compared to a job that kicks off several multi hour jobs, or is otherwise completely dwarfing that, it becomes much more attractive. Think a CLI app to orchestrate Kubernetes clusters, where each VM starting up takes several minutes and rollouts to pods may take days/hours and involve lots of intermittent failure. Under the hood, that may shell out or call go binaries as NIFs, but orchestrating an application like that in Elixir sounds attractive.
3 Likes
Then you should probably be building a full release. ^.^
Still ignoring the rest of it though, a lot of the ecosystem, language, and VM is just not efficient in a programming way for CLI work. Use the right tool for the right job after all. 
1 Like
Maybe you should describe what you mean by CLI work. You can start all programs from the command line after all.
1 Like
For me I mean things that are quick runs that I manually run from a command line generally stringed with other commands. If itâs something that is long-time running then it should be a service and I start it as such.
To give a practical example: The command-line client for CloudFoundry for orchestrating your CF deployments is written in Go and can be downloaded as a single binary.
I also created a command-line tool for my software distribution platform DBLSQD. I might have written it in Elixir if there had been a more convenient way of packaging it but there wasnât, so I went with Node instead.
1 Like
Personally I would call Beats a âCLI appâ. It is a ncurses based drum machine and I think that Elixir is well suited to it and I think it would be great if it was possible to easily build it into a binary for running from the command line.
This is what it looks like:
Github: GitHub - mtrudel/beats: Beats is a drum machine
Conference talk: https://youtu.be/XN4WuOujr38?t=1102 (video set to load to beats-specific section)
No, thats not a CLI application, thats a terminal based application or sometimes seen as TUI application (Text/Terminal User Interface).
CLI means Command Line Interface, so it describes a tool, which you can fully operate through the command line, usually without asking for user feedback, or at least making it optional (eg. apts --yes switch or pacmans --noconfirm).
4 Likes
I wonder what the state of Erlangâs LLVM support is. Thatâs how the Scala folks are attempting to bring Scala to the CLI world.
That is perfectly fine, having in mind that Erlang / Elixir are aiming at long-running services and servers and not one-off scripts. In that area Go and Rust are hard to beat and that is okay. You donât need to use Elixir for absolutely everything. It already does quite a lot.
5 Likes
18:15:08 cees@cees-MBP-Linux:~/tmp/foo$ mix escript.build
Generated escript foo with MIX_ENV=dev
18:15:12 cees@cees-MBP-Linux:~/tmp/foo$ time ./foo
hello, world
real 0m0.179s
user 0m0.166s
sys 0m0.056s
7 Likes
Good catch. ODLâs example has to load the compiler. Naked ERTS isnât so bad.
1 Like
Until you loop while calling it. 
