It’s annoying that Elixir or Erlang languages are only good for writing web applications. You can’t write CLI tools as starting the BEAM doesn’t make sense for it. Unless I’m mistaken.
With Go for example, you can write the same highly concurrent web apps but also write CLIs thus use one language for everything + Go LSP is more mature.
I never tried out Elixir/Gleam though, perhaps its functional & expressive features are really that good.
You can write command line applications in Erlang based languages, it’ll just be a bit slower to start and harder to distribute than a language that complies to binary, similar to tools written in Ruby, etc.
I wouldn’t pick Erlang for a general purpose CLI but I might for a tool for a larger Erlang project. This is a common approach: iex, mix, rebar3, rabbitmq CLI, etc.
Go does a great job of making easy to distribute binaries, but sadly it is lacking many of the concurrency and durability features of Erlang. Ideally there would be a language with both! I’m hoping Lumen, the LLVM compiler for Erlang, will deliver here in future.
(On a second read of your comment, I can’t tell if you have experience in the Erlang world. If you do, my apologies if you already know what I’ve written below. I’m learning about a new topic and I’m some what excited.)
I have been messing around with Elixir for a few weeks and I love the pattern matching, function overloading, and expression oriented syntax. It’s a very fun, expressive language. I would recommend checking it out!
I believe that there are some frameworks to make TUIs, but it is probably not suitable for short lived command line tools. Specifically, I understand that it is not very fast when it comes to text processing.
One important thing to note about the erlang virtual machine (BEAM) is that it is built for low and consistent latency. You could run an infinite, cpu bound loop in one process and the rest of the processes would keep chugging along. This means that it is not necessarily built for high throughput. (The runtime interrupts each process after a certain number of “reductions”.)
So while Go might be able to build highly concurrent systems I think you would have to put a lot of work into making the latency consistent and to build fault tolerance into your application. That said, throughput is more important than responsiveness for some applications so it is a reasonable trade-off to make.
Use escript. It doesn’t start OTP which is where the startup time is spent. Starting escript is pretty much instantaneous. If you need distribution access you can still call net_kernel:start/2 manually and send messages to other instances.
As a follow up to my previous reply (https://lobste.rs/s/q66slp/v0_10_gleam_statically_typed_language_for#c_upesnz) I would like to say that I’ve been thinking about how Go could be a complication target for Gleam. I keep hitting into problems of not being able to replicate some Erlang features using the Go concurrency primitives (namely monitors, process isolation, and links). If you or anyone has an idea of how we could tackle this I’d love to explore this area!
Language server protocol. It’s a common API for IDE engines so that one program can be made per language and then shared with all editors, rather than each editor implement their own language tooling.
It’s annoying that Elixir or Erlang languages are only good for writing web applications. You can’t write CLI tools as starting the BEAM doesn’t make sense for it. Unless I’m mistaken.
With Go for example, you can write the same highly concurrent web apps but also write CLIs thus use one language for everything + Go LSP is more mature.
I never tried out Elixir/Gleam though, perhaps its functional & expressive features are really that good.
You can write command line applications in Erlang based languages, it’ll just be a bit slower to start and harder to distribute than a language that complies to binary, similar to tools written in Ruby, etc.
I wouldn’t pick Erlang for a general purpose CLI but I might for a tool for a larger Erlang project. This is a common approach: iex, mix, rebar3, rabbitmq CLI, etc.
Go does a great job of making easy to distribute binaries, but sadly it is lacking many of the concurrency and durability features of Erlang. Ideally there would be a language with both! I’m hoping Lumen, the LLVM compiler for Erlang, will deliver here in future.
(On a second read of your comment, I can’t tell if you have experience in the Erlang world. If you do, my apologies if you already know what I’ve written below. I’m learning about a new topic and I’m some what excited.)
I have been messing around with Elixir for a few weeks and I love the pattern matching, function overloading, and expression oriented syntax. It’s a very fun, expressive language. I would recommend checking it out!
I believe that there are some frameworks to make TUIs, but it is probably not suitable for short lived command line tools. Specifically, I understand that it is not very fast when it comes to text processing.
One important thing to note about the erlang virtual machine (BEAM) is that it is built for low and consistent latency. You could run an infinite, cpu bound loop in one process and the rest of the processes would keep chugging along. This means that it is not necessarily built for high throughput. (The runtime interrupts each process after a certain number of “reductions”.)
So while Go might be able to build highly concurrent systems I think you would have to put a lot of work into making the latency consistent and to build fault tolerance into your application. That said, throughput is more important than responsiveness for some applications so it is a reasonable trade-off to make.
Use escript. It doesn’t start OTP which is where the startup time is spent. Starting escript is pretty much instantaneous. If you need distribution access you can still call net_kernel:start/2 manually and send messages to other instances.
http://erlang.org/doc/man/escript.html
As a follow up to my previous reply (https://lobste.rs/s/q66slp/v0_10_gleam_statically_typed_language_for#c_upesnz) I would like to say that I’ve been thinking about how Go could be a complication target for Gleam. I keep hitting into problems of not being able to replicate some Erlang features using the Go concurrency primitives (namely monitors, process isolation, and links). If you or anyone has an idea of how we could tackle this I’d love to explore this area!
LSP?
Language server protocol. It’s a common API for IDE engines so that one program can be made per language and then shared with all editors, rather than each editor implement their own language tooling.