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.
OvermindDL1
wmnnd
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.
0
OvermindDL1
╰─➤ 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
asummers
@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
OvermindDL1
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
CptnKirk
Maybe you should describe what you mean by CLI work. You can start all programs from the command line after all.
1
OvermindDL1
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.
0
wmnnd
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
axelson
Scenic Core Team
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 · GitHub
Conference talk: https://youtu.be/XN4WuOujr38?t=1102 (video set to load to beats-specific section)
0
NobbZ
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