If you were choosing today, would you recommend choosing Elixir over Go for web/back-end development? Would you say Go is more suited for high-performance command-line tools, and Elixir for long-term running stuff?
I'm an indie developer building such a back-end (social networking/chat space), have full choice of language. Started using Go earlier this year and mostly happy with it.
Should I switch to Elixir in my next iteration? Would it make me more productive, or save me from various deployment hurdles in long-term?
(Please don't take this as one of those mostly aimless "Hey, is Ruby or Python better?" type of questions. I hate those myself. I'm going to be investing thousands of hours into Go at this point. Hoping for some serious pro-vs-con discussion, hoping people who have architected something big in either language could chime in -- such is the major plus of asking on HN.)
I tried Googling, and the best/most recent I found was this thread. [1]
I don't know enough about the internals of the languages to speak on that, but here's what has influenced my decision on choosing Elixir:
Community: smart people (who I respect) in the Ruby community are getting really excited about (and choosing) Elixir. People like José Valim, Dave Thomas, Bruce Tate, Chris McCord, etc.
BEAM and OTP: The Erlang VM and OTP have been battle-tested at Ericsson. It's known for having 9 9's of reliability and scaled WhatsApp to millions of simultaneous connections.
HEX: like Rubygems was for Ruby, Elixir/Erlang has a budding package management system via Hex. Hopefully this becomes the canonical source for libraries.
Phoenix: Rails popularized Ruby and became the framework of choice for quickly and pragmatically developing CRUD apps. Phoenix has Rails-like conventions in building an Elixir app and has built in support for websockets. This framework is built for today's technology.
Syntax: Coming from Ruby, the Elixir syntax is approachable and understandable. It's easy to jump into without having much prior knowledge.
Kinda subjective, but those are reasons why I'm excited and choosing Elixir to build future projects upon.
One thing that attracts me to Elixir is what it doesn't have to do. Go had to start from 0, Clojure had to build FP on top of Java. If they work at all, it's a success.
By contrast, if Elixir just works, it's useless. Its functionality comes almost entirely from Erlang. Therefore its whole reason to exist is to make using that power more pleasant.
That's why, for example, Jose Valim has said "if you see a bad error message in Elixir, which makes you confused and does not help you solve the problem, pls open a bug report." https://twitter.com/josevalim/status/621933537009246208
"The Go devs have since stated that they were surprised to see that a lot of Go converts were from dynamic languages like Python and not C or C++. Go still makes sense for a lot of apps ... somewhere, however, that has been extrapolated to the idea that Go is a good language for writing web apps."
I think this is the crux of the question. And heck, it's very easy to spin up a web server in Go, and so many intro examples focus on that.
One thing I really like about Go is that the output is a binary. This significantly reduces some types of infrastructure complexity (deploy, CI, etc).
After a long stint as a python dev, I find myself seemingly almost subconsciously avoiding languages that require a ceremonial dance and some type of sacrifice to get all the various bits (dependencies, etc) in just the right place before the app will start up properly.
Elixir is easier to deploy than Python/Ruby. Since Elixir compiles down to bytecode all you need installed on a server is the BEAM (the name of Erlang's virtual machine). It's not as simple as a binary but is still a significant improvement over git-based deployments.
You are probably more productive in Elixir at the early stage of development. However, I personally think Go would be better for long-term development because it is statically typed.
You can read more about pros and cons of statically and dynamically type languages [1]
The presence of a type system definitely improves maintainability, however it is only one of many factors. Being C and Haskell both statically typed, are they equally suitable for long term development?
For example, Elixir is a more "strict" dynamic language than your usual Python/Ruby/Javascript. Data is immutable. There is no monkey patching. Most state changes happen explicitly via process communication. The macro system is compile-time which means nothing will pull the carpet under your feet at runtime.
Also long-term productivity is about actually maintaining your system in production. And Elixir leverages 3 decades of experience on that, using a runtime designed to build systems that self-heal and are fault-tolerant (I slightly explore this here: http://blog.plataformatec.com.br/2015/06/elixir-in-times-of-...).
I don't want to give a yes or a no answer, I would just like to point out the line is much blurrier than that. It doesn't matter which type system you use, your code is going to have bugs or unexpected situations will arise, specially when we are talking about network. So knowing that your system system can heal itself is quite comforting.
Those are two complementary aspects. It is one of the reasons I would love to see a statically typed language succeed in the Erlang VM.
I've used both Go and Elixir so here's my thoughts:
Elixir/Erlang aren't your typical dynamic language. Elixir is compiled and has pattern matching. I catch a ton of bugs at compile time in Elixir that I would never catch in Ruby/Python/JS until runtime. Examples of these are misspelled variables/bindings/function names and pattern match that will never actually match. Those are really, really common time wasters all taken care of at compile time.
Now what types of errors in Go really hurt you? Race conditions at runtime. I have to be way more careful about that to where it was costing me a lot of time in very concurrent programs. Eventually you develop a paranoia. Go has better tooling to help with this now, but concurrency and a language that prefers pointers just doesn't mix well. In Elixir I don't worry about this because everything is immutable. Now that GOMAXPROCS defaults to NumCPU I think a lot of programs that looked race condition-free probably aren't.
As far as runtime goes, Elixir and Go are at the same mercy but Elixir has much better debubbing capabilities than Go thanks to Erlang.
If you want something that gets you closer to static types and you have the discipline to keep up with running it and maintaining your type annotations, there's always dialyzer.[0].
Elixir can be optionally typed with the Dialyzer which will bring you to about the same level of static typing as go (if not more because the dialyzer allows for generics).
I've heard this argument before. For a long time, actually. But the kinds of errors I have are only rarely related to type issues, and those are almost always caught very early. YMMV, that's just been my experience.
All of our servers and daemons at Cronitor have been built using Python. I know you're asking just about these two languages but i would consider a language with a bigger library and user base. It takes discipline with language features but we've had a lot of success writing stateless daemons that are under heavy load 24/7. It's been far easier to think from a fan-out pov vs worrying about every clock cycle wasted by, for example, the garbage collector.
My advice would be to find out for yourself and don't believe the hype:
> Would you say Go is more suited for high-performance command-line tools, and Elixir for long-term running stuff?
Like Go isn't very high performance. See for yourself: http://benchmarksgame.alioth.debian.org/ (I know, lies, damn lies and benchmarks, but it's the best we got!). Elixir is it good for marathons because it's based on Erlang and Ericsson claims six nines uptime? Just use the tech you find is most FUN to work with because it's better to have fun programming than being bored.
Also it depends on the system you are building. Elixir and Erlang scale great and send messages even between servers fast! So if you need to scale it is great. Go I am sure is faster performance wiz but Elixir/Erlang will stay running longer and be easier to reason about as the system gets bigger. Go will be easier to find devs then Elixir/Erlang will be harder. So there are trade offs.
In the end you could use both, use the right tool for the job.
No, I won't!
I would advice you to learn them both instead, they are on such opposite sides, than knowing both will expand your knowledge in a very fulfilling way.
Nice insight. Learning more languages, especially those that seem to be different, could widen one's perspectives, and able to avoid the issue of learning only hammer and treat all problems as nails.
Hmm, still in the exploratory-hacking phase. Rewrote various parts of what Gorilla provides for learning purposes, plan to switch to Gorilla.
Using "lib/pq" (Postgres) for the db.
Also: need to cache some computed data in memory, and reload using a REPL or other means, haven't figured out the most "batteries included" way to do so yet.
Also: need to figure out the most production-friendly way to redeploy code (sounds like Erlang/Elixir can do really well in this regard.)
After spending nearly 7 years in the Ruby and Rails ecosystem, I changed jobs and have been working in with Elixir and Phoenix for nearly 3 months. I have been very satisfied with the process. The community is amazing, the tooling is unbeatable, and the quality and availability of open source libraries is great, especially for such a young project. The future looks very bright for Elixir and Phoenix!
Agreed. One of the many things that makes Phoenix/Elixir great for us rails/ruby refugees is that it's built by other rails/ruby refugees. In many ways, we have all the good things that our old masters DHH trailblazed with rails, but at the same time, very little of the mess that also came with the trail-blazing.
That being said, I do miss active_support though; Elixir's utility libraries (fox, pipe, croma, etc.) doesn't yet have all the easy automagic that made rails so simple to develop on.
1) Referring to DHH and others as a "our old masters" instinctively bothered me.
2) While I appreciate that Elixir and Phoenix have Rails connections and can learn from it, I'd prefer it not become just a place for Rails refugees where it turns into a huge circle jerk about how Rails is terrible and Phoenix is great (which happens all too often in communities).
Other than that, I agree. But we should start something new.
The flip side is that everyone is trying to write Ruby packages and projects in Elixir rather than thinking out of the box as to what is best for this new programming paradigm.
Phoenix shares many features with Ruby on Rails, e.g. a strong MVC model, an integrated ORM, a routing system, etc. What Phoenix on Elixir excels at is concurrency and distributed computing. For applications, this means you can have many active web sockets, for instance, where Rails applications tend to break down when you have too many active connections. Phoenix uses erlang processes for these tasks, which are lightweight and can number millions on a single machine.
As an example, Heroku uses cowboy (the erlang web server that Phoenix uses) for load-balancing incoming connections to all Heroku applications. The erlang VM (BEAM) is great for these types of highly concurrent, highly available, distributed tasks. The original use case for erlang was highly available phone switching for Ericsson.
Better for building out services. Parallel processing. The supervised process abstractions are incredibly powerful.
If you're building another Twitter I would still use Rails. You'll be much more productive.
On the other hand, if you need to run parallel tasks or have mission-critical (aka can't go down for anything) work to be done I think you'll find Elixir the perfect combination of Ruby's syntax and Erlang's power.
Just my $.02 - I'm having a blast with Elixir at the moment.
Phoenix and Elixir are really great tools. I spent the summer building a bunch of interactive components for an EdX MOOC (https://imgur.com/a/rAXVz), and got to try out a lot of Phoenix capabilities (channels/websocket support is great!), but also using underlying Elixir/Erlang libraries for task-queues, email sending and receiving, etc. Super stable, never able to get our server above a few percent of CPU :)
Do you have any blog posts on task-queues and email sending/receiving? I'm trying to learn Phoenix and Elixir by rewriting an app I have that does just this.
Sidekiq has been great as a background worker, but I'd like to try concurrency elsewhere.
Just wrote something on [sending errors by emails](http://reganmian.net/). The full code is here: https://github.com/houshuang/survey, including my job module https://github.com/houshuang/survey/blob/master/lib/job_work.... The code worked well for me, mostly because it registers errors and retries (I had problems with rate-limiting of Amazon SES), however it's not parallel right now. I will probably rewrite it to have a single module that gets tasks from the DB, and then dispatches it to workers, and I want to split it out into a separate library.
Note that this was my first Elixir library and I was very much learning as I went along. Lot's of code that I want to refactor and extract.
If you're curious about the framework as well, here's the source for an app I made for peer-to-peer file sharing in Phoenix: https://github.com/hayesgm/fuego. You can try it out here: https://fuego.link
Phoenix has really been exciting to use. It's a great way to get introduced into the OTP system from Erlang (plus all of Erlang's modules), it's incredibly fast, and the immutable data structures make it easy to reason about your concurrent code. I would strongly suggest giving it a try.
It's also worth noting that Ecto [1], the core-maintained Elixir ORM-like package, also hit v1 earlier this week and has backends for dealing with: PostgreSQL, MySQL, MSSQL, SQLite3 & MongoDB.
Ecto isn't an ORM since Elixir isn't OO. Terminology aside, Ecto identifies more as an Integrated Query Language in a similar vein as LINQ does in the .NET ecosystem.
As someone who has used lots of ORMs I find the switch to a libary like Ecto very refreshing. It has an intuitive and very composable querying API and friendly DSLs for defining schemas and validations. These are the baseline features of any database/modeling library and Ecto satisfies them nicely.
But by far my favorite feature that has come in handy is that Ecto's concept of Repos does not couple you to a specific database. Unlike traditional ORMs that couple your objects to a specific database (read: the my_cool_app database in MySQL or Postgres) it's easy to support different databases within the same type of RDBMS or different RDBMS entirely. Since all querying in Ecto goes through Repo modules all you need to do is just create more Repo modules and configure them accordingly.
For some people this feature might not sound useful but if you've ever worked on an Enterprise or older app with multiple data sources or want to switch from MySQL to Postgres, this is a killer feature. Doing this with Rails' ActiveRecord is ugly, buggy, a pain and will bring you to your knees during Rails upgrades any time there are major changes in ActiveRecord.
Personally, I have enjoyed using it. I prefer to stay closer to the SQL than perhaps most would and writing queries in Ecto felt a lot like SQL but with added composability.
Unfortunately, I don't have experience with using the ORMs you listed in anger so I can't make a direct comparison. Anecdotally, I have found it much nicer to use than Django's.
I've used Rails, but a long time ago. However, I really enjoyed Ecto; the migrations, the query interface etc. Still wrapping my head around changesets (I think it's quite simple, but when I began with Phoenix there were just so many new concepts).
Very exciting that they are branching out to support MongoDB as well. I'd love if they could support more untraditional Postgres operators for arrays and json (I guess there's always a tension between least common denominator and using the specialized features of each DB). You can get around it with partials, but it makes the code more messy.
This is awesome! I've been working with Phoenix for a bit now, and aside from the fact hex/phoenix doesn't yet have all the libraries that rubygems/rails have, Phoenix has blown my expectations out of the water. For such a big and complex framework, the entire functional plug system (functional is love, functional is life) makes the whole thing easy to grok in a way utterly unimaginable in a traditional rails framework.
By the way, in case core team is reading, what's the motivation behind removing infer_model_view from the render functions?
I haven't done much either with Elixir or Ruby (I do more Python and Erlang). But one thing I noticed is Valim (and others on the team) created a really approachable langauge and framework. Their emphasis on new comers, documentation, friendliness of community is outstanding.
Also Elixir will bring more people to the BEAM VM and take advantage of it, as I think it is a gem of engineering.
It's great having new people, but hopefully we'll avoid the clusterfuck of gems and node modules that are the hallmark of the perpetually-immature web development community.
When people choose to build on a more esoteric language such as Elixir (and to lesser extent Erlang) is it because what they want to do simply is not possible in Ruby/Python/Go/JavaScript/etc or just less efficient, elegant, productive, etc?
> is it because what they want to do simply is not possible in Ruby/Python/Go/JavaScript/etc
There are several key distinctions about Elixir vs the other languages you mentioned. These are things that are basically not going to happen in Ruby, Python, Go, Javascript, or etc.:
1) You get the benefits of Erlang/OTP as others have mentioned in their replies.
2) You also get the amazing macro capabilities (runtime code execution and runtime code generation, a la LISP) that Elixir brings to the table. Many of the language features of Elixir are written in macros in Elixir. The source to both Elixir and Phoenix are quite elegant and educational to browse, and demonstrate this runtime code generation aspect very well. It's straightforward in Elixir to introspect code, represent that code as data structures, manipulate those data structures, then generate or execute that code, as you can in LISP.
3) Immuatable data and functional style leads to better code in lots of ways. This is what really makes the benefits of OTP possible (updating the code without restarting the servers, easily migrating state between servers, and so on). But it also makes certain kinds of situations easier to understand and fix, since all state in the system can be expressed as parameters to functions.
Erlang/OTP is great fit for building applications that support a huge amount of concurrent users, but the problem is that IMO Erlang is nowhere near as pleasant to work with as Ruby, Python, etc. So if you're building something with zero users and choosing Erlang because of the ROFLscale potential it's premature optimisation. Elixir is the difference. I am just as productive in it as anything else and I enjoy it much more. So what we have is the massive power and potential of Erlang/OTP with a productive, pleasant API and great developer tools (Mix, Hex, etc).
Everything is possible in a Turing complete language (assuming enough of base utility functions are provided by stdlib), so the question is not possible vs impossible, but how much of a help the tool is.
Erlang provides great abstractions for building fault-tolerant, scalable, distributed, soft real-time systems. That's not to say you can't do it with Erlang, but Erlang does give some simple, yet very powerful tools for making developer's life easier.
Without Erlang you have to work harder to get similar effects. Again, it's not impossible but there's more burden on developers because the runtime provides less guarantees. I elaborated a bit on the topic in the promo interview for my book (http://www.infoq.com/articles/elixir-in-action-erlang-review).
The latter. The virtues of Elixir is that it is a functional language with immutable data structures, and that it does not support object oriented programming (which I consider a feature).
I did. I love Rails. Love it. Love Ruby. I've been writing code for over 25 years this year, and I've been doing Ruby for 10. And I hit a big brick wall with a very websocket-heavy app I'm building.
I switched to Elixir and Phoenix last year and got the core of my app working.
It's funny though - the core is easier. But many freebies from Rails aren't there yet. So I still don't have password recovery emails or confirmation emails on signup done yet :)
my employer uses erlang because it's a huge leap forward operationally over ruby/python/go/java. the erlang/otp concept of a release is extremely straightforward and reliable and the beam (erlang/elixir vm) run time introspection and debugging tools are second to none. it's trivial to attach to any running application and get a REPL with full access to the environment. you can even update running code in place
how do people typically put security (authentication and authorization) around this? You wouldn't want just anyone to be able to connect to your running apps, of course. From what I saw in Elixir, there's some kind of cookie/session key that you can specify, but is that it or is there more?
"You want to explore functional programming, but are put off by the academic feel (tell me about monads just one more time). You know you need concurrent applications, but also know these are almost impossible to get right. Meet Elixir, a functional, concurrent language built on the rock-solid Erlang VM. Elixir’s pragmatic syntax and built-in support for metaprogramming will make you productive and keep you interested for the long haul. This book is the introduction to Elixir for experienced programmers."
Ah, this is great. Hopefully now there won't be updates that alter syntax and functionality with quite the same frequency! (check the 'Upgrading from...' posts)
I'm pretty excited about Elixir and Phoenix. Building on Erlang's OTP should mean scaling can be fairly transparent.
I have been working with Phoenix for about a year. Upgrading hasn't been bad. The most inconvenient thing was when Ecto changed some APIs to return tuples, and changing Ecto.Repo.update/2 to be a no-op with no changes. It really isn't that bad with a good test suite though. :)
Readit News
I'm an indie developer building such a back-end (social networking/chat space), have full choice of language. Started using Go earlier this year and mostly happy with it.
Should I switch to Elixir in my next iteration? Would it make me more productive, or save me from various deployment hurdles in long-term?
(Please don't take this as one of those mostly aimless "Hey, is Ruby or Python better?" type of questions. I hate those myself. I'm going to be investing thousands of hours into Go at this point. Hoping for some serious pro-vs-con discussion, hoping people who have architected something big in either language could chime in -- such is the major plus of asking on HN.)
I tried Googling, and the best/most recent I found was this thread. [1]
[1] https://www.reddit.com/r/elixir/comments/3c8yfz/how_does_go_...
Community: smart people (who I respect) in the Ruby community are getting really excited about (and choosing) Elixir. People like José Valim, Dave Thomas, Bruce Tate, Chris McCord, etc.
BEAM and OTP: The Erlang VM and OTP have been battle-tested at Ericsson. It's known for having 9 9's of reliability and scaled WhatsApp to millions of simultaneous connections.
HEX: like Rubygems was for Ruby, Elixir/Erlang has a budding package management system via Hex. Hopefully this becomes the canonical source for libraries.
Phoenix: Rails popularized Ruby and became the framework of choice for quickly and pragmatically developing CRUD apps. Phoenix has Rails-like conventions in building an Elixir app and has built in support for websockets. This framework is built for today's technology.
Syntax: Coming from Ruby, the Elixir syntax is approachable and understandable. It's easy to jump into without having much prior knowledge.
Kinda subjective, but those are reasons why I'm excited and choosing Elixir to build future projects upon.
By contrast, if Elixir just works, it's useless. Its functionality comes almost entirely from Erlang. Therefore its whole reason to exist is to make using that power more pleasant.
That's why, for example, Jose Valim has said "if you see a bad error message in Elixir, which makes you confused and does not help you solve the problem, pls open a bug report." https://twitter.com/josevalim/status/621933537009246208
Here I am pimping my own stuff but I wrote a related article on this:
http://lebo.io/2015/06/22/the-unix-philosophy-and-elixir-as-...
"The Go devs have since stated that they were surprised to see that a lot of Go converts were from dynamic languages like Python and not C or C++. Go still makes sense for a lot of apps ... somewhere, however, that has been extrapolated to the idea that Go is a good language for writing web apps."
I think this is the crux of the question. And heck, it's very easy to spin up a web server in Go, and so many intro examples focus on that.
After a long stint as a python dev, I find myself seemingly almost subconsciously avoiding languages that require a ceremonial dance and some type of sacrifice to get all the various bits (dependencies, etc) in just the right place before the app will start up properly.
You can read more about pros and cons of statically and dynamically type languages [1]
[1] http://programmers.stackexchange.com/questions/122205/what-i...
For example, Elixir is a more "strict" dynamic language than your usual Python/Ruby/Javascript. Data is immutable. There is no monkey patching. Most state changes happen explicitly via process communication. The macro system is compile-time which means nothing will pull the carpet under your feet at runtime.
Also long-term productivity is about actually maintaining your system in production. And Elixir leverages 3 decades of experience on that, using a runtime designed to build systems that self-heal and are fault-tolerant (I slightly explore this here: http://blog.plataformatec.com.br/2015/06/elixir-in-times-of-...).
I don't want to give a yes or a no answer, I would just like to point out the line is much blurrier than that. It doesn't matter which type system you use, your code is going to have bugs or unexpected situations will arise, specially when we are talking about network. So knowing that your system system can heal itself is quite comforting.
Those are two complementary aspects. It is one of the reasons I would love to see a statically typed language succeed in the Erlang VM.
Elixir/Erlang aren't your typical dynamic language. Elixir is compiled and has pattern matching. I catch a ton of bugs at compile time in Elixir that I would never catch in Ruby/Python/JS until runtime. Examples of these are misspelled variables/bindings/function names and pattern match that will never actually match. Those are really, really common time wasters all taken care of at compile time.
Now what types of errors in Go really hurt you? Race conditions at runtime. I have to be way more careful about that to where it was costing me a lot of time in very concurrent programs. Eventually you develop a paranoia. Go has better tooling to help with this now, but concurrency and a language that prefers pointers just doesn't mix well. In Elixir I don't worry about this because everything is immutable. Now that GOMAXPROCS defaults to NumCPU I think a lot of programs that looked race condition-free probably aren't.
As far as runtime goes, Elixir and Go are at the same mercy but Elixir has much better debubbing capabilities than Go thanks to Erlang.
If you want something that gets you closer to static types and you have the discipline to keep up with running it and maintaining your type annotations, there's always dialyzer.[0].
> Would you say Go is more suited for high-performance command-line tools, and Elixir for long-term running stuff?
Like Go isn't very high performance. See for yourself: http://benchmarksgame.alioth.debian.org/ (I know, lies, damn lies and benchmarks, but it's the best we got!). Elixir is it good for marathons because it's based on Erlang and Ericsson claims six nines uptime? Just use the tech you find is most FUN to work with because it's better to have fun programming than being bored.
In the end you could use both, use the right tool for the job.
Deleted Comment
Using "lib/pq" (Postgres) for the db.
Also: need to cache some computed data in memory, and reload using a REPL or other means, haven't figured out the most "batteries included" way to do so yet.
Also: need to figure out the most production-friendly way to redeploy code (sounds like Erlang/Elixir can do really well in this regard.)
That being said, I do miss active_support though; Elixir's utility libraries (fox, pipe, croma, etc.) doesn't yet have all the easy automagic that made rails so simple to develop on.
1) Referring to DHH and others as a "our old masters" instinctively bothered me.
2) While I appreciate that Elixir and Phoenix have Rails connections and can learn from it, I'd prefer it not become just a place for Rails refugees where it turns into a huge circle jerk about how Rails is terrible and Phoenix is great (which happens all too often in communities).
Other than that, I agree. But we should start something new.
As an example, Heroku uses cowboy (the erlang web server that Phoenix uses) for load-balancing incoming connections to all Heroku applications. The erlang VM (BEAM) is great for these types of highly concurrent, highly available, distributed tasks. The original use case for erlang was highly available phone switching for Ericsson.
If you're building another Twitter I would still use Rails. You'll be much more productive.
On the other hand, if you need to run parallel tasks or have mission-critical (aka can't go down for anything) work to be done I think you'll find Elixir the perfect combination of Ruby's syntax and Erlang's power.
Just my $.02 - I'm having a blast with Elixir at the moment.
Sidekiq has been great as a background worker, but I'd like to try concurrency elsewhere.
Note that this was my first Elixir library and I was very much learning as I went along. Lot's of code that I want to refactor and extract.
Phoenix has really been exciting to use. It's a great way to get introduced into the OTP system from Erlang (plus all of Erlang's modules), it's incredibly fast, and the immutable data structures make it easy to reason about your concurrent code. I would strongly suggest giving it a try.
It's also worth noting that Ecto [1], the core-maintained Elixir ORM-like package, also hit v1 earlier this week and has backends for dealing with: PostgreSQL, MySQL, MSSQL, SQLite3 & MongoDB.
[1] https://github.com/elixir-lang/ecto
As someone who has used lots of ORMs I find the switch to a libary like Ecto very refreshing. It has an intuitive and very composable querying API and friendly DSLs for defining schemas and validations. These are the baseline features of any database/modeling library and Ecto satisfies them nicely.
But by far my favorite feature that has come in handy is that Ecto's concept of Repos does not couple you to a specific database. Unlike traditional ORMs that couple your objects to a specific database (read: the my_cool_app database in MySQL or Postgres) it's easy to support different databases within the same type of RDBMS or different RDBMS entirely. Since all querying in Ecto goes through Repo modules all you need to do is just create more Repo modules and configure them accordingly.
For some people this feature might not sound useful but if you've ever worked on an Enterprise or older app with multiple data sources or want to switch from MySQL to Postgres, this is a killer feature. Doing this with Rails' ActiveRecord is ugly, buggy, a pain and will bring you to your knees during Rails upgrades any time there are major changes in ActiveRecord.
Unfortunately, I don't have experience with using the ORMs you listed in anger so I can't make a direct comparison. Anecdotally, I have found it much nicer to use than Django's.
Very exciting that they are branching out to support MongoDB as well. I'd love if they could support more untraditional Postgres operators for arrays and json (I guess there's always a tension between least common denominator and using the specialized features of each DB). You can get around it with partials, but it makes the code more messy.
By the way, in case core team is reading, what's the motivation behind removing infer_model_view from the render functions?
Also Elixir will bring more people to the BEAM VM and take advantage of it, as I think it is a gem of engineering.
I'm not on the core team, but speaking as an Elixir user, explicitness trumps all virtues.
There are several key distinctions about Elixir vs the other languages you mentioned. These are things that are basically not going to happen in Ruby, Python, Go, Javascript, or etc.:
1) You get the benefits of Erlang/OTP as others have mentioned in their replies.
2) You also get the amazing macro capabilities (runtime code execution and runtime code generation, a la LISP) that Elixir brings to the table. Many of the language features of Elixir are written in macros in Elixir. The source to both Elixir and Phoenix are quite elegant and educational to browse, and demonstrate this runtime code generation aspect very well. It's straightforward in Elixir to introspect code, represent that code as data structures, manipulate those data structures, then generate or execute that code, as you can in LISP.
3) Immuatable data and functional style leads to better code in lots of ways. This is what really makes the benefits of OTP possible (updating the code without restarting the servers, easily migrating state between servers, and so on). But it also makes certain kinds of situations easier to understand and fix, since all state in the system can be expressed as parameters to functions.
Erlang provides great abstractions for building fault-tolerant, scalable, distributed, soft real-time systems. That's not to say you can't do it with Erlang, but Erlang does give some simple, yet very powerful tools for making developer's life easier.
Without Erlang you have to work harder to get similar effects. Again, it's not impossible but there's more burden on developers because the runtime provides less guarantees. I elaborated a bit on the topic in the promo interview for my book (http://www.infoq.com/articles/elixir-in-action-erlang-review).
I switched to Elixir and Phoenix last year and got the core of my app working.
It's funny though - the core is easier. But many freebies from Rails aren't there yet. So I still don't have password recovery emails or confirmation emails on signup done yet :)
https://pragprog.com/book/elixir/programming-elixir
From the website:
"You want to explore functional programming, but are put off by the academic feel (tell me about monads just one more time). You know you need concurrent applications, but also know these are almost impossible to get right. Meet Elixir, a functional, concurrent language built on the rock-solid Erlang VM. Elixir’s pragmatic syntax and built-in support for metaprogramming will make you productive and keep you interested for the long haul. This book is the introduction to Elixir for experienced programmers."
If you want a deeper look at Elixir - I'd recommend Elixir in Action by Saša Jurić (Manning publications).
Ben Tan Wei Hao's book is also promising (still in early release) - The Little Elixir & OTP Guidebook also Manning.
I'm pretty excited about Elixir and Phoenix. Building on Erlang's OTP should mean scaling can be fairly transparent.