[franticgecko3]

>Why Elixir + Erlang are not more popular for high concurrency projects is a mystery to me.

I work at an Erlang shop.

For Erlang to be useful you need to have massive scale, millions of DAU. Yes Elixir might run your website serving thousands of DAU but Erlang and the BEAM was not invented for you. Few companies have the scale that makes Erlang a reasonable choice.

More pressing these days I believe is that the Erlang ecosystem is all or nothing, the BEAM is like its own little operating system and has extremely (IMHO) complicated setup and configuration with many moving parts: ERTS, epmd, Rebar,... You don't need or shouldn't use container tech and k8s with Erlang because it's already doing that stuff in its own Erlang way - but it's the Erlang way it's extremely unique and unfamiliar to most.

When you have the right use case for Erlang and you see it in action it is truly like black magic, it's been a highlight of my career to work with it.

[HappMacDonald]

When we tried to use Elixir Liveview we found that containerizing it (docker compose) was necessary just because of how demanding the runtime environment is regarding keeping modules up to date and synced, and what that requires of the host operating system.

We'll run prod on one server and dev on 3-4 workstations and nothing will match between any of them without a docker container to give this Elixir app a cleanroom environment to work from.

The project we were trying this on eventually ran out of funding before it got off the ground, and we lost access to our main guy who understood Elixir setup really well, so nowadays the rest of us can't even manage to stand up the service to demo it because of all of the moving parts that get angry about not having their environment set up just right.

I've basically found it the only language more difficult than python to set up an environment for. (Well.. the more I think about it, Gradle and every other mobile development stack I have yet seen is literally Satan's armpit..)

With python (though I rarely code in that either) I can stand up almost anything on almost any machine with miniconda and venv and not have to drag Docker into things.

Node/NPM is a prima donna and a PITA but IME as long as you whack it with a wrench long enough following up on each of its complaints then you'll eventually get things running.

My experience still revolves around PHP or Perl or C on the backend, Raw Javascript or sometimes Elm on the front end, and those all seem to be a lot easier to maintain over a timescale of decades as servers update and browsers gobble up new and different features.

---

What I can say in favor of Elixir Liveview is that we built a smooth as hell SPA using that. It was incredibly user friendly to work with and aesthetically amazing, but the maintenance right down at the foundation was the biggest challenge.

[prophesi]

What environment issues were you running into? We use mise/asdf to manage which version of erlang/elixir our project is using, and only needed to containerize our database to ease its maintenance.

For the dev experience, I'd also recommend NextLS/Lexical over Elixir LS until the official one is out. It should compile much faster for nontrivial Elixir applications.

https://elixir-lang.org/blog/2024/08/15/welcome-elixir-langu...

[tlavoie]

Would something like Nix (optionally, NixOS) help in getting all the parts documented and working together?

[borromakot]

Elixir has been quite easy to set up, configure and deploy, at least for the last 5-6 years. I can't speak for Erlang though.

[michaelcampbell]

> Elixir has been quite easy to set up, configure and deploy, at least for the last 5-6 years.

One of your sibling commenters noted...

> I've basically found it [Elixir] the only language more difficult than python to set up an environment for.

Quite the difference.

I'm not saying either one of you is wrong; I'm sure you both experienced what you say you did, it's just interesting to see the dichotomy, literally (as of this writing) next to each other.

[evnu]

We found Erlang to be the right choice at small scale. Namely, we used it in iot applications, where the self-healing property of proper supervision trees resulted in a very stable implementation. We also saw the same benefits in the cloud part of our application. No complicated k8s setup, just simple supervisor trees.

[michaelcampbell]

> Few companies have the scale that makes Erlang a reasonable choice.

This is a reality that I wish more people would embrace, for so many things.

[throwawaymaths]

elixir softens a whole ton of the sharp edges around getting started and there are only a handful of "gotchas" coming from other hlls (like all terms being immutable when you pass to a function -- but thats honestly almost a problem with the "mainstream" languages).

[genewitch]

So you'd do:

x = doubler(x)

Instead of treating the function like a "subroutine"? Like:

x = 10

doubler(x)

print x

I'm unsure why, but I use the former. Probably due to most sources saying global variables are bad and if I do it the latter way I get errors, whereas with the former I only get errors unrelated to scope.

I'm not a professional or even amatuer programmer, that's why I ask. My only exposure to Erlang unfortunately is from coding contests like advent of code and Codegolf stack; and those are "clever" and my brain doesn't abide clever. The inverse of "why use many words when few words will do"

In my own programs, if I go back and read the code I can tell what I copy-pasted vs what I understood as I wrote it, if that makes sense. Because clever stuff that solves the problem I've been unable to solve in the time I alloted will be in my code. You see anything pretending to be, or being a lambda in my code, I lifted it.

I would like to learn Erlang and there's been a few book recommendations aside from TFA. This comment also serves as my reminder to get some books.