News for hackers. Stuff that matters.
Re:Rails 5.0: Action Cable, API mode, and more by themgt on Thursday June 30, 2016 @07:27PM (#12012685)
Exactly this. It's easy to do 'rails new' and push to Heroku, but when you've got redis, memcache, the worker process & scheduler etc etc you're really maintaining your own ecosystem. It's a lot of where time gets spent on production Rails apps.

Here's that slide, I believe: http://i.imgur.com/QzTCJS8.png

Re:Rails 5.0: Action Cable, API mode, and more by mavelikara on Thursday June 30, 2016 @08:12PM (#12012938)
And here is a Ruby vs Java meme from 2006 or so: http://i.imgur.com/1V6rdWV.jpg.

This too shall pass.

Re:Rails 5.0: Action Cable, API mode, and more by mooreds on Friday July 01, 2016 @07:47AM (#12015272)
What's old is new again!
Re:Rails 5.0: Action Cable, API mode, and more by sayelt on Thursday June 30, 2016 @08:17PM (#12012959)
So NIH is the appealing factor of Elixir according to this slide?
Re:Rails 5.0: Action Cable, API mode, and more by bratsche on Thursday June 30, 2016 @10:06PM (#12013417)
No.

In a Rails system you've got Rails running, maybe across X number of instances with Unicorn or whatever, sitting behind nginx. If you want to have a long-running request or websocket you've typically used Go or Node or Elixir. If you need to store state between requests you may be using Redis. For background jobs and general async things you've probably got something like Sidekiq.

Erlang already has an http server that Elixir apps are using now, it's called Cowboy. It's not that Elixir is creating their own just because. One of the reasons nginx is often used for Rails apps is to handle static assets, because Rails just isn't as well-equipped to handle those. Cowboy seems to be fine with handling static assets, so a lot of people just take nginx out of the equation for an Elixir app.

Typically Rails apps have used something else like Node or Go or Elixir for long-running requests or websockets. Maybe that will change with ActionCable, maybe not. Either way, Elixir/Phoenix happen to be quite good at this already. Phoenix's equivalent to ActionCable is called Phoenix Channels and it's able to handle 2 million+ websocket connections on a single server, which is pretty cool I think.

Rails apps use redis to manage state between requests. Elixir apps just don't need something like this. Elixir doesn't have something different, it just happens to be easy to store state between requests already.

Rails apps may use Sidekiq or something to deal with background jobs or async operations. This is another case where Elixir doesn't have anything special to occupy that role in the stack, it just happens to be good at that already.

Most of these properties are things that Elixir inherited from Erlang, which has been around for years. I wish I had started learning Erlang a long time ago but unfortunately it just wasn't really on my radar. But really the only thing on this list which is a relatively recent thing is Phoenix Channels, and I don't think that's really a NIH thing. At least, certainly not any more than ActionCable is.

Re:Rails 5.0: Action Cable, API mode, and more by baudehlo on Friday July 01, 2016 @12:14AM (#12013831)
I'd love to see an active record (npi) of that 2m active web sockets. It's trivial these days to make 2m connections (it's just a RAM problem), but marshalling data between them is the non-trivial problem, as is actually having active data crossing those sockets.
Re:Rails 5.0: Action Cable, API mode, and more by gamache on Friday July 01, 2016 @05:52AM (#12014849)
Re:Rails 5.0: Action Cable, API mode, and more by bcardarella on Thursday June 30, 2016 @08:23PM (#12012985)
Considering that nearly all of those features were in Erlang before the other services listed I don't think NIH applies. Elixir just exposes the Erlang tools.