13 ms·

Existential crisis at Railsconf

206 points by railsbird 11y ago

colinramsay 11y ago
Could this be formalized? Have odd releases as "feature" releases and even releases as Snow Leopard-style "consolidation" releases?
davidw 11y ago
No, Rails isn't great for web socket kinds of things, but if it were me, I'd just use something else for that, and Rails for the main site. It's still one of the best things out there for quickly iterating, and yet still maintaining some structure and discipline, from what I've seen.
- axx 11y ago
  Same here, i see it this way: use the right tool, for the right job. Sometimes it's Ruby/Rails, sometimes it's Node, somtimes it's something else.
- railsbird 11y ago
  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.
  - brodock 11y ago
    I'm pretty sure "ActionCable" will be optional, as for example "ActiveResource" were
- knes 11y ago
  You could also use hosted solutions such as Pusher, Pubnub or Fanout which plays really well with frameworks
- serve_yay 11y ago
  > No, Rails isn't great for web socket kinds of things You're doing the "best tool for the job" thing. But if Rails is not a good tool for the job of web socket programming... then ya kinda have to wonder why they're rolling a web socket thing into Rails core, no?
- tonyarkles 11y ago
  What I've done a few times in the past is had a Rails server for the main app, and a node-based socket.io server for the websockets. All the socket.io server does is listen to a redis server and emit events to the right listeners.
noelwelsh 11y ago
In web framework terms, Rails is old. When it was created single-page applications weren't on anyone's radar, APIs were extremely uncommon, and websockets hadn't been invented. It's natural to expect some pain try to adapt new paradigms into the old model. Whether this pain is worth it is up to the individual to decide. My web applications are almost always pure client-side these days, so Rails is not something I often turn to.
- stephenson 11y ago
  Re "In web framework terms, Rails is old" Oh how I love that! I would rather build my business on something old and well testet then something new and shiny.
  - mgkimsal 11y ago
    would you move to java? that's older and even less shiny.
    - stephenson 11y ago
      I would, if the technology solved the problem, the workflow fitted our org, the cost of running it in production fitted our budget etc.
    - yellowapple 11y ago
      Or PHP. Or Perl. Or COBOL.
  - symfoniq 11y ago
    This. We didn't feel comfortable moving my company to Rails until it hit version 3. Maturity is a good thing.
  - LunaSea 11y ago
    http://www.cvedetails.com/vendor/12043/Rubyonrails.html http://www.cvedetails.com/vendor/12043/Rubyonrails.html "well tested"
hopeless 11y ago
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't know until some ActionCable code is released but it sure didn't look complicated. It does seem odd that -api takes years to get in, but ActionCable gets a go-straight-to-core pass without any community review first. It certainly seems like a weakness in the process, which should be addressed, although I'd agree with the eventual result & priorities. -api probably isn't something I'd ever use: even if I eventually created an API-only app, I'd probably have started from a regular Rails app and gradually optimised things out. Edited to add: I'm actually quite bullish on TurboLinks 3 if it can help me to avoid ever having to write a Javascript MVC app again. It's not so much that these apps are hard to write, it's that they're freaking hard to debug, particularly in the hands of users.
- erichmond 11y ago
  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.
  - matthewmacleod 11y ago
    Interestingly, we had a couple of Clojure experiments. Takeaway was that there were some benefits in terms of performance and maintenance, but they weren't worth the tradeoff in expressivity and increased developer time. There's no reason that Rails should be restricted to 'monorail' or monolithic apps. We've had great success writing what are essentially microservices in Rails. Code is easy to read, easy to maintain, and performs well. It's hard to find any compelling reason to use another toolset under those circumstances!
jameskilton 11y ago
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://elixir-lang.org/ http://www.phoenixframework.org/ http://www.phoenixframework.org/
- jazzyb 11y ago
  Interestingly, Elixir was created by one of the Rails Core developers mentioned in the article: Jose Valim.
- jimiray 11y ago
  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.
- pmontra 11y ago
  I used Phoenix for a small project last September, not much more than a toy but anyway... Pros: websocket support is good, the developers are friendly and answer questions, the app is faster than what I'm used to with Rails. Neutral: Elixir looks like Ruby but it's very different. Be prepared to learn everything from scratch. You need also to know a little Erlang and the OTP framework to be able to use some useful library functions. OTP is a world on its own. Cons: the tooling is very immature, probably like the one for Rails at the time of the 1.x releases. Be prepared to write many things by hand instead of requiring gem_x and automagically get functionality for free. This is going to slow down developement, increase costs and possibly get you outbid from competitors. Nevertheless it could be OK for internal projects used to get familiar with the framework.
  - chrismccord 11y ago
    We've come a long way since September, so please check again. I am outlining our 1.0 remaining milestones Friday at ElixirConfEU. We should see 1.0 in a few months
