[Comment removed by author]
Very excited to see Phoenix coming along. I want elixir to succeed so badly.
What features does Phoenix provide over other popular web frameworks such as Rails or Django?
1) Soft-realtime PubSub layer on both client & server, w/ browser & iOS clients (Android soon)
From an outside perspective, the biggest thing we provide over Rails/Django is a soft-realtime pubsub system out of the box, which is our Channel layer. We ship a phoenix.js client that makes it really easy to push realtime messages out, and we fallback to longpolling if websockets are not supported. We also have an iOS client and will include an Android client with 1.0. Phoenix aims to target the entire web space, not just the browser. Underlying all this is a PubSub layer that supports different adapters. For example, if you’re running clustered nodes, you can just use built-in std lib features, but we also provide a Reds PubSub adapter so support pushing updates across non-distributed deployments like Heroku.
2) Concurrency Model
On top of that, our concurrency model lets you write code the way you wish you could write code in Rails. For example, we don’t have to worry about blocking in controllers, where Rails any tiny blocking requires offloading to a background worker and polling for changes. What should be a simple microservice/remote API call turns into workers, client polling code, and a bunch of cruft. In Phoenix, you can just do your work and not worry about a blip in throughput.
3) Precompiled Templates
Additionally, our template layer is 100% precompiled, compared to Rails (not sure about Django). So we do the work at compile-time to turn your templates into a function call that just performs string concat at runtime. No disk read/caching required.
It’s worth mentioning too that the features that Erlang & Elixir provide out of the box are applicable when comparing Phoenix to others. For example, through OTP (our standard lib for building distributed, fault tolerant systems), we can build out applications as supervision trees that restart on failure, failover to other nodes, and as WhatsApp has proven, handle millions of concurrent connections. The code you write to run on one machine is nearly the same for the code to run on a cluster of 50 machines.
To be fair, we are still young, and head-to-head comparison leaves us lacking in some areas. Things like community packages, comprehensive documentation, and learning resources are still coming together, so Phoenix will require getting your hands dirty in some areas and has less off-the-shelf access to packages. That said, these area should continue to improve as we march towards a 1.0 release later this year. Hope that helps!
Thanks for the lengthy reply – I don’t believe I’m worth it – honestly.
After I wrote the comment, I took a look at the Phoenix documentation. I only have one more technical question: Considering, Phoenix is being built – I believe – to explore the possibilities of building a web framework on top of erlang/OTP (and therefore concurrency is a topic of central focus), what advantages does say Phoenix/Elixir have over Golang and the string of concurrent web frameworks being developed for it (Martini, Goji, Gin,etc). I only skimmed through the router documentation, and it looks like you have a separation section for Channel routes, but is it possible to use a concurrent router and see the performance gains you see in Golang with Phoenix?
Also, I wanted to say: You guys are doing a great job! Very impressed with everything that has been done already. I’d say now is the best time to be a contributor to a project like this – only when it’s young and just getting started does a person have the opportunity to contributing to something major.
I think you’d want to look at the differences in general between Go and Erlang to get an idea of where their relative strengths lie. There have been some good HN threads on that subject. Erlang’s error handling and fault tolerance are probably strong spots compared to Go. Lately I’ve been working with Erlang, to build a semi-embedded system. Go looked appealing too, but we felt more comfortable with the idea of Erlang in terms of robustness, stability, and the ability to run without intervention for long periods of time. For a regular web site where you can easily intervene when there are problems, these advantages are probably not quite as important.
Maybe. I’d also compare them age wise. Erlang was developed in the mid-80s, whereas Go has only been around since 2009 – though both feature most exclusively message-passing actor model based concurrency.
I’m actually reading a book on Erlang right now – but only as a sort of intro to actor-model based concurrency before continuing a project I started in Golang a few weeks ago (I want to understand the theory more). So far from what I’ve learned about Erlang, I find the differences between Erlang and Haskell a lot more interesting.
though both feature most exclusively message-passing actor model based concurrency.
Sure, on the surface there’s that, but there are a lot of differences under the hood. For instance, Erlang really does not share memory: GC and pretty much everything in each process is separate. Erlang’s supervision tree is also an extremely important part of what makes Erlang Erlang.
No doubt. Erlang is more interesting then Golang in certain respects. OTP and the Erlang VM have really amazing proprieties in regards to keeping a distributed system up and running for as long as possible. I’m still learning all this – but even beyond message passing actors – Erlang is amazing and has a lot more to teach us.
Though, when it comes to the highly competitive web application market with big brand web frameworks competing for our attention – I feel like Golang has the edge – maybe simply because of Google, or it’s heavy corporate sponsorship, or maybe since it comes from the age of web applications – I don’t know.
I thought blocking was fine in Rails controllers because the concurrency model is non-existent / is just to run a ton of instances of your app. Am I wrong?
Blocking and spinning up instances is not cheap. Best case scenario your Rails app will consume 150mb per instance. Even with a threading server like puma/unicorn, you aren’t going to be able to easily spin up hundreds of instances of your app to achieve concurrency. Keep in mind each of these instances will consume a database connection from the connection pool. I’ve used Ruby & Rails professionally for five years, and the Erlang concurrency model and semantics is just mind blowing compared to what I’d been accustomed to.
Does anyone have any experience with the market for Elixir? I’d love to read your experiences.
It’s interesting how, sometimes it seems that new things just kind of get some momentum and roll. I don’t know quite how to describe it, but compare and contrast with Erlang, where the existing web frameworks are just not all there (and I say this as a committer to Chicago Boss), and seem to have little to no momentum.