Not really. Go, C, Rust, and even Python are much better for that for simple reason - you do not need whole VM to run such tool (and Python is commonly available OotB on many platforms). Additionally startup times in BEAM aren’t great, which mean that for short-living CLI tools it makes little sense, as startup is often main reason for “slowness” of such tools.

Again, not really, again, because of the slow startup.

If these tasks will be ran as a long running processes, then probably yes. There are tools for Elixir that make writing such applications much simpler and easier than in some other languages.

Everywhere where you will need long-running and IO-heavy workload that can be split into set small, independent, and isolated set of tasks (and REST API is perfect example of that) then Erlang/Elixir will be great choice.

Most of these are there because a lot of people are coming to Elixir from languages like Ruby or Python and are comparing it to the Go or Rust deployment cycle, where you either just dump sources on the server or you build one executable and dump that. However it is more like building C# assemblies (which are like Erlang applications) and deploying them to the Java Application Servers. For me it isn’t hard, you just need to understand that it is done in a slightly different way than you get used to. Erlang releases are more like Docker containers rather than Ruby on Rails deployments.

Erlang do not really have “executables”. The nearest what we can get are escripts, but these are more like JARs, where you have all code needed for the application to be ran, but you still need VM to run it.

Or whole web browser to edit text. I call these people “problem” as they are the reason for software bloat in recent years.

I believe @hauleth summarised it perfectly, so I’ll just echo some points:

1. CLI apps. Eh, no. I’d reach for Go or Rust when writing those. I don’t appreciate the startup pauses of the dynamic languages, Erlang and Elixir included. If you expect the CLI app to get very complex and big and want the expressiveness and ease of management of the FP languages like Elixir, then use Elixir. If not, just use Go or Rust.

2. General-purpose scripting is very far from data processing / scraping. Addressing them separately:

   • General-purpose scripting: IMO don’t. Really depends on what you want to do but so far I haven’t found use of Elixir as a quick scripting language. This is a really 50/50 advice though; if you give us more examples, you’ll get a more precise answer.

   • Data processing / scrapping: definitely yes. The OTP architecture lends itself very well to multi-stage workflows with a lot of parallelism involved. There aren’t many other languages that do this well in the area.

3. REST APIs, GraphQL, generic web apps, API gateways: Elixir is a perfect fit in my experience. Elixir apps almost never lag, they are robust and mostly self-recovering (with a little extra effort from your side) and are very fast which is counter-intuitive when you take into account that the language is dynamic. I rewrote two Rails apps to Phoenix and they got accelerated by 20x to 100x. I am not exaggerating; one of the both apps had a median response time of 280 - 320ms and when I finalised it with Phoenix its median response time dropped down to 2.5 - 3.5ms. Crazy.

4. Deployment is still not as brain-dead easy as compiling a single executable as in Go and Rust but it’s definitely not as hard as many impatient bloggers out there make it sound. Yes, you will have to sink one weekend in it. After that you’ll do it in your sleep.

Hope this helps you make an informed decision.

I too, and I often do not need anything more than AWK, sed, and shell. I understand that for some people Elixir can be easier, but at the same time this language wasn’t designed for it. This koan is about Vim, but I think it fits there as well:

One night there was a storm, and Master Wq’s house collapsed. The next morning he began to build it again using his old tools. His novice came to help him, and they built for a while and were making good progress. As they worked, the novice began to tell Master Wq of his latest accomplishments.

“Master, I have developed a wonderful Vim script to give all sorts of useful information about a document. It counts the words, the sentences, the paragraphs, and even tells you what kind of document it is using the syntax highlighting rules. I use it in my pipelines all the time. It is a thing of beauty, and I am very proud. Truly, Vim is the greatest tool!”

Master Wq did not reply. Thinking he had unwittingly angered his master, the novice fell silent and continued his work.

The novice finished aligning two beams and had positioned a nail ready for beating into the wood, but found the hammer was out of reach.

“Would you pass me the hammer, master?”

Master Wq handed the novice a saw.

At once, the novice was enlightened.

This marks few things:

• Go is a bad language, and I do not like it (in nice words)
• NIH is a problem, there is jq which probably would allow you to achieve the same thing with greater ease
• Unbounded mutability is bad as this makes following data flow at least hard