Thank you all for your replies! This is why I love this community

As @bbense says, I could use Ruby, Perl or Python. In fact the tool I am going to build is a replacement for an existing one that is currently written in Ruby. I am choosing to replace it because if I want to use the tool everywhere on my system, I have to add the gem in the global Ruby installation. This should not be a problem if the tool did not require other gems which get also installed globally. I consider this a little dirty and it is what I would like to avoid.

The idea of @brainbag and @Onor.io resembles more closely what I have in mind. Building an escript would allow me to distribute my package as a single binary with its dependencies bundle (it would still require the Erlang VM, but so happens with JARs).

I am going to opt for Go or Rust (I like more the Rust approach because it is more close to functional programming) because I want to keep the dependencies absolutely minimum, the ideal would be to distribute a binary that could be run as is. I am a little bit sad about not using Elixir, but @bbsense has a point when he says that “Where Elixir really shines for this kind of stuff is when you have a 24 core server and enough work to keep those cores busy”.

So, Go or Rust it is. Thank you all!

I’ve been using a cli project as an excuse to learn Rust. I considered a lot of the same things at first. Since my project has zero network interfacing, Elixir seemed like overkill. I’ve used Go before and although it was kinda fun, I didn’t get hooked in any where near the same way Rust or Elixir got me. FWIW, there is a lot of fast software written in Go.

So you don’t use any Ruby, Perl or Python?

As far as I know, only the only choice for a completely stand alone binary these days is Go.
( I’ve no idea what Rust’s runtime, need to check that out).

Even boring old C is dependent on shared libraries.

Everything I’ve written in Elixir is a cli more or less. Where Elixir really shines for this kind of stuff is when you have a 24 core server and enough work to keep those cores busy. That’s not every cli app, but if you have that scale of problem, it’s so much easier to deal with in Elixir.

While the default erlang runtime is 200meg, there is a lot that can be trimmed; escripts only require the erlang runtime. While maybe not comparable to a minimal Ruby or Python installation, it’s certainly the same as any Java app. Elixir cli’s at least start much faster than most java apps I’ve used, they do have a minimal runup time that makes them less than ideal for some uses.

I have written several CLI tools in Elixir now using escript, including the specific one you mentioned (remote API) and I love it enough that I’ve been using it instead of Ruby. I’m not certain about distribution though since I haven’t had any reason to share it.

Set up the project for CLI:

# add to mix.exs in the project function
[app: :myproject, 
...
escript: [main_module: YourProjectName.CLI],
...]

Create the entry point:

defmodule YourProjectName.CLI do
  def main(args) do 
    # - use OptionParser to parse args
    # - use IO.ANSI for color
    # - use System.halt(code) to exit with an error code
    # - use ExUnit.CaptureIO to capture terminal output for testing
    IO.puts "Howdy Earth!"
  end
end

Build and run

# build it
mix escript.build

# install it into your path
mix escript.install

If you use a release though the VM is indeed bundled in.