I'm a django guy. I have no experience with functional programming.
What would a transition to phoenix + elixir look like for me?
What would a transition to phoenix + elixir look like for me?
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.
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.
I'd suggest:
https://pragprog.com/book/phoenix/programming-phoenix
In structure it reminds me a lot of the very first Rails book co-authored by DHH. It's a good way to get into the language/framework.
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.
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)
Or are you making a stronger claim that language X is better than Y, at least when it comes to web dev?
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.
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.