Hacker News Reader

Comment by lycos | Hacker News Reader

I love using Elixir but I also like to think "right tool for the job" and imho Elixir is generally not the right tool for the job for command-line user interfaces. It's fun to experiment with though, of course.

Having said all of that that, something like this might be useful when writing custom Mix tasks inside Elixir projects!

View on HN

Elixir is having a big push into machine learning (checkout Nx and Axon) and generally is also great for doing data streaming processing so you could imagine tools cropping up that might have it's primary interface be a CLI... this would be a great fit for those use cases.

I rewrote all my CLI scripts in Elixir, it's best in class IMO. With Mix.install now it's just amazing. Fast, free and simple concurrency, low startup time, great ecosystem, very good system level abstractions and functions in the stdlib.

I completely agree with GP in that Elixir isn't really _designed_ for CLI tools, but I agree with you that it does happen to be great for it. I don't doubt there are some facilities it lacks that would make ones life easier, but overwhelmingly its standard library is more than sufficient.

Are any of these published or would you share an example?

Nothing published, they're typically not very complex.

Things of interest for CLI stuff:

    #!/usr/bin/env elixir

Use Mix.install like so

    Mix.install([
      {:jason, "~> 1.4"},
    ])

Execute shell commands

    {output, status_code} = System.cmd("ls", ["-la"])

For handling files and paths:

    Path.join/2
    __ENV__.file
    Path.dirname/1
    Path.expand/1
    File.lstat/1
    File.read/1

Parsing arguments

    argv = System.argv()
    OptionParser.parse(argv, [strict: [switch: :boolean], aliases: [s: :switch]])
    exit({:shutdown, status_code}) # for shutting down with an error

For printing colors (from docs)

    iex> IO.ANSI.format(["Hello, ", :red, :bright, "world!"], true)

> imho Elixir is generally not the right tool for the job for command-line user interfaces

why? what factors lead you to this conclusion?

there's so mamy examples of low grade opinion sharing in the comments. going just a little further to say why you think something, what factoes are good or bad, can provide a real starting point where folks can learn & engage usefully, rather than just subject each other to utterly shallow opinion. another example from elsewhere:

> Elixir is ill-suited to command line apps out of the box.

we should have actual substance to our conversations; again, why?

(my own guess is that beam vm has to get started & is mind of heavyweight... i dunno if that cost even necessarily has to be paid for each program launch or no, maybe there's some trickery to quickly start new cli processes in existing vms. just guessing, not my scene. but what would be negative factors? no one says.)

I completely agree with your points about shallow comments. In a similar vein, while we’re asking for a bit more effort, I’d like to ask you to re-read what you write before posting. There are a half dozen typos and no capitalization. It helps ESL users, gives your subconscious another chance to refine your comment, and makes it easier for each reader to focus on your ideas without distraction.

I have no horses in this race, but a good language for a CLI is a language that generates small binaries that use little memory and start up very fast.

I can think of three languages that I would use based on that: Go, Rust and if I was feeling adventurous or wanted to be able to execute scripts, Common Lisp (it's surprisingly fast, in the same league as Rust, for small programs).

Does Elixir compare positively to those in these categories?

EDIT: some people on this thread say it takes 200ms just to start an Elixir program. That's three times slower than Java, which is generally not considered a good language for CLIs.

One of the great things about Elixir is that it encourages you to think of your application as the code that executed the purpose of your system and everything else as an interface to it.

So a web interface, an API interface, a CLI interface, etc are all treated the same way since the code doing the work isn’t tightly integrated to any of them.

From that perspective, Elixir can be great for CLI.

Either I don't understand what you are saying, or this is not unique to Elixir at all? Or both lol

With Elixir/Erlang the various BEAM nodes can connect and call each other so the code internally tends to reflect the same approach.

The equivalent approach in most other languages would be to create a single web API and have everything talk to it via REST, etc.

It’s closer to thinking of everything having an RPC interface by default I suppose.

And not all CLI tools are isolated UNIXy bins you install. It could be an interface to a larger app running on the system like a database.

It's not. I keep factoring my CLI scripts to something that's very MVC. Everytime.

brightball is perhaps alluding that the BEAM VM environment itself is treated more as an operating system within an operating system rather than just another process in an operating system.

The BEAM VM is unique (at least compared to mainstream languages) in that everything is run as a preempted, stackful coroutine. The result is an environment reminiscent of an operating system.

As long as you aren’t severely memory constrained or trying to do tasks that only take a few ms, it’s totally fine. It’s even desirable in a lot of cases. You can do a lot of tasks in about the time it takes python, or faster if it’s a parallelizable problem.

You absolutely can strip beams memory usage if required.

There are a number of applications(Erlang term) that start by default that may not be required, which can be disabled.

I know you can do that, but I’m not sure how much memory it saves in practice.

> I love using Elixir but I also like to think "right tool for the job" and imho Elixir is generally not the right tool for the job for command-line user interfaces

Unless you're writing a CLI utility that natively interacts with BEAM VM services without having to de/serialize JSON via a REST API first

I wonder which one is currently the king (include all arbitrary metrics you can think of)? I guess 1.Go 2.Rust

Bash?

Won't work on windows outside of WSL, at least that has been a reason I've heard for not using Bash for simple stuff.

For complex applications bash (or shellscript in general) is also rather ill-suited as it has a lot of footguns and can be hard to maintain.

You can also use Bash in Cygwin/MSYS environments, like Git for Windows. I've been using Bash for writing cross-platform Git scripts :)

For decades. Bash even runs in DOS.

I have no idea if Bash has library? It's more like for managing host stuff rather than compute wide range of application.

Python is by far the world most popular language, and is used a lot for command-line scripts.

Its awful package management makes using Python for CLI applications more painful than it has a right to be. Despite this egregious shortcoming, it's popular for scripts only because it comes with a quite extensive standard library.

These days I'd rather suffer through the verbosity of Go or strict memory semantics of Rust (which are no concern in most CLI applications) than write more than a dozen lines of Python. Personally, while I think the compiled world has settled onto a few very good languages, the scripting ecosystem still to this day leaves a lot to be desired.

As of last year, Meta recommends internally that CLI tools be implemented in Rust:

https://engineering.fb.com/2022/07/27/developer-tools/progra...

Reply on news.ycombinator.com