[josevalim]

> FWIW the last time I tried to use Elixir with escript was with 1.3.

Interesting, escripts should have worked by then. I assume this was quite some time ago, so you don't have it around anymore, but if you do recall what went wrong I would love to take a look at it. But just to put things in perspective, v1.3 is almost three years old and things have generally evolved since.

> There just aren't any killer features in Elixir that would revisit it.

Well, sometimes the killer feature is having all of that in the same package: immutability, concurrent primitives, scripts, etc.

There are also killer features (although I guess "killer" will depend on the person) that we get from running on the Erlang VM: focus on fault-tolerance and supervisors, concurrency and distribution out-of-the-box, and generally other features coming from processes and the actor model. For example, Phoenix makes an excellent use of all those features to build performant web applications with a focus on real time (Phoenix LiveView being a recent great example). Nerves uses the fault tolerance bits for building embedded software. Etc.

[inferiorhuman]

But just to put things in perspective, v1.3 is almost three years old and things have generally evolved since.

But who wants to sit idly and wait for three years for a language to evolve (and regress)? At what point does saying "deployments have been broken with no fix or root cause in sight, let's just sit tight and hope for the best" sound ridiculous?

Were the alternatives to Elixir mediocre I'd consider revisiting it. Were I to see an interesting opening at an Elixir shop, I'd consider it. Would I ever stake my reputation on suggesting Elixir for a new project in a professional environment? Absolutely, 100% no.

Well, sometimes the killer feature is having all of that in the same package: immutability, concurrent primitives, scripts, etc.

I get all of that with rust and I'm not tied to Linux or a petulant maintainer. vOv

I'd be careful about touting performance versus a compiled language like Rust though. Going from Phoenix to Rocket I saw a pretty dramatic speedup in the time it took to serve requests even on my simplest web app (an image gallery). Phoenix wasn't slow, but Rocket was consistently faster.

Edit: OK async on rust is still a shit show, but hey nothing's perfect, right?

[josevalim]

> But who wants to sit idly and wait for three years for a language to evolve?

That's not what I meant at all.

Look, I am not trying to invalidate your experience. Nor I am implying you should wait 3 years for things to get fixed. Nor I am saying that Elixir is better than Rust.

I just want to point out that, for someone starting with or using Elixir today, their experience may be different because 3 years is a lot for a language and ecosystem where v1.0 was only 5.5 years ago. Deployment involves many concerns and even if some particular scenarios have not evolved accordingly, you can be sure others have. The same applies to Rust and other languages, they are improving all the time.

[inferiorhuman]

I just want to point out that, for someone starting with or using Elixir today, their experience may be different because 3 years is a lot for a language and ecosystem where v1.0 was only 5.5 years ago.

Distillery was (is?) broken less than a year ago. Ending up in a situation where such a key component (deployments) is developed and understood by only one person for such a long period of time speaks very poorly to the oversight and development process of Elixir. Beyond that it creates a distrust that Elixir will continue to work or prioritized appropriately — deployments worked on BSD for some period of time.

The last message I got from Github from BSD user commenting about distillery not working was in February 2019. After that it devolved into "here's how you get distillery working in Docker." That's the kind of low quality engagement I walked away from, and that's the reason I continue to recommend against Elixir or Phoenix for new projects.