I think it is very accurate and should be uncontroversial to say that Elixir/Erlang/OTP are very angled towards building services. I'd say service rather than server because I don't think it is necessarily about client/server as much as doing a long-running job. Which very often is a server but I've done bots, workers and whatnots that I wouldn't necessarily think of as servers.

I think the language and ecosystem are fairly general-purpose but there are definitely a lot more general ecosystems. I think some of the big wins both Erlang and Rails have achieved (that Elixir build off of) have been about constraining the problem to be "a service" or "a web app with a database".

So you are spot on there.

One of the things I've found Elixir to be surprisingly nice for is as a replacement to my Python and Bash scripting. Shelling out is occasionally awkward but Mix.install is glorious and Task.async_stream is hilarious.

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 agree and completely sympathize.

[rant]

What irked me many times: people around here idolizing a certain PL they learned as kids and giving it much more credit than it ever deserved.

[/rant]

I completely understand the almost PTSD levels of reactions when people say "you actually can do ${obviously_difficult_thing} in ${obviusly_niche_language}!". I have the same reactions towards these statements myself.

I mean sure, if you're a good enough physicist you probably can make a lounge chair out of toothpicks, toilet paper tubes, rubberbands and glue. Doesn't mean that it's sustainable or viable to do so for everyone else. It's just your hobby; go wild and have fun! Don't pretend that's how lounge chairs should be mass-produced, however.

Same goes for PLs.

A lot of PLs should have remained niche curiosities and research ideas -- and nothing beyond that. Sadly we both know how people are. They easily fall in love and lose all scientific objectivity.

So yeah, I quite get your frustration.

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.

I like it for scripting because with the Flow module, concurrent code looks mostly like non concurrent code. You can also pull in dependencies right in the file.

I did a small experiment with a few different languages and Elixir had the fewest changes going from single threaded to parallel.

Clojure was the lowest loc in general.

It having strengths and weaknesses doesn't make it not general purpose language.

In your mind, what distinguishes a language as "general" or "specific" purpose?

I'd argue the community and focus of the language.

Or, to your point, the historic design considerations that led to the creation of the language in the first place. In the case of BEAM, it was very specific.

What I mean is that, you can write CLIs in Elixir. I have. You can write games in Elixir (others have, I haven't). They come with pros & cons. The Elixir community advances on many of those fronts regularly. I could write a web application in C, but I wouldn't.

I would honestly have a much easier time writing a web app in C than a game in Elixir.

You are probably right

If your application doesn't need GenServer you shouldn't use GenServer.

Elixir is definitely not a language to write games in, but it's totally viable to write stuff that doesn't fit into the OTP model.

What are some examples of large scale production systems written in Elixir that do not use OTP?

I don't know and it's tangential to the question of whether "elixir is a general purpose language".

Might be important for you, but it's irrelevant for my comment.

My main point is that a language’s historic design considerations, community and ecosystem play a huge part in determining its applicability to a particular domain. Years of personal anecdote, coupled with the history of the project, and what people are building with it in practice (rather than what could be built in theory) drive my conclusion that it is not a general purpose language. That doesn’t mean it’s not a good language for what it was historically intended for.

But in the process you are redefining general purpose language to general applicable language and making everybody confused. Why not adhere to the general convention and accept that Elixir is totally a general purpose language but has limited applicability depending on the domain.

I disagree, it’s wonderful for writing compilers in as well https://github.com/elixir-dbvisor/sql I would go so far as to say superior to a lot of other languages that do not have advanced pattern matching.

So is any ML or Lisp descendent.

> I disagree with calling Elixir a general purpose programming language.

I was going to comment this seperately, I'm glad someone pointed this out. +1

Came here to say this. What makes a great general purpose language is not only in the programming part but also in transportability. I think Go takes the cake here. If only Elixir apps could be compiled and transported as a binary to similar systems and it works, then it would make it a great general purpose language. Until then, it's really only a good client/server language as it was intended to be.