Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Existential crisis at Railsconf

railsbird.tumblr.com

Post reply on HN
Print view View original

11–20 of 168 posts

Re: Existential crisis at Railsconf

#11

Post by erichmond »

hopeless wrote: post #6

LOL at the idea that every Rails programmer will be switching to Clojure or Elixir! While they might be interesting languages (particularly Elixir) I don't see any 10x advantages their web stacks have over Rails for the typical "majestic monolith" use case. Re. EventMachine: As I understood DHH's speech, the idea is that ActionCable abstracts all the messiness around EventMachine, Websockets, Rack and threads. We won…

This is just an anecdote as:

- I agree that most rails programmers will not move to clojure.

- For monorail apps, rails is still king.

That said, for us, when comparing clojure and ruby REST API services we've built, clojure has had the following benefits:

- Less code

- Less tests needed

- Better concurrency

- Less developer hours

- Less maintenance

- About 33% of the servers for same performance

- Easier/faster debugging

It's been far more then a 10x improvement overall, and if people are looking to move out of the monorail style of app, it's definitely worth a look.

Re: Existential crisis at Railsconf

#12

Post by railsbadruby »

Rails was always crappy, it just took you a while to realise what we already knew. A framework so full of security fails it made PHP look secure.

My main concern though is all the rails rats jumping ship and sinking the promising good ship phoenix and elixir.

Re: Existential crisis at Railsconf

#13

Post by otterley »

Websockets isn't really HTTP and so it doesn't really conform to the request/response model in HTTP that is centered around retrieving document objects.

Most web service implementations, including Rails, are built around that paradigm - they get a request for a document, they return it, then they can forget about it (stateless) and move on to serving subsequent document requests, which are likely to be entirely unrelated to the first request. The Rack framework that connects Rails to webservers like Unicorn is just a thin (pun not intended) abstraction on top of that.

Websockets, on the other hand, is a clever way to upgrade (or rather downgrade) an HTTP connection to its lower-layer communication channel, the TCP socket. Once you escape the document-oriented confines of HTTP, the kind of server you need changes because the concurrency model could be entirely different. If you expect a long-running communication channel with a client, a forking webserver like Unicorn is going to have scalability limits (as you'll need a process per connection), and you're going to have a lot of Rails code in memory that has no use whatsoever.

So I wouldn't expect that Rails would be very useful for a websocket service. And I wouldn't fret about it either :) Different protocols often require different services.

Re: Existential crisis at Railsconf

#14

Post by jazzyb »

jameskilton wrote: post #7

For those wondering what the alternatives to Rails are these days, I highly recommend checking out Elixir and the Phoenix framework. http://elixir-lang.org/ http://www.phoenixframework.org/

Interestingly, Elixir was created by one of the Rails Core developers mentioned in the article: Jose Valim.

Re: Existential crisis at Railsconf

#15

Post by davidw »

railsbadruby wrote: post #12

Rails was always crappy, it just took you a while to realise what we already knew. A framework so full of security fails it made PHP look secure. My main concern though is all the rails rats jumping ship and sinking the promising good ship phoenix and elixir.

You do know that José Valim is both the developer of Elixir and a Rails core guy, right?

Re: Existential crisis at Railsconf

#16

Post by rakoo »

otterley wrote: post #13

Websockets isn't really HTTP and so it doesn't really conform to the request/response model in HTTP that is centered around retrieving document objects. Most web service implementations, including Rails, are built around that paradigm - they get a request for a document, they return it, then they can forget about it (stateless) and move on to serving subsequent document requests, which are likely to be entirely unrel…

You don't need to go as far as websocket to leave the stateless world: Server-Sent Events and all its cousings (Comet, chunked transfer encoding, even long polling ...) all need to keep a connection open for an unknown amount of time and then send data back to the client. Is Rails discouraged for such use cases ?

Re: Existential crisis at Railsconf

#18

Post by jimiray »

jameskilton wrote: post #7

For those wondering what the alternatives to Rails are these days, I highly recommend checking out Elixir and the Phoenix framework. http://elixir-lang.org/ http://www.phoenixframework.org/

The websocket support in Phoenix is amazing. And it's not a huge jump to at least get an app up and running if you are a Ruby developer. Most of the really hard things from elixir/erlang have been tucked away nice and neat.

Re: Existential crisis at Railsconf

#20

Post by railsbird »

hopeless wrote: post #6

LOL at the idea that every Rails programmer will be switching to Clojure or Elixir! While they might be interesting languages (particularly Elixir) I don't see any 10x advantages their web stacks have over Rails for the typical "majestic monolith" use case. Re. EventMachine: As I understood DHH's speech, the idea is that ActionCable abstracts all the messiness around EventMachine, Websockets, Rack and threads. We won…

> 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.

Post reply on HN