- vezzy-fnord 11y ago
mundanevoice 11y ago
Forget rails. Move to Django ;)
- davidw 11y ago
  Django has basically the same architecture as Rails, so it's really in the same boat from that point of view.
  - federico3 11y ago
    Minus the security issues.
    - biokoda 11y ago
      And equally bad at concurrency.
      - mpdehaan2 11y ago
        I don't buy this, having written and dealt with a lot of concurrent Django apps - I think people read something about the GIL often, and don't understand what the articles are really meaning. Basically Django is usually fronted with mod_wsgi and you use celery for backend tasks. The multiple requests part are dealt with because the web server pre-forks, and it's just fine with it. I think Django's problem is it moves very slowly, and mostly just that. The ORM isn't awesome, but it's workable. You can also choose to not use parts of it, like templates, and that's common in single-page apps.
        wldcordeiro 11y ago
        It's speeding up development lately, 1.8 came out rather fast but it seems like the Django team likes to have ~1 year development cycle.
        mundanevoice 11y ago
Kiro 11y ago
> as developers flock to new technologies like Clojure and Elixir Is that really the case? Clojure and Elixir?
- GnwbZHiU 11y ago
  I know people who move from Ruby/Rails to Golang. No people I know move from Ruby/Rails to Clojure and Elixir
  - railsbird 11y ago
    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.
    - claudiug 11y ago
      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 :)
railsbadruby 11y ago
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.
- davidw 11y ago
  You do know that José Valim is both the developer of Elixir and a Rails core guy, right?
- pjonesdotca 11y ago
  I love it when debate gets reduced to someone creating a troll account ( 'railsbadruby' account is 48 min old as I write this ) and badmouthing. Is this what HN discourse has come to?
otterley 11y ago
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.
- rakoo 11y ago
  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 ?
  - otterley 11y ago
    If you could run Rails in an event-driven webserver, it might be usable with persistent connections. Otherwise you'll need a whole lotta memory for all those workers that'll be sitting around doing nothing most of the time.
    - brodock 11y ago
      in other words: "unicorns considered harmful"
tinco 11y ago
> Unfortunately, we don’t have better options in Ruby for working with websockets. We do! Celluloid (the actor model) is vastly superior to EventMachine in my opinion. It fits much better to Ruby's OOP style and I suspect would integrate into Rails very cleanly. I am positive that bringing any EventMachine technology into the Rails stack would be a mistake. I am saying that with a bit of a bias as I have written my own celluloid-websocket[0] gem that comes with a Rack adapter. But I wrote it because I put a project using EventMachine websockets into production and was not happy with it. Now in a new project I can just hook up the celluloid-websockets Rack app and run it using `passenger start` or any of the Rack application servers. Even though so many people seem to flock to Node.JS for these kinds of servers, the fact that as a language Ruby is superior to Javascript remains, even if Javascript VMs are a hundred times as fast. As long as Node.JS is run on standards compliant VM's things like promises are just lipstick on the callback hell pig. You can write clean and understandable Ruby to solve any problem, including Websocket servers. We as the Ruby community were just late to the asynchronous I/O party. Now Celluloid is production ready, there's really no reason (except for performance of course) for a Ruby developer to write Javascript on the server side. (sorry for my extreme opinions, if you want a more nuanced deliberation on a point just ask ;)) 0] https://rubygems.org/gems/celluloid-websocket https://rubygems.org/gems/celluloid-websocket
- railsbird 11y ago
  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.
- onli 11y ago
  Do you have experience with https://github.com/ngauthier/tubesock https://github.com/ngauthier/tubesock? In a very small project of mine I used https://github.com/minoritea/sinatra-hijacker https://github.com/minoritea/sinatra-hijacker which I found very nice to program with.
