Should Elixir replace Ruby for simple scripting?

The only important thing to keep in mind when running these scripts (mainly with escript) is the fact that there is always a quite substantial delay when it starts, because it always spins a new VM instance.

Running them by hand should make no difference, however if you plan on using them in some automated fashion, this becomes a bottleneck very fast.

ahhhh, right. a very interesting factor… yeah i guess that’s why scripting/interpreted langs make sense for devops sorta stuff! hmmm..

This is not a interpretation issue per-say, because .exs files are also interpreted, but more of a performance problem of the VM when starting up.

From my understanding the penalty comes from the fact that application supervision tree starts all processes synchronously, this is a great feature for developers, because you don’t have to think about race conditions, but the price is performance.

At the same time I might be wrong and it is just something that will be fixed in the future, currently it doesn’t have a wide impact because most of the elixir applications work as long-running daemons.

Scripting doesn’t have anything to do with it, Ruby and Python have bootstrapping time that I find unacceptable as well as Erlang’s / Elixir’s. They all need time to get going.

For scripting I use bash / zsh if it’s something quick / one-off, or reach for Golang if I suspect I’ll use the tool regularly and need logic that bash / zsh make difficult to code (and sadly they have a lot of foot guns).

It’s “per se” btw.

Many of us would wet their pants if the BEAM has CLI parameters that would allow it to boot much faster (maybe at the cost of initializing apps slower? no idea), trust me. There was a discussion some months ago about it and there were various options listed even by core Erlang maintainers but none of them truly helped.

I think it would be nice, however I think this is not the right tool for CLI applications, at least not in the fashion of run this command and close.

I’ve had this problem before on a project, and what I ended up doing is to switch the strategy to a long-running process, that basically receives input and generates the output without closing the process, but of course there are many potential problems with this approach.

Yes, but only because of the slow boot time. If that got addressed then suddenly will be more than adequate for CLI apps, there are libraries making it easier too.

Eh. At this point it’s probably best to just rewrite it. Good for you that you made it work but we both know that it’s best to use the tools to their strengths and not try to bend them.

I think one of the solutions we can employ that will work currently would be to have a runtime started and run the scripts in the fashion livebook does, solves the problem and doesn’t require expensive and hard work from VM maintainers.

In that case it was not possible, the CLI was just a wrapper for a custom binary parsing library that we had to use on another project that was written in node, and it was easier from the perspective of infrastructure to ship it as a CLI and not as another service.

IMHO other tools definitely have better options for the sorts of scripts I find myself writing, although I tend to reach for sed, awk or sh (and occasionally perl) rather than ruby. By the time a script approaches something more like an ETL then I’m going to be writing a mix task, although nowadays I’ll be seriously considering livebook.

Depends on what you know. If you know Ruby well, I see no point to switch to Elixir for that. I still use Perl for simple scripting:

I’ve experienced two problems with elixir scripting 1) slow startup time 2) lack of ‘getch’. If neither of these matter to you, then Elixir is great for scripting! Check out Ratatouille a very nice TUI toolkit for Elixir.