This is interesting. I hear most about Elixir, with Clojure coming second. As I said above though, those are just examples, if I knew for a certain what is next, I would be learning it already.
In Berlin, Munchen people chat about elixir when they compare some pharma, alcohol industry. As for clojure, only small projects. as for the hype, let's say go. But, majority choose, php :)
A year ago we benchmarked Celluloid and Event Machine. Celluloid was much better... on JRuby. Event Machine was better on CRuby based on our tests and, since we couldn't migrate to the JVM due to other factors, we ended-up stuck with CRuby and Event Machine.
Agreed. I was fine with Railsconf focus last year of being "rock solid". Rails is still the best at what it does thanks to its community.
However, Rails 5 is moving to a direction that goes against the abstractions and platform it runs on. If I don't care about this, now I have even more code and dependencies in my Rails apps. On the other hand, if that is becoming the sanctioned way of building apps, I would rather do it elsewhere. To me it is a lose-lose situation.
> LOL at the idea that every Rails programmer will be switching to Clojure or Elixir!
I meant those as examples based on what I see around me. That's exactly my agony, I don't know what is next and, if I did, I would be learning it already. At this point, I just feel it is not Rails.
> Re. EventMachine: As I understood DHH's speech, the idea is that ActionCable abstracts all the messiness around EventMachine, Websockets, Rack and threads
If you are using Event Machine you can't abstract away from it. You need to do all I/O using Event Machine aware mechanisms. You can get rid of callbacks by using fibers but you are still required to use an API specific to Event Machine. For example, you can't use File.read to read a file as that will block your event loop.
Nginx HTTP Push Module seems to much better solution than EventMachine. So Nginx keeps opened sockets and a Rails app sends messages via ordinary HTTP.
I'm also wary of handling websockets from Ruby, which is demonstrably ill suited for any kind of high concurrency networking (been there, got the t-shirt).
Since most people already run nginx in their stack anyway I don't see the advantage of sticking with a Ruby-based solution that is almost guaranteed to be inferior on every metric.
You are confusing the real need to use EM aware mechanisms with a not-real inability to use abstractions over EM itself. Those are two different issues.
