Not sure when you were using Elixir, but releases are a good option for deployment now. This is supported with the distillery library (https://hexdocs.pm/distillery/home.html).
Last I checked distillery was Linux only (e.g. does not work on BSD), which is a deal breaker for me. But I wouldn't consider using distillery (and thus Elixir/Phoenix) on any platform given the haphazard nature of the support for distillery. There's exactly one person who knows anything about it and he supports it when he doesn't have anything better to do. Sure, in a smaller shop you could dig into distillery and try to fix things up. But when shit hits the fan, do you want to discover the hidden dependencies (e.g. bash vs POSIX sh)? I wouldn't want to bet on a single point of failure like that.
And the big problem for Elixir is that you don't see that level of mess or siloed knowledge with other languages. Say what you will about something like Capistrano, but it's an order of magnitude easier to dig into and support because it's not mashing together a variety of languages (erlang, bash, elixir). Some languages like anything JVM based (that compile down to JARs), Rust, and Go compile down into single artifacts quite easily. Others like Ruby and Python can be moved around with standard system tools easily enough.
If those are your concerns, then the fact we are adding releases to Elixir core in the upcoming version should solve most of them.
The single point of failure is gone. The code is now maintained by the Elixir Core Team and it should garner more general attention from the community. The amount and complexity of scripts have been reduced drastically and they are statically verified to run on `sh` (no bash). As with everything else in Elixir, we do our best to keep the Erlang <-> Elixir interface pretty clean. You should expect the same level of quality and polish as the remaining of the Elixir tooling.
I am not sure about this point though:
> Others like Ruby and Python can be moved around with standard system tools easily enough.
If you are not using releases, and simply Mix, is Elixir any harder to move around then Ruby and Python? From my understanding, using Mix to run Elixir in prod is a similar experience that both Ruby and Python would provide.
If those are your concerns, then the fact we are adding releases to Elixir core in the upcoming version should solve most of them.
I've articulated my experience in my previous reply to you, but I'll pose this response: that it's taken so long for Elixir to come up with a manageable deployment story makes it seem like deployments are an afterthought with Elixir. If things are better now that's great, but as an ops guy by trade I think that deployments are one of the most important user stories out there.
I suspect one of the reasons people are gravitating towards Rust for things it's not particularly well suited for (like web apps with a ton of business logic) is that the Rust team focuses on important user stories like:
These are things that Elixir and Phoenix aren't focused on. For example I still get the occasional email from github about the poor souls trying to use distillery on FreeBSD so I don't buy that things have improved that much.
The Elixir tooling is fantastic, not sure where you pulled that one out from. IDE's are unnecessary cruft to the point that I'd call it a language-design smell if you really felt compelled to use one; VSCode is great. Deployments are trivial if you use Gigalixir (which has a free tier) and will be easier in the general case going forward.
And the big problem for Elixir is that you don't see that level of mess or siloed knowledge with other languages. Say what you will about something like Capistrano, but it's an order of magnitude easier to dig into and support because it's not mashing together a variety of languages (erlang, bash, elixir). Some languages like anything JVM based (that compile down to JARs), Rust, and Go compile down into single artifacts quite easily. Others like Ruby and Python can be moved around with standard system tools easily enough.