If you want to know what Phoenix 1.2 is all about, check my ElixirConfEU keynote which demos Phoenix Presence:
José Valim and I were also on the changelog podcast talking about what's new:
Do you have more information about the "Phoenix with gaming" book that's in the works? I'd like to find out more about it and when it would be available.
https://haslab.wordpress.com/2011/07/08/version-vectors-are-... - are you sure what you described is a version clock, and not a version vector? I'll readily admit to not having a thorough enough grasp of both to feel confident in making that call.
So it is probably the source of the problem more than Elixir vs Erlang.
Phoenix 1.2 looks ready for prime-time! I just finished setting up a continuous integration/deployment pipeline with edeliver and CircleCI and couldn't be happier with how everything is fitting together.
Very excited for the bright future of Phoenix!
What are the biggest pros/cons you've encountered so far? What do you miss from Django? What do you wish Django could copy from Phoenix?
Elixir as a language is very nice. This is my first taste of "functional" programming and I really like it. Shifting my mindset from object-oriented has been difficult, but I find the code I write much more straight-forward so far for the types of apps I will be building.
What do I miss? Maturity. Django dotted its Is and crossed its Ts a long time ago. I wouldn't say Phoenix is buggy at all—I think it is production ready—but the recent work Django has been doing with things like Postgres libraries are several steps ahead of where Phoenix is at today. Also, Django documentation is bar-none.
There is nothing about Phoenix that jumps out at me and says "Django would be so much better if it had this!" Maybe Presence will be one of those things, but I have not had a chance to play with it yet. I am excited about how Elixir (on top of Erlang OTP) scales horizontally with virtually no effort, which is something that Python cannot replicate as easily without a lot of thought and some sort of bolted on message db—and in the end, slower. The robust concurrency story (and what that could mean long-term) is exciting to me.
What do you miss from Django's Postgres libraries in Phoenix/Ecto?
For the Django Admin there's ex_admin which I haven't used yet but it appears to take a bit more work than the Django Admin does.
I haven't felt like virtualenv + pip was too bad for deps and deployment but exrm is already comparable/easier with an even better `mix release` planned for this summer/fall. No uwsgi or gunicorn to configure and even nginx can be skipped.
For the last part of your question: the biggest thing missing from Django was a good way to do websockets. Django has channels now but I doubt they'll work like Phoenix/OTP/Erlang (especially in the concurrency and fault tolerance categories).
I'm working on a Phoenix app, getting close to being ready for a beta deployment, and I was just looking for best practices as far as putting it in production.
I think Django is showing its age, but not in a bad way, in a mature way. I truly admire the way Django and its core team have matured. They have been role-models for me for years and still are.
Django's momentum is only getting greater. Mozilla has been dumping money into it recently, and important projects like Django REST Framework are getting funded as well. Django is level-headed and forward-facing. I can't emphasize the importance of those two characteristics enough. Look no further than projects like Andrew Godwin's django-channels for evidence. I think starting a new project in Django absolutely sets you up for success.
That being said, Phoenix is terrific so far. It's fast, fun, and the Erlang/OTP concurrency story is really exciting! I'm lucky to be at a place where I can take a few months to really explore it; and I'm loving it! I will choose Phoenix for my future projects, but not because Django is losing any steam.
Of course, no one can tell you whether it's good for your particular business case- but Erlang is battle-tested, and Elixir/Phoenix have made it both easy to reason about and perfect for being productive. If one had the option of choosing a framework right now, I don't know of many reasons to not use Phoenix.
Personally my biggest reservation would be the difficulty of debugging production issues that span two languages - Elixir and Erlang – when I have no familiarity with the underlying language (and when that language is not widely used, and therefore likely to be sparse on StackOverflow).
That's not to say I wouldn't use Phoenix; it's just that that's the biggest drawback I can think of (aside from general ecosystem maturity, which it sounds like is on an impressive clip).
Nor have I heard of anyone else having that issue. It's one of the reasons I enjoy it so much- I get all the performance with none of the complexity.
Then you'll dig deeper into und the actual syntax (a week for rubyists before it clicks?). Dont give up, its awesome.
Then you'll be productive right away. And then you'll discover what OTP actually means in practice and be blown away. (Point of no Return)
And then you fully "get" what channels, distributed systems, umbrella-refactorings and all the latest talks are about.
Phoenix as a whole is so advanced compared with everything else we have currently its not even funny.
I highly recommend the official book, it itself is one of the best books in web dev i've ever read.
I used Erlang on my last project, and it was an awesome fit for what we were doing. It's a really great system.
That said... "don't drink too much kool-aid" - Rails is fine for lots of things, and continues to be fine. Not everyone needs a fault-tolerant, distributed system, or web sockets or some of the other stuff where Erlang is a win.
This has been the whole appeal behind Phoenix: it truly is as productive as Rails/Django but much more performant. Better throughput, faster boot times, faster tests, etc. Fault-tolerance, channels and presence are the cherry on top.
I have seen Chris keynote about the presence implementation and they seem to have used really advanced techniques that I cannot not quite follow. Still, this week we are going to deploy presence into production and all we really care is that it just works (and without Redis or any other dependency).
I'd be a little bit skeptical of both things: Rails has a huge, mature ecosystem, and Erlang is often faster than Ruby, but is not a "fast" language.
Where Erlang really shines is that it's running in a single Unix process, yet can handle multiple things going on at once thanks to its scheduler (and not have ugly code, because it's the scheduler doing the work, not the programmer writing spaghetti). This means that generally, it's going to handle more connections better and degrade more gracefully. This is a huge win for web sockets where you have a connection sitting open and not tying up a huge Rails process. Although even there, I guess the Rails guys are working on some new stuff that should help alleviate that problem.
Erlang is cool stuff, and well worth a look. I certainly enjoy working with it. But be wary of throwing out Rails because "new! shiny!"
The Erlang benefits you have mentioned above also fully apply to regular web requests and applications. One of Ruby biggest flaws (and consequently Rails') is poor support for concurrency. And Phoenix performs well on all aspects Jason mentioned because running tests, serving data, etc is all done concurrently.
I was also skeptical at first. I've heard talks and benchmarks reporting Phoenix is from 10x to 20x faster than Rails (like this one: https://gist.github.com/omnibs/e5e72b31e6bd25caf39a). After porting our authentication service to Phoenix (our first), we saw similar gains with less CPU and memory usage (as well as better response time averages and 99 percentiles). Our deployment infrastructure for this service is now one fourth of what it was originally.
Other than that, Rails definitely has a huge ecosystem and that should be taken into account by those planning to move to Phoenix. Honestly, it has not impacted us in any significant way but YMMV.
To be able to get that without sacrificing productivity is huge.
I'm fine sitting on the sidelines for now and letting the ecosystem mature, but will definitely be jumping in at some point.
Another thanks to the teams behind all these amazing releases, and particularly (for this news) Phoenix.Presence and Phoenix.PubSub, for the wide range of new exciting applications they'll have.
At my organization, I created our first internal service which uses Elixir and Phoenix. I've had a number of both junior and senior devs come up to me really excited about building on Phoenix and Elixir. It's rock-solid stable, fast and fun to use. Props to José, Chris and the rest of the team for their continued hard work.
Nice! I found the way Phoenix deals with iteration to be quite refreshing, glad to see lib is now a part of this too.
Edit: I was wrong! My comments will apply to Ecto 2.1. Life is confusing living on the edge sometimes
TL;DR - not yet, soon.
I really appreciate the work of you all!
> A productive web framework [using node] that does not compromise speed and maintainability.
> A productive web framework [using elixir] that does not compromise speed and maintainability.
Apologies for incorrect info, I saw the "npm install" content in the instructions and assumed it meant phoenix used node.
Also note: Phoenix is not so much a singular framework, it's more of a collection of libraries (Plug, Ecto, etc.)... it's just that Elixir makes cohesive communication between independent libraries so dead simple it "feels" like a Rails-like monolith.
But once you actually look at the structure of the project, there's really not a whole lot that's hidden "behind the scenes" like in Rails. You can just add remove any of these components as you like.
Honestly give it a try. This is the first backend environment I've tried that feels "right" (and man I've been searching); everyone else I know who's tried it agrees. It's just a pleasure to work with.
So far every surprise has been pleasant!
There is even a generator for json API iirc.