[DevinTheDude]

First, thanks for taking the time to answer my question, I'm at my day job (I program at night) so I can't do much research

>correct a lot of core issues that come up long term with Rails.

I've never gotten to this point, what are some of these issues? From reading comments here, it seems like dependency hell could be one, but what do you think? I've had issues in my short time with outdated gems, but I don't know if this is necessarily an issue with the framework/language.

[fbonetti]

For me personally, one of the coolest features of Phoenix is that it natively supports concurrency. Communicating with a front-end via websockets is really easy to do with Phoenix, whereas in Rails it's basically unheard of. I know that Rails 5 is going to introduce ActionCable and that it's possible to write event-based apps with EventMachine, but these are ultimately poor solutions compared to what's capable in languages that take concurrency seriously (like Elixir).

[brightball]

Dependency hell is s big one.

Monolith syndrome is another and one of the huge perks of Elixir is that it forces you to build in a way that makes separating out parts later on much simpler.

Performance is "the" major one because it's one of those things that you just can't overcome easily with Ruby. Usually that leads long term to refactoring a part of your system in another language like Go just for performance sake.

The routing layer is one of the biggest issues that is incredibly difficult to solve in non-compiled languages.

People are familiar with callback hell in JavaScript but the same thing happens overtime from using all of those before/after callbacks, nesting from inheritance, etc.

Rack middleware is great until you only want it on some of your requests. At that point things end up in a top level controller that other controllers are inheriting from which forces those parts to get hit after the router. Phoenix has something called pipelines that basically lets you define your middleware stack for sets of routes or even based on request matching like "accepts json" vs "accepts html".

ActionCable has just been added to handle websockets but whether or not they will actually scale remains to be seen. Phoenix has been built for it from the ground up and it's very impressive. You can find the 2 million websockets on a single server benchmark with some Googling.

RAM and CPU usage is better. Concurrent processes have built in supervisors that know how to restart them on failures and know how to drop associated concurrent jobs as well. It's as easy as Go routines but with fault tolerance.

Erlang eco system libraries are usable and bring a lot to the table so it's not like starting from nothing. The "awesome-elixir" page on github is a great reference.

It's functional programming with immutable data structures which forces you to think about problems a bit differently, but also ensures a better concurrency model since there is no such think as a mutex lock.

The built in hot code deploys from Erlang gives you zero downtime deploys on a single machine. Although I haven't yet tried this, people have suggested that this means you could deploy to with millions of connected websockets without breaking the connections (in the same way that Erlang was built to do this with phone systems without dropping calls).

It's a little bit mind blowing and as you can probably tell, I'm excited. ;)

[DevinTheDude]

Thanks a lot. I'm going to research this once I get home. You may have just saved my future project time/money.