- wilmoore 11y ago
  >> the fact that as a language Ruby is superior to Javascript remains, even if Javascript VMs are a hundred times as fast. As someone who frequently switches between Ruby/Rails and NodeJS (sometimes in the same day), I wonder about this statement (err, fact). You mentioned that the Ruby language is superior and that this is a "fact". What about the Ruby (I know Node isn't really a language, but for the sake of discussion, Node,JS,npm) is substantially better that the speed trade-off is worth it (besides familiarity)? In my case, I'm familiar with both, and I prefer Node,JS,npm. Node,JS,npm are definitely not perfect, yet still, I like it over Rails,Ruby,Gems/Bundler. I'm not looking to "win" here; I'm just very curious now given your assertion.
dham 11y ago
After trying Clojure(and Luminus) several times over the past year I don't think it would be my go to for things that Rails is tackling. On a side note writing Clojure gave me a little anxiety so I'm trying to hold back on it for now. After working in this stuff for a while I just use the right tool for the right job. Most of the time Rails is that tool and it allows you to just get stuff done. Sometimes Node is the right tool, or Python. I think the new Turbolinks stuff is pretty interesting(and useful) although it doesn't help me with forms, and that's the thing I'm usually using React or Angular for these days. Angular may get crap but it's actually really good at forms.
- brodock 11y ago
  I believe the right balance with turbolinks is a mix of React for interactive animated stuffs, graphs, etc, and turbolinks to render stuff that is better generated server side, or to push json data (and then bind it to your react component)
artursapek 11y ago
People use Rails to build websocket hubs?
t4nkd 11y ago
Is this just a really polite, introspective take on (Rails|Ruby) is a Ghetto? I can't point out one really valid critique in this entire rant. While I imagine that you've had enough kool-aid to actually believe the things you said, I think you should probably do a few google searches to find out how many shops are hiring Rails devs versus Clojure or Elixir. You can do more experimenting by seeing who else is actually working those jobs, what kind of professional experience they have, and if you're really lucky figure out what they get paid. Rails needs websockets, just like years ago when it needed a better way to handle organizing and deploying assets. The modern application demands it, and if you've ever had the pleasure of trying to build a websocket application in Ruby you'd understand why it's actually really exciting that we're going to get the Rails community to build this for all of us. If you want to be disenchanted about some aspect of Rails then pick the fact that the need for diversity at RailsConf this year has yielded some of the worst presentations I've ever seen (like, literally, the presenter spoke poor/broken english and the Docker oriented talks were about 6 months behind). Rails moves the way it does and absorbs the ideas it does because they become popular. It's much easier to add a feature that everyone wants, instead of inventing a feature that makes a solved problem that much easier/faster/what-have-you. DHH seems to have to explain this every few years, but go back in time when Rails adopted sprockets and you'll see posts not unlike the one you just wrote. Realistically, Ruby and Rails jobs are still among the highest paying in the industry. Startups and other more established companies still choose Rails as their platform, and not just for bullshit brochure sites. Certainly there remains a "best tool for the job" mentality but, right now, the alternatives are to: build it yourself, hop on a less "mature" framework -- Pheonix? I don't even know what you pick when you adopt Elixir as your platform language and need to build an API or front end apps but Pheonix won the google -- or choose from one of the popular technologies like Express.js, Laravel(?), or Django. That part of building technology (and business) didn't change, and there are still hundreds of thousands of Ruby and Rails engineers out there.
- kailuowang 11y ago
  > the alternatives are The main competitive alternatives to Rails are single page application frontend frameworks combined with light API focused backend frameworks. Not a single web application framework.
deedubaya 11y ago
The Rails team, including DHH, owes us nothing. They aren't required to give us a framework of our choosing, they're the ones building it! Just like we don't owe anything to Rails! DHH uses Rails for Basecamp, so it makes sense that he'll lead the project towards the goals of BC.
ksec 11y ago
To those unsure about Eventmachine https://github.com/eventmachine/eventmachine/blob/master/CHANGELOG.md https://github.com/eventmachine/eventmachine/blob/master/CHA... IT seems to have much more fix and features in recent months then its entire life span. And as DHH pointed out on twitter Clearing up misconception re: Action Cable: EventMachine only used for connection handling, threads for channel code. No block restrictions.
matthewmacleod 11y ago
I understand that there's not quite the same consistent 'theme' this year, but I'm not sure that's concordant with developers who are using Rails 'abandoning' it or anything like that. It's true that real-time operations like websockets are a total pain in the arse with Rails. Nobody's yet figured out an optimal solution for that sort of thing, and maybe ActionCable is a good solution. The thing is that while some demands on the web stack have changed, a lot of it is still pretty similar. We have HTTP requests, and HTML, and assets, and databases. It might turn out that Rails can also perform some other tasks that require realtime operation. Or maybe it won't be able to, and we'll be able to use some other tools. Ultimately, we're still using Rails for all of our new web apps. We've tried loads of different toolsets, but haven't found an alternative that's compelling enough to bother. So YMMV, but the fact that Rails is maybe a bit less exciting that newer frameworks doesn't mean it's not great to use any more.
PaulHoule 11y ago
I also see Basecamp as having jumped the shark. Highrise was a palatable "cheap and cheerful" CRM system but they decided to stop investing in it. The appeal of Basecamp is that it is a simple product and there isn't anything 40 developers can do to make it more simple.
alexggordon 11y ago
A slight tangent, but as a lover of rails and a user of websockets, I can't recommend Tubesock[0] highly enough. I think regardless of your opinion on event machine, Tubesock is a better engineering match for rails, than websocket-rails. Hopefully, the websocket support will be a standard in the future, as opposed to an afterthought for rails, but until that point, I'll keep recommending Tubesock! [0] https://github.com/ngauthier/tubesock https://github.com/ngauthier/tubesock
makeitsuckless 11y ago
The almost complete dominance of the Rails in the Ruby ecosystem seems incredibly unhealthy to me. IMO, Rails should do what Rails is good at and was designed for (simple, monolithic, server-side heavy web applications), and there should be dozens of other successful Ruby frameworks with other philosophies. Rails was supposed to be the breakthrough for Ruby, but instead the near monopoly of Rails is suffocating it.
- yellowapple 11y ago
  It's especially jarring when the Ruby world - which originally revolved around "Matz is nice so we are nice", emphasizing developer happiness, being a more readable Perl, etc. - now revolves around the "Rails way" as if all other ways are wrong. If I wanted a "There's Only One Way To Do It(TM)" world, I'd be programming in Python, not Ruby.
claudiug 11y ago
I never hear any production app with elixir in Berlin, some noise with clojure, but some people move from node.js to Golang. As for rails, people are happy. Sometines I think is super cool to rant rails :)
- rio517 11y ago
  As a ruby/js dev moving to Berlin in September, that's good to hear. I'm interested in talking to folks who might be more familiar with the scene there. If you know anyone who'd be good to reach out to, let me know!
  - claudiug 11y ago
    enroll here: http://berlin.onruby.de/ http://berlin.onruby.de/
