I'm curious which use cases you're reaching for that aren't client server?
Not to suggest that those don't exist or anything, just that there are so many dimensions available there that knowing more about which dimensions you'd most value having reach in might be enlightening. :)
Like: Video games? Desktop apps? Mobile apps? Embedded? Systems-level programming like OS or hardware drivers? Or one of a thousand other directions I can't think of just off the top of my head?
In my case it was a non-resource constrained embedded system (several GB of RAM, gigabytes of storage not unlike a set top box application). The tooling was OK, but in retrospect, the community and language felt too biased towards server-client applications. Every time you search for a question, you inevitably bump into answers that assume you are building a Web app and don’t apply to more general use cases. Or OTP ends up getting in your way because you are trying to do something simple that does not require massively parallel scaleability. For a lot of these situations, I walked away from the language feeling like it would’ve been easier to just do it in Python, JS or some other general purpose language. All of the BEAM languages make heavy trade-offs in the name of concurrency, and in cases where concurrency is not a main concern, the gains just weren’t there compared to mainstream languages.
Thanks for sharing. I would reach for Golang or even Rust if I was you.
I work with Elixir for 9 years now (& love it) and I agree what you describe is not a good fit for it.
Elixir is a general-purpose language in the meaning of Turing-completeness. I never once felt tempted to write a CLI tool with it though.
I wrote a custom bioinformatics pipeline (CLI) in Elixir the other week. Not a terrible experience. Being able to save annotations to a binary and unpickle using term_to_binary was amazing.
If that CLI tool integrates with a bigger ecosystem (like connect to a cluster and reuse data / services) that's already written in Elixir, then that would make it an even bigger no-brainer to use.
Also hi, haven't seen you active in ElixirForum in a long time.
css is Turing complete, XSL-T is Turing complete, so I don't think Turing completeness is a good measure of if something is a general purpose programming language. I would argue for environmental completeness - does the language have the possibility of accessing everything in the operating system it runs in? If so, it is environmentally complete and usable as a general purpose programming language.
Despite something being a general purpose programming language there are some tasks it may be better at than others. Visual Basic is a general purpose programming language but really you would most often use it for a particular subset of purposes. Elixir it seems is not good for writing a CLI.
I was mostly clarifying what most people I've met believe is a "general-purpose language". I agree with your take on telling it like it is for the practical needs of the commercial programmers / users of a language.
And again, as a guy who loves Elixir, it absolutely is not suited for writing CLI tools. Many would say it can be easily done, the community even has a few really good libraries for it as well, but the BEAM VM startup time absolutely kills its utility for tooling for me.
And, as others also said, Erlang / Elixir simply excel at orchestrating a lot of runtime micro-agents, each with their own small responsibility. And they do this better than any other language I've seen. But, for one-offs / scripts / CLI tools, Golang / Rust are very difficult to dethrone. We could also add Zig / D / V and others, I suppose, but I am not familiar with them.
yeah sorry, I've just got some trauma from people claiming that languages can be used for stuff they can't really be used for just because of Turing completeness.
I am a huge Elixir fan and I would basically never reach for it to build a CLI.
The BEAM VM is generally terrible at any computationally heavy task. But what it lacks in performance, it makes up for in stability built-in to Erlang's OTP framework.
It's also "difficult" to integrate with existing C programs such as system drivers due to BEAM's execution model. It's possible to do, but there are a lot of foot guns & you have to be careful.