I'm spending all my free time with Phoenix. I come from a Rails, Laravel, Django and a bit of .NET Core background. So far I am extremely impressed. I'm surprised it has not been adopted by that many folks in production.
You'll have a phase of disorientation where you'll be wishing you had x feature in Django and the reverse where you'll wish you had y feature in Phoenix/Elixir.
The thing I really miss from Django is the admin scaffolding. Phoenix just isn't there. In practice, you could continue to use Django as a front-end.
I moved away from Django when the recurring question of "this is neat, but how do I make it keep going no matter what?"
The problem is that I was/still am a rookie of a programmer. I could not wrap my head around async in Python. I just wasn't getting it. I had a nagging sense that it was going to fail in the middle of the night and there was nothing I could do about it.
So, enter Elixir, which actually has a syntax that is kind of close to Python. It made immediate sense. If you want to do something that can cause the program to fail, do it in a process and send a message back with the result. If the program spawning the process fails, the supervisor will restart it!
Sorry - back to your question - and this will probably disatisfy you, but the answer is that everything was neat. It was just simple CRUD stuff, but doing it in Python didn't feel "robust" enough.
I'm fully aware that my reasons are superficial, but the way Elixir works has made me way more confident as a programmer.
This isn't your fault. Python doesn't get the asynchronous stuff particularly right, nor does it make it as straightforward as it should. I've moved to Elixir and one of my employers has moved to Go as a direct result of Python's concurrency model (and the hilariously needless and recondite primitives attached). Your reasons aren't particularly superficial; I'd pick the Actor model over systemd and uWSGI for anything critical!
As a Ruby/Rails guy, here's my experience(summary):
I came to Ruby from Java, I wrote Ruby code like Java code at the start, it runs, but it is bad, once I really learned to write Ruby code it became a billion times better.
Same thing happened to Elixir, my first few lines of Elixir were very similar to Ruby, similar syntax makes this possible, but I missed the real gains from Elixir this way.
There are quite a few functional programming concepts to learn, but once I finally clicked what pattern matching was all about Elixir programming went from enjoyable to amazing, if you can work functional programming concepts your way you can do a lot.
That said, don't worry about it unless it is critical for your job, do your code, once all the concepts click in it gets way better, spend some time with pure Elixir, it pays off just as much as it pays to a Rails developer to understand what Ruby is all about.
Phoenix works within existing Elixir constructs like macros and modules, so it keeps a lot of the nice interfaces of Rails without the magic, how things work is pretty straightforward.
It is worth stating that the way Erlang/Elixir manage processes is completely different than most other languages and that has to be grokked at some point. Thankfully the framework abstracts a lot of that.
The Elixir and Phoenix docs are also pretty good. They're not Django-level (what is), but they're good.
Phoenix 1.3.0 really helps you understand that you are just making an Elixir app with some additional features. I don't think there is as much "magic" as Rails.
There's almost no magic in Phoenix, it's modular from the start and is really just a collection of libraries held together by some mix tasks to help you structure stuff.
Phoenix is much more straightforward and explicit but macros are used a lot in both Phoenix and the Elixir standard library. I think most of the macros are fine but opinions vary widely on that.
I tend to think of "magic" as meaning fragile, indirect coupling; for example "magic numbers" at the start of files, which are only meaningful if the consuming application has a corresponding pattern in its database.
Or sets of things which only work if given in a particular order. Or unrelated functionalities which interfere with each other due to implementation details. And so on.
In other words, leaky abstractions where thinking in terms of the concept has so many edge cases that it's easier to think in terms of the implementation instead. Or conventions which can only be used via memorisation, trial and error, stack overflow and reading the source (often this is due to shoehorning things into language models which aren't amenable; e.g. all of the things aspect oriented programming tries to do)
Go into it with the attitude of 'deferal of gratitude'. In other words it might look painful for a while but when various things click you get your holy s moments and you'll never go back. I've worked in a lot of java, php, python, c# etc frameworks and there are very specific reasons this is near always better long term. A lot of it comes back to elixir simply solving the correct problems. Learn elixir using the elixir lang site guides and then jump into phoenix using their official guides. Eventually you'll experience the upsides and versatility
By correct you mean that Elixir solves problems differently than java, php, python, etc. and you found this more appealing over time, which may or may not be the case for someone else.
Or are you making a stronger claim that language X is better than Y, at least when it comes to web dev?
No I don't mean it in a way that is subjective. It does depend on person to person because of factors in their knowledge and situation, history etc etc, but elixir lives in a world that the others don't. Making a language that plays on the erlang vm and has complete access to OTP was a good solve. Other languages haven't been able to replicate OTP despite attempts (and they likely won't). It's not better for everything and the language isn't somehow obviuosly better, it just solved the right problem if you want easy web scale that doesn't do things like drop connections when you release or have a difficult concurrency model. Functional programming is a grind at first but it's a good fit for this world and elixir is more accessable day to day than erlang. I have way more experience with PHP but there are limitations there that can't be solved. So I would say that both your points apply, I am making the claim that X is better than Y because of core value reasons, but that doesn't mean that economically other languages don't make sense for web programming. I still make new projects in PHP and Python because of existing infra at work and others that can't/won't learn elixir and co. We'll just be making something slightly inferior and not be building tools for a more pleasant future, but it still makes money for the biz and isn't terrible
I've used both and honestly it probably wouldn't change much. Unless you're building an application that deals with tons of persistent connections and websockets there aren't really that many advantages. The Python ecosystem is also much, much bigger than the Erlang and Elixir ecosystem and it has far more mature libraries.
If you really want to learn a functional programming language I'd strongly suggest looking at Haskell, Ocaml or F#. Functional programming only really starts to shine with a good static type system and dialyzer simply doesn't cut it.
The difference between Elixir/Erlang and a statically typed functional language is that it's built for distribution.
In a distributed system where machines register on a cluster and messages are passed constantly across isolated heaps, processes and entire machines transparently all of the assumed protections of a static type system break down. You can't enforce static types across a cluster anymore than you can across a JSON requests to somebody else's API without a lot of extra overhead.
Static types are essentially contracts and in order to enforce a contract like that on a cluster of different machines that would mean you'd have to exchange contracts everytime a new machine joined the cluster...for all modules and functions...with every machine on the cluster. And then you have to determine how to handle contract violations.
Clustered message passing operates more like request routing in that regard. Send to this machine, to this module, to a function named this, with this arity, that matches this pattern.
The Elixir gradual typing approach balances this reality extremely well in my opinion. You get type checking if you want it and can specify it in more detail...but it won't promise something that it can't guarantee across the cluster, across deploys and across changes.
I beg to differ. FP with Clojure is pure joy. Spec, which is due out soon with 1.9, is also the next best thing to static typing. Some would even say it's better.
>> I'm surprised it has not been adopted by that many folks in production.
I'm surprised that it's used in production at all. It's based on a new language that is years behind all the others in terms of available third-party libraries and modules.
Does the language lack some maturity? Sure. But you don't have to use pure elixir for everything. You can leverage most Erlang packages. Phoenix is hosted on Cowboy[0] which is a mature, battle tested web server written in Erlang.
