The best things about Elixir are mix and phoenix. We all can talk about how well under load on multicore machines it behaves but that is the same as we would talk about Erlang. What pushes Elixir beyond Erlang is advanced macro language that allows for things like Ecto, mix with moden Ruby like gem+rake kinda dependency management and really really good solid testing framework.
Elixir/Phoenix is really good. And the ecosystem is also pretty solid.
Pros:
* Functional language
* Multicore support built in
* Mix
* Phoenix
* REPL
* solid ecosystem of most needed tools
Cons are:
* Functional language
* Still niche adoption, not many talented people to pick from.
* If you are deploying via release ( as you should ) mix is going away in production
Can be plus or minus depending on people reading it etc.
Now things like LiveView are just cherry on top. In general Elixir/Phoenix is a full package.
Phoenix is necessary for the success of Elixir absolutely. Because languages at this level of abstraction need a web framework to thrive.
I'm not sure I find Ecto and Phoenix as central to Elixirs value proposition in general. I'm looking a lot at Nerves (IoT) and Membrane (media serving). Having a strong web framework simplifies things and Phoenix is good there. But there are a lot of things to like about Elixir/Erlang/BEAM.
Tbh, I feel comfortable writing Elixir and dealing with OTP. But while I find Plug and Ecto to be very interesting projects, I've not touched Phoenix at all. I just didn't feel the need.
I haven't done a release with Elixir or Phoenix yet and the documentation about it is quite confusing. There are many different ways but I have no idea which one to choose.
I went through this a short while ago for a new side project. You can totally use Mix and you'll be fine to get going with initially but you lose a lot of the benefits of BEAM. A proper BEAM "release" has several key advantages. Most of them are in the Elixir docs [1] but I'll point out the ones I like.
* You don't need to include the source code because you have the pre-compiled code in the release, that includes packages as well. No need to `mix deps.get` on production. They don't even require Erlang / Elixir on the production box because that's also baked directly into the release. As long as your architecture is the same as your build machine, you get a super light weight artifact and a simplified production stack.
* It's very easy to configure the BEAM vm from releases. I think most of this is possible through mix with everything installed on the box but using a release you get it put into the release artifact and there's no fussing around after that.
* It also makes life easier when you start using umbrella applications. You can keep your code together and cut releases of individual applications under the umbrella. That lets you scale your application while keeping it together in a single unit (if that's your thing).
There are other benefits, but ultimately it's the way the erlang/elixir/beam community seem to prefer. For me this was the selling point, as I expect tooling will continue in that direction rather than supporting mix in production.
An OTP/Mix release will produce an executable which bundles your code with the whole BEAM runtime, so for a start, it will mean that won't need to install Elixir on the host machine / server.
OTP based release executables also have an internal versioning system. When people talk about the Erlang/Elixir hot code swapping feature, OTP releases are the basis for it. But it needs a bit of extra work beyond just creating the release binary itself.
Yeah it's super confusing, especially since mix releases are now a thing, but weren't before.
I've heard Chris McCord (the author of Phoenix) say he doesn't use Elixir releases in production in most of his consulting company's client work. He talked about it in some podcast like 6 months ago. I think they just run the same mix command as you would in development but he wasn't 100% clear on that.
But yeah, it's not easy to reason about it, and also if you decide to use releases it's a bummer you lose all of your mix tasks. You can't migrate your database unless you implement a completely different strategy to handle migrations. But then if you ever wanted to do anything else besides migrations that were mix tasks, you'd have to port those over too.
That's not true at all. Mix Tasks are just code. Assuming you stashed them in /lib (or someplace that elixirc reaches) you can call them in a release using eval.
I've seen a bunch answers around having to jump through larger hoops to get to run mix tasks in releases. Are all config options still available to be read in mix tasks that are called that way? What about Mix functions like Mix.env()?
If you Google around the topic of database migrations in Elixir releases you'll find like 5 different ways to do them with no clear "this is the best answer".
Mix doesn't exist in releases. You can get config options like normal, but not `Mix.env/0`. You can compile your current env into a config option though, and use that at runtime.
Not many talented people to choose from applies to any language though. And a functional language weeds out all the people who aren't willing to try something new.
Elixir/Phoenix is really good. And the ecosystem is also pretty solid.
Pros:
* Functional language * Multicore support built in * Mix * Phoenix * REPL * solid ecosystem of most needed tools
Cons are:
* Functional language * Still niche adoption, not many talented people to pick from. * If you are deploying via release ( as you should ) mix is going away in production
Can be plus or minus depending on people reading it etc.
Now things like LiveView are just cherry on top. In general Elixir/Phoenix is a full package.