[josevalim]

I am sorry to hear that you had bad experiences while deploying Elixir. To avoid having others running into the same bad experiences, I would like to point out to some resources and recent improvements in the area for those interested in deploying Elixir.

There are mostly two ways to deploy Elixir. One is the provisioned approach: you install Erlang/Elixir (or you assume it is installed in the machine), then you fetch your project source code, fetch deps, compile them and run your project (in the same way you would run it locally).

The other approach is via releases. A release is a way to package the Erlang VM, Elixir and all of your application code into something you can dropped into production. The downside is that you need to match the target OS and architecture but there are many documented approaches to do so. Today the main tool for performing releases is Distillery and it has great documentation covering AWS, Docker, etc: https://hexdocs.pm/distillery/home.html

In Elixir v1.9, coming out this July, we are incorporating releases as part of the language. You can read more about it in our documentation for master: https://hexdocs.pm/mix/master/Mix.Tasks.Release.html

If you are using a PaaS such as Heroku, it is likely there is already tooling that will take care of it for you, such as the Heroku Elixir buildpack: https://github.com/HashNuke/heroku-buildpack-elixir. There is also Gigalixir, a PaaS specific to Erlang/Elixir: https://gigalixir.com/

Finally, if you want a more structured resource, there is also the Adopting Elixir book (disclaimer! I am one of the authors): https://pragprog.com/book/tvmelixir/adopting-elixir - One third of the book is about production concerns, covering deployment, performance, metrics, monitoring, etc.

If none of this works, you can always reach out to the community in elixirforum.com. I assure you there are more than 2 developers that know about deployment :) and if you still feel like none of the replies about deployment there have been satisfactory, feel free to add me to the conversation there.

> And you're definitely not going to write CLI tools in Elixir (it straight doesn't work with escript in the first place).

I do not understand this comment as Elixir works with escripts just fine. You can build an escript for your project by simply calling `mix escript.build`. This has been available since v1.0 (https://github.com/elixir-lang/elixir/blob/v1.0.0/lib/mix/li...). You can even install escripts directly from Hex (our package manager) since Elixir v1.4 (2.5 years old).

[inferiorhuman]

FWIW the last time I tried to use Elixir with escript was with 1.3. The parts that make Elixir interesting for web apps aren't necessarily things you'd be leveraging in scripts and so, unfortunately, instead of waiting around for Elixir to do the things I was interested in I've moved on. There just aren't any killer features in Elixir that would revisit it. If I need lightweight concurrency primitives there's go. If I want immutability by default there's rust. If I want to hack up some scripts that leverage my web app there's Ruby and Python.

I'm deploying to BSD, which distillery does not support. Perhaps there are other people who can grok deployments on Elixir, but none of them have seen fit to (or know how to) resolve these issues. I've seen scattered reports of success in the issues, bitwalker's attitude and general willful lack of engagement was enough to get me to move on from Elixir and not look back. By the time I gave up on Elixir, deployments on BSD had been known broken for months.

I'm used to hitting speed bumps by not deploying to Linux, but Elixir was by far the bumpiest road for the least benefit. For comparison the rust community has been extremely responsive to BSD users of all stripes (incl. dfbsd).

[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.