dankohn1 11y ago
My last startup used Node.js + Angular + Postgres, which was great for supporting multiple single page applications and websockets. With my current startup (a healthcare marketplace where we have to support older browsers), we chose Rails as the best and most mature way to provide server-rendered pages. I think it's great to try to extend Rails to provide a credible websockets approach, but it will always be difficult because the biggest strength of Rails is the incredible ecosystem of gems. However, all of that existing code is written as blocking, rather than asynchronously like Node and some newer frameworks. Nevertheless, the Rails ecosystem remains a hotbed of innovation as well as a very warm and welcoming place for both new and experienced programmers. Rails has not been the new hotness since at least the time Node rolled around. But that's a long way from an existential crisis.
lifo 11y ago
As someone who's done the bulk of the work for Action Cable, I wanted to clear the confusion re: cable and eventmachine. Cable is currently using EventMachine because it uses faye-websocket for dealing with websockets. And Faye is one of the very few well maintained ruby library dealing with websockets. And in fact, Action Cable uses Celluloid threadpool to run all the application code in threads. So the model is a combination of EventMachine + Threads. There's absolutely no reason it can't use Threads + Celluloid all the way. But building on top of Faye was the simplest way to get things up and running.
- moe 11y ago
  As someone who's tried to use Faye and EventMachine (separately) back in the Ruby 1.9.3 days: Have they stabilized enough to be used for anything? My memory of them is rather horrible. Memory leaks, segmentation faults(!) and obscure deadlocks eventually made me scratch EventMachine from the list of things I'd ever want to touch again. And Faye, well, I don't think I even got it fully running at the time. I still re-call my astonishment when I realized that neither of their two different server-impls at the time would pass even most basic tests (e.g. browser connect/disconnect, redis start/stop) without crashing, locking up or losing messages. Admittedly it's been a while... Is anyone running Faye in production and can comment? Edit: Thanks for the feedback. I guess it's time to give Faye a second chance.
  - bshimmin 11y ago
    I've been using Faye quite happily for the last month or so and have been very pleased with it.
  - bradgessler 11y ago
    I wrote http://firehose.io/ http://firehose.io/ that runs on a separate fleet of servers to handle pub/sub that uses Faye. For the most part it runs without putting up a fuss. Lost messages aren't a concern because it's assumed the protocol won't handle lost or dropped messages, so Firehose messages have a sequence that counts up per channel that the client keeps track of.
  - 11y ago
redeemedfadi 11y ago
For those of you who would like to watch the keynote: https://www.youtube.com/watch?v=oMlX9i9Icno https://www.youtube.com/watch?v=oMlX9i9Icno
eranation 11y ago
The OP is talking about Elixir/Clojure as alternatives. I really liked Elixir's built in Actor like system, Ruby like syntax and the fact it runs on the Erlang VM is very interesting. I was always wondering why Ruby developers who looked for an alternative didn't move to Scala / Play ecosystem, Scala always seemed to me more like "typed Ruby" than a "better java" or "mediocre Haskell". But after skimming elixir's getting started docs, I think I know why. Elixir seems to have much more "Ruby like" syntax, it's not running on the JVM, and it's dynamic. But still I wonder how much the Ruby / Rails community is aware of Scala / Play framework / Akka / Akka-http (formerly spary) as a possible comfortable alternatives to Ruby / Rails / Elixir's actor system / Ruby API? Play framework knowingly (and admittedly, giving all due credit) borrows a lot from Rails. and I am amazed how Ruby and Scala have more similarities than Scala and Java, yet people still link Scala with Java much more than with anything else. I think the Scala ecosystem will benefit a lot if there was even a small stream of Rails contributors that also do Scala on the side. I think what makes Rails and Ruby so great is the amazing community and open source culture behind it. As a Scala fan, I can't be but a little gelous...
briantakita 11y ago
I somehow got stuck upgrading from Rails 3 to Rails 4. Nightmare... I've been through 5 Rails upgrades. Rails 2 to Rails 3 was a nightmare... Rails does not scale well with complexity & is a pain to maintain... There are a number of reasons for that. Rails started off favoring syntactic sugar over architectural integrity. They are gradually iterating toward a solid architecture. However, that required some significant api changes, which causes upgrade pain. Also, the prevalence of monkey-patching (largely due to an unsound & overly complicated architecture), exasperated these issues. Rails architecture is still overly complicated & misses the mark, IMO. DHH's infamous "golden path" direction put the blame on the developers, when Rails itself had some major architectural flaws. Rails Routes + Controllers are horrible. Why do we want an extra level of indirection? Sinatra/Express.js are easier to reason about RESTfully. Asset Pipeline is horrible. The Node.js ecosystem (i.e. browserify) is much better. Client/Server separation of architecture scales in complexity more readily than the Rails monolith monstrosity. I'm kindof bummed that Rails became so big. The "Rails Way", while being a step forward from what was there before, became too prevalent; sucking up too much mindshare; inhibiting further evolution of the broader ecosystem. It's time we let Rails slowly die. There are many better libraries & frameworks out there.

