Wow this news front-paged fast! I just tagged the commit, grabbed a quick lunch, and I haven't finished drafting the official release announcement yet :)
Hey Chris! Just watched the video from elixir conf EU
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.
I believe they are technically version vectors, which I've mentioned in other talks, but I haven't been sure if the distinction is helpful and I haven't been confident enough yet to explain the nuances. Will check out the link
Ok - the reason I ask is because when I needed to figure some of that stuff out, I had more or less the same reaction you did in your talk. I'm still not 100% of everything :-)
Chris, been a huge fan of Elixir and Phoenix. Do you have any scope on the performance of Elixir versus standard erlang? I am gathering the opinion that erlangers believe Elixir to be slower in general? E.g. the performance of poison versus jiffy
I'm 10-years Python/Django and making the leap to Phoenix. I can't begin to describe how thrilled I am with the intelligence and warmth of this community—something I always treasured at Django and was afraid of losing.
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.
I'm still learning, but I've already noticed some incredible response times. Phoenix is very fast. I wish I had actual numbers to give you that compare to Django but I'm just not that far along yet.
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.
Another Django -> Phoenix dev here. Currently I miss Django's model field types (UrlField, EmailField, etc) and will probably write them if no one else does soon. I sometimes miss South style migrations when I'm prototyping but doubt there's a good reason to implement them in Phoenix. For building JSON APIs JA Serializer is a quite capable alternative to DRF-JA.
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).
Is it common to skip nginx or insert-your-reverse-proxy-of-choice-here?
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.
From what I've read (I'm not an expert either) nginx is completely optional. Cowboy (used by Phoenix) supports https termination and I understand that it's the router for Heroku so it sees plenty of traffic.
+1 to rattray's questions. Some more questions: do you think Django is showing its age? Should new web projects be started in new frameworks like Phoenix, or is Django still good to go?
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.
It's been awhile since I've used Django, but I work with those who use it frequently. Django certainly shouldn't be put out to pasture- but you'd be surprised just how robust and production-ready Phoenix is.
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.
> 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).
EDIT: Oh, and Elixir doesn't have support for static type analysis (though it does have typespecs[0], and there is Erlang's dialyzer[2]...). Python has mypy[1], and JavaScript has TypeScript/Flow.
In the year or so I've been working with Elixir, I've not had to learn a lick of Erlang besides a couple of function calls I can get at directly from Elixir.
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.
Same here. There's only one minor thing that bugs me a bit - Phoenix seems laid out more similar to RoR than to Django, so took me a bit of getting used to. This is not a criticism by any means. Overall, I'm really thrilled with Phoenix (and Elixir).
Long-time rails guy here, really looking forward to playing around with Phoenix soon. I keep hearing really positive things, just haven't had the time dive in. I tried diving into react for a bit, but I found that it was really hard to retain unless I was working with it every day. Lots of people are telling me that the switch from Rails to Phoenix will be a lot easier though (I hope so!)
You'll feel instantly at home in phoenix, since you know more or less what MVC, migrations, ... are about.
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.
> And then you fully "get" what channels, distributed systems, umbrella-refactorings and all the latest talks are about.
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.
I agree with the "don't drink too much kool-aid" but you can also completely develop and deploy Phoenix without worrying about distributed systems, umbrella-refactorings, and so on. At least, I have. :)
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).
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.
Very true, but what I particularly like is the raw speed- having a JSON API with an average response time in microseconds(ie, sub-millisecond) is super cool and goes a long way in transforming a web app into that native-app feel.
To be able to get that without sacrificing productivity is huge.
Not necessarily. If the data is in the database's cache it can be pretty fast. I just tried `explain analyze select email from users where id = 10` on my local postgres, and while the first query took 20ms, the second one only took 0.065ms.
Not every API needs to hit a database for every call. This is especially true for Elixir/Phoenix because if you don't need your data to be persistent over a server failure, you can just store it in an OTP process/ETS table and keep it in memory.
It's also worth pointing out, the newest Ecto(released this week) has features that can do multiple database calls at once, since each one is put into its own connection pool and then assembled at the end. So even rather heavy calls get effectively zeroed-out.
You'll probably find Phoenix a much easier to get started in. The database layer will feel weird and foreign to you, but you'll feel right at home with everything else. And after awhile you'll probably start to appreciate the decisions that went into the database layer, even though they still involve you typing a little more than you do for ActiveRecord.
Yeah, I've been doing Rails for work + side projects for awhile, and I love & appreciate it, but I keep sneaking glances at Elixir/Phoenix. Fast, concurrent-capable tests out of the box seems like a game-changer, for starters. Not to mention all of the cool, new (to me) concepts to nerd out on.
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.
Just bumped my servers to erlang 19, Elixir 1.3 and Phoenix 1.2. The erlang and Elixir communities have done a great job shipping.
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.
I posted this in the Elixir 1.3 thread but also relevant here. If you're looking to understand why you/your company may want to consider migrating from Rails to Phoenix you can check out my RailsConf talk on the subject https://www.youtube.com/watch?v=OxhTQdcieQE
They are supported if you are on Elixir 1.3 since we ship with Ecto 2.0 out of the box, but we are waiting to make them the default with the Phoenix generators until we make Elixir 1.3 a hard dependency.
Edit: I was wrong! My comments will apply to Ecto 2.1. Life is confusing living on the edge sometimes
Since that question is related to Ecto, I will take it. :) Right now it is not possible to use the new Calendar types in Ecto. The plan is for Ecto v2.1 to come in about a month, when v1.3 is a bit more stable, and it will introduce the `:datetime`, `:time` and `:date` types that will map to Elixir's v1.3 new Calendar types.
Sounds good! I am actually waiting for this exact feature before starting my next project, since I have to deal with a lot of time range queries (all items from the Last 48h, ...)
The tagline is definitely not about using node :) We include brunch.io, a nodejs asset builder, for our css/js building/bundling. Phoenix is first and foremost and Elixir web and distributed systems framework, which is where we get our productivity, speed, and maintainability.
Phoenix looks great, but seems like it's focus is on serving html to websites (like Rails). Is there something simpler for building REST apis for mobile/single-page apps (like Sinatra)?
I have just started working on a serious Phoenix project after watching from the sidelines for a while. It takes a completely different approach to Rails. First of all there's no magic (everything is completely explicit). It's extremely adaptable to different needs (JSON apis, real-time communication, etc).
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.
I serve an API with it and also some services that use WebSockets. I've actually never used Phoenix to serve HTML, but I'd definitely recommend it for API development.
If you want to know what Phoenix 1.2 is all about, check my ElixirConfEU keynote which demos Phoenix Presence: https://www.youtube.com/watch?v=n338leKvqnA
José Valim and I were also on the changelog podcast talking about what's new: https://changelog.com/208/