206 points by railsbird 11y ago

Could this be formalized? Have odd releases as "feature" releases and even releases as Snow Leopard-style "consolidation" releases?

davidw 11y ago

No, Rails isn't great for web socket kinds of things, but if it were me, I'd just use something else for that, and Rails for the main site. It's still one of the best things out there for quickly iterating, and yet still maintaining some structure and discipline, from what I've seen.

axx 11y ago
Same here, i see it this way: use the right tool, for the right job. Sometimes it's Ruby/Rails, sometimes it's Node, somtimes it's something else.
railsbird 11y ago
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.
- brodock 11y ago
  I'm pretty sure "ActionCable" will be optional, as for example "ActiveResource" were
knes 11y ago
You could also use hosted solutions such as Pusher, Pubnub or Fanout which plays really well with frameworks
serve_yay 11y ago
> No, Rails isn't great for web socket kinds of things You're doing the "best tool for the job" thing. But if Rails is not a good tool for the job of web socket programming... then ya kinda have to wonder why they're rolling a web socket thing into Rails core, no?
tonyarkles 11y ago
What I've done a few times in the past is had a Rails server for the main app, and a node-based socket.io server for the websockets. All the socket.io server does is listen to a redis server and emit events to the right listeners.

noelwelsh 11y ago

In web framework terms, Rails is old. When it was created single-page applications weren't on anyone's radar, APIs were extremely uncommon, and websockets hadn't been invented. It's natural to expect some pain try to adapt new paradigms into the old model. Whether this pain is worth it is up to the individual to decide. My web applications are almost always pure client-side these days, so Rails is not something I often turn to.

stephenson 11y ago
Re "In web framework terms, Rails is old" Oh how I love that! I would rather build my business on something old and well testet then something new and shiny.
- mgkimsal 11y ago
  would you move to java? that's older and even less shiny.
  - stephenson 11y ago
    I would, if the technology solved the problem, the workflow fitted our org, the cost of running it in production fitted our budget etc.
  - yellowapple 11y ago
    Or PHP. Or Perl. Or COBOL.
- symfoniq 11y ago
  This. We didn't feel comfortable moving my company to Rails until it hit version 3. Maturity is a good thing.
- LunaSea 11y ago
  http://www.cvedetails.com/vendor/12043/Rubyonrails.html http://www.cvedetails.com/vendor/12043/Rubyonrails.html "well tested"

hopeless 11y ago

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't know until some ActionCable code is released but it sure didn't look complicated. It does seem odd that -api takes years to get in, but ActionCable gets a go-straight-to-core pass without any community review first. It certainly seems like a weakness in the process, which should be addressed, although I'd agree with the eventual result & priorities. -api probably isn't something I'd ever use: even if I eventually created an API-only app, I'd probably have started from a regular Rails app and gradually optimised things out. Edited to add: I'm actually quite bullish on TurboLinks 3 if it can help me to avoid ever having to write a Javascript MVC app again. It's not so much that these apps are hard to write, it's that they're freaking hard to debug, particularly in the hands of users.

erichmond 11y ago
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.
- matthewmacleod 11y ago
  Interestingly, we had a couple of Clojure experiments. Takeaway was that there were some benefits in terms of performance and maintenance, but they weren't worth the tradeoff in expressivity and increased developer time. There's no reason that Rails should be restricted to 'monorail' or monolithic apps. We've had great success writing what are essentially microservices in Rails. Code is easy to read, easy to maintain, and performs well. It's hard to find any compelling reason to use another toolset under those circumstances!

jameskilton 11y ago

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://elixir-lang.org/ http://www.phoenixframework.org/ http://www.phoenixframework.org/

jazzyb 11y ago
Interestingly, Elixir was created by one of the Rails Core developers mentioned in the article: Jose Valim.
jimiray 11y ago
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.
pmontra 11y ago
I used Phoenix for a small project last September, not much more than a toy but anyway... Pros: websocket support is good, the developers are friendly and answer questions, the app is faster than what I'm used to with Rails. Neutral: Elixir looks like Ruby but it's very different. Be prepared to learn everything from scratch. You need also to know a little Erlang and the OTP framework to be able to use some useful library functions. OTP is a world on its own. Cons: the tooling is very immature, probably like the one for Rails at the time of the 1.x releases. Be prepared to write many things by hand instead of requiring gem_x and automagically get functionality for free. This is going to slow down developement, increase costs and possibly get you outbid from competitors. Nevertheless it could be OK for internal projects used to get familiar with the framework.
- chrismccord 11y ago
  We've come a long way since September, so please check again. I am outlining our 1.0 remaining milestones Friday at ElixirConfEU. We should see 1.0 in a few months
vezzy-fnord 11y ago

mundanevoice 11y ago

Forget rails. Move to Django ;)

davidw 11y ago
Django has basically the same architecture as Rails, so it's really in the same boat from that point of view.
- federico3 11y ago
  Minus the security issues.
  - biokoda 11y ago
    And equally bad at concurrency.
    - mpdehaan2 11y ago
      I don't buy this, having written and dealt with a lot of concurrent Django apps - I think people read something about the GIL often, and don't understand what the articles are really meaning. Basically Django is usually fronted with mod_wsgi and you use celery for backend tasks. The multiple requests part are dealt with because the web server pre-forks, and it's just fine with it. I think Django's problem is it moves very slowly, and mostly just that. The ORM isn't awesome, but it's workable. You can also choose to not use parts of it, like templates, and that's common in single-page apps.
      - wldcordeiro 11y ago
        It's speeding up development lately, 1.8 came out rather fast but it seems like the Django team likes to have ~1 year development cycle.
        mundanevoice 11y ago

Kiro 11y ago

> as developers flock to new technologies like Clojure and Elixir Is that really the case? Clojure and Elixir?

GnwbZHiU 11y ago
I know people who move from Ruby/Rails to Golang. No people I know move from Ruby/Rails to Clojure and Elixir
- railsbird 11y ago
  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.
  - claudiug 11y ago
    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 :)

railsbadruby 11y ago

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.

davidw 11y ago
You do know that José Valim is both the developer of Elixir and a Rails core guy, right?
pjonesdotca 11y ago
I love it when debate gets reduced to someone creating a troll account ( 'railsbadruby' account is 48 min old as I write this ) and badmouthing. Is this what HN discourse has come to?

otterley 11y ago

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.

rakoo 11y ago
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 ?
- otterley 11y ago
  If you could run Rails in an event-driven webserver, it might be usable with persistent connections. Otherwise you'll need a whole lotta memory for all those workers that'll be sitting around doing nothing most of the time.
  - brodock 11y ago
    in other words: "unicorns considered harmful"

tinco 11y ago

> Unfortunately, we don’t have better options in Ruby for working with websockets. We do! Celluloid (the actor model) is vastly superior to EventMachine in my opinion. It fits much better to Ruby's OOP style and I suspect would integrate into Rails very cleanly. I am positive that bringing any EventMachine technology into the Rails stack would be a mistake. I am saying that with a bit of a bias as I have written my own celluloid-websocket[0] gem that comes with a Rack adapter. But I wrote it because I put a project using EventMachine websockets into production and was not happy with it. Now in a new project I can just hook up the celluloid-websockets Rack app and run it using `passenger start` or any of the Rack application servers. Even though so many people seem to flock to Node.JS for these kinds of servers, the fact that as a language Ruby is superior to Javascript remains, even if Javascript VMs are a hundred times as fast. As long as Node.JS is run on standards compliant VM's things like promises are just lipstick on the callback hell pig. You can write clean and understandable Ruby to solve any problem, including Websocket servers. We as the Ruby community were just late to the asynchronous I/O party. Now Celluloid is production ready, there's really no reason (except for performance of course) for a Ruby developer to write Javascript on the server side. (sorry for my extreme opinions, if you want a more nuanced deliberation on a point just ask ;)) 0] https://rubygems.org/gems/celluloid-websocket https://rubygems.org/gems/celluloid-websocket

railsbird 11y ago
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.
onli 11y ago
Do you have experience with https://github.com/ngauthier/tubesock https://github.com/ngauthier/tubesock? In a very small project of mine I used https://github.com/minoritea/sinatra-hijacker https://github.com/minoritea/sinatra-hijacker which I found very nice to program with.
wilmoore 11y ago
>> the fact that as a language Ruby is superior to Javascript remains, even if Javascript VMs are a hundred times as fast. As someone who frequently switches between Ruby/Rails and NodeJS (sometimes in the same day), I wonder about this statement (err, fact). You mentioned that the Ruby language is superior and that this is a "fact". What about the Ruby (I know Node isn't really a language, but for the sake of discussion, Node,JS,npm) is substantially better that the speed trade-off is worth it (besides familiarity)? In my case, I'm familiar with both, and I prefer Node,JS,npm. Node,JS,npm are definitely not perfect, yet still, I like it over Rails,Ruby,Gems/Bundler. I'm not looking to "win" here; I'm just very curious now given your assertion.

dham 11y ago

After trying Clojure(and Luminus) several times over the past year I don't think it would be my go to for things that Rails is tackling. On a side note writing Clojure gave me a little anxiety so I'm trying to hold back on it for now. After working in this stuff for a while I just use the right tool for the right job. Most of the time Rails is that tool and it allows you to just get stuff done. Sometimes Node is the right tool, or Python. I think the new Turbolinks stuff is pretty interesting(and useful) although it doesn't help me with forms, and that's the thing I'm usually using React or Angular for these days. Angular may get crap but it's actually really good at forms.

brodock 11y ago
I believe the right balance with turbolinks is a mix of React for interactive animated stuffs, graphs, etc, and turbolinks to render stuff that is better generated server side, or to push json data (and then bind it to your react component)

artursapek 11y ago

People use Rails to build websocket hubs?

t4nkd 11y ago

Is this just a really polite, introspective take on (Rails|Ruby) is a Ghetto? I can't point out one really valid critique in this entire rant. While I imagine that you've had enough kool-aid to actually believe the things you said, I think you should probably do a few google searches to find out how many shops are hiring Rails devs versus Clojure or Elixir. You can do more experimenting by seeing who else is actually working those jobs, what kind of professional experience they have, and if you're really lucky figure out what they get paid. Rails needs websockets, just like years ago when it needed a better way to handle organizing and deploying assets. The modern application demands it, and if you've ever had the pleasure of trying to build a websocket application in Ruby you'd understand why it's actually really exciting that we're going to get the Rails community to build this for all of us. If you want to be disenchanted about some aspect of Rails then pick the fact that the need for diversity at RailsConf this year has yielded some of the worst presentations I've ever seen (like, literally, the presenter spoke poor/broken english and the Docker oriented talks were about 6 months behind). Rails moves the way it does and absorbs the ideas it does because they become popular. It's much easier to add a feature that everyone wants, instead of inventing a feature that makes a solved problem that much easier/faster/what-have-you. DHH seems to have to explain this every few years, but go back in time when Rails adopted sprockets and you'll see posts not unlike the one you just wrote. Realistically, Ruby and Rails jobs are still among the highest paying in the industry. Startups and other more established companies still choose Rails as their platform, and not just for bullshit brochure sites. Certainly there remains a "best tool for the job" mentality but, right now, the alternatives are to: build it yourself, hop on a less "mature" framework -- Pheonix? I don't even know what you pick when you adopt Elixir as your platform language and need to build an API or front end apps but Pheonix won the google -- or choose from one of the popular technologies like Express.js, Laravel(?), or Django. That part of building technology (and business) didn't change, and there are still hundreds of thousands of Ruby and Rails engineers out there.

kailuowang 11y ago
> the alternatives are The main competitive alternatives to Rails are single page application frontend frameworks combined with light API focused backend frameworks. Not a single web application framework.

deedubaya 11y ago

The Rails team, including DHH, owes us nothing. They aren't required to give us a framework of our choosing, they're the ones building it! Just like we don't owe anything to Rails! DHH uses Rails for Basecamp, so it makes sense that he'll lead the project towards the goals of BC.

ksec 11y ago

To those unsure about Eventmachine https://github.com/eventmachine/eventmachine/blob/master/CHANGELOG.md https://github.com/eventmachine/eventmachine/blob/master/CHA... IT seems to have much more fix and features in recent months then its entire life span. And as DHH pointed out on twitter Clearing up misconception re: Action Cable: EventMachine only used for connection handling, threads for channel code. No block restrictions.

matthewmacleod 11y ago

I understand that there's not quite the same consistent 'theme' this year, but I'm not sure that's concordant with developers who are using Rails 'abandoning' it or anything like that. It's true that real-time operations like websockets are a total pain in the arse with Rails. Nobody's yet figured out an optimal solution for that sort of thing, and maybe ActionCable is a good solution. The thing is that while some demands on the web stack have changed, a lot of it is still pretty similar. We have HTTP requests, and HTML, and assets, and databases. It might turn out that Rails can also perform some other tasks that require realtime operation. Or maybe it won't be able to, and we'll be able to use some other tools. Ultimately, we're still using Rails for all of our new web apps. We've tried loads of different toolsets, but haven't found an alternative that's compelling enough to bother. So YMMV, but the fact that Rails is maybe a bit less exciting that newer frameworks doesn't mean it's not great to use any more.

PaulHoule 11y ago

I also see Basecamp as having jumped the shark. Highrise was a palatable "cheap and cheerful" CRM system but they decided to stop investing in it. The appeal of Basecamp is that it is a simple product and there isn't anything 40 developers can do to make it more simple.

alexggordon 11y ago

A slight tangent, but as a lover of rails and a user of websockets, I can't recommend Tubesock[0] highly enough. I think regardless of your opinion on event machine, Tubesock is a better engineering match for rails, than websocket-rails. Hopefully, the websocket support will be a standard in the future, as opposed to an afterthought for rails, but until that point, I'll keep recommending Tubesock! [0] https://github.com/ngauthier/tubesock https://github.com/ngauthier/tubesock

makeitsuckless 11y ago

The almost complete dominance of the Rails in the Ruby ecosystem seems incredibly unhealthy to me. IMO, Rails should do what Rails is good at and was designed for (simple, monolithic, server-side heavy web applications), and there should be dozens of other successful Ruby frameworks with other philosophies. Rails was supposed to be the breakthrough for Ruby, but instead the near monopoly of Rails is suffocating it.

yellowapple 11y ago
It's especially jarring when the Ruby world - which originally revolved around "Matz is nice so we are nice", emphasizing developer happiness, being a more readable Perl, etc. - now revolves around the "Rails way" as if all other ways are wrong. If I wanted a "There's Only One Way To Do It(TM)" world, I'd be programming in Python, not Ruby.

claudiug 11y ago

I never hear any production app with elixir in Berlin, some noise with clojure, but some people move from node.js to Golang. As for rails, people are happy. Sometines I think is super cool to rant rails :)

rio517 11y ago
As a ruby/js dev moving to Berlin in September, that's good to hear. I'm interested in talking to folks who might be more familiar with the scene there. If you know anyone who'd be good to reach out to, let me know!
- claudiug 11y ago
  enroll here: http://berlin.onruby.de/ http://berlin.onruby.de/

dankohn1 11y ago

My last startup used Node.js + Angular + Postgres, which was great for supporting multiple single page applications and websockets. With my current startup (a healthcare marketplace where we have to support older browsers), we chose Rails as the best and most mature way to provide server-rendered pages. I think it's great to try to extend Rails to provide a credible websockets approach, but it will always be difficult because the biggest strength of Rails is the incredible ecosystem of gems. However, all of that existing code is written as blocking, rather than asynchronously like Node and some newer frameworks. Nevertheless, the Rails ecosystem remains a hotbed of innovation as well as a very warm and welcoming place for both new and experienced programmers. Rails has not been the new hotness since at least the time Node rolled around. But that's a long way from an existential crisis.

lifo 11y ago

As someone who's done the bulk of the work for Action Cable, I wanted to clear the confusion re: cable and eventmachine. Cable is currently using EventMachine because it uses faye-websocket for dealing with websockets. And Faye is one of the very few well maintained ruby library dealing with websockets. And in fact, Action Cable uses Celluloid threadpool to run all the application code in threads. So the model is a combination of EventMachine + Threads. There's absolutely no reason it can't use Threads + Celluloid all the way. But building on top of Faye was the simplest way to get things up and running.

moe 11y ago
As someone who's tried to use Faye and EventMachine (separately) back in the Ruby 1.9.3 days: Have they stabilized enough to be used for anything? My memory of them is rather horrible. Memory leaks, segmentation faults(!) and obscure deadlocks eventually made me scratch EventMachine from the list of things I'd ever want to touch again. And Faye, well, I don't think I even got it fully running at the time. I still re-call my astonishment when I realized that neither of their two different server-impls at the time would pass even most basic tests (e.g. browser connect/disconnect, redis start/stop) without crashing, locking up or losing messages. Admittedly it's been a while... Is anyone running Faye in production and can comment? Edit: Thanks for the feedback. I guess it's time to give Faye a second chance.
- bshimmin 11y ago
  I've been using Faye quite happily for the last month or so and have been very pleased with it.
- bradgessler 11y ago
  I wrote http://firehose.io/ http://firehose.io/ that runs on a separate fleet of servers to handle pub/sub that uses Faye. For the most part it runs without putting up a fuss. Lost messages aren't a concern because it's assumed the protocol won't handle lost or dropped messages, so Firehose messages have a sequence that counts up per channel that the client keeps track of.
- 11y ago

redeemedfadi 11y ago

For those of you who would like to watch the keynote: https://www.youtube.com/watch?v=oMlX9i9Icno https://www.youtube.com/watch?v=oMlX9i9Icno

eranation 11y ago

The OP is talking about Elixir/Clojure as alternatives. I really liked Elixir's built in Actor like system, Ruby like syntax and the fact it runs on the Erlang VM is very interesting. I was always wondering why Ruby developers who looked for an alternative didn't move to Scala / Play ecosystem, Scala always seemed to me more like "typed Ruby" than a "better java" or "mediocre Haskell". But after skimming elixir's getting started docs, I think I know why. Elixir seems to have much more "Ruby like" syntax, it's not running on the JVM, and it's dynamic. But still I wonder how much the Ruby / Rails community is aware of Scala / Play framework / Akka / Akka-http (formerly spary) as a possible comfortable alternatives to Ruby / Rails / Elixir's actor system / Ruby API? Play framework knowingly (and admittedly, giving all due credit) borrows a lot from Rails. and I am amazed how Ruby and Scala have more similarities than Scala and Java, yet people still link Scala with Java much more than with anything else. I think the Scala ecosystem will benefit a lot if there was even a small stream of Rails contributors that also do Scala on the side. I think what makes Rails and Ruby so great is the amazing community and open source culture behind it. As a Scala fan, I can't be but a little gelous...

briantakita 11y ago

I somehow got stuck upgrading from Rails 3 to Rails 4. Nightmare... I've been through 5 Rails upgrades. Rails 2 to Rails 3 was a nightmare... Rails does not scale well with complexity & is a pain to maintain... There are a number of reasons for that. Rails started off favoring syntactic sugar over architectural integrity. They are gradually iterating toward a solid architecture. However, that required some significant api changes, which causes upgrade pain. Also, the prevalence of monkey-patching (largely due to an unsound & overly complicated architecture), exasperated these issues. Rails architecture is still overly complicated & misses the mark, IMO. DHH's infamous "golden path" direction put the blame on the developers, when Rails itself had some major architectural flaws. Rails Routes + Controllers are horrible. Why do we want an extra level of indirection? Sinatra/Express.js are easier to reason about RESTfully. Asset Pipeline is horrible. The Node.js ecosystem (i.e. browserify) is much better. Client/Server separation of architecture scales in complexity more readily than the Rails monolith monstrosity. I'm kindof bummed that Rails became so big. The "Rails Way", while being a step forward from what was there before, became too prevalent; sucking up too much mindshare; inhibiting further evolution of the broader ecosystem. It's time we let Rails slowly die. There are many better libraries & frameworks out there.