Live data from Hacker News

Why critics of Rails have it all wrong (and Ruby's bright multicore future)

unlimitednovelty.com

71–80 of 127 posts

Re: Why critics of Rails have it all wrong (and Ruby's bright multicore future)

#71

To pour a little cool water on this bombastic post -- I have much love and respect for Rails. We (NYT Interactive News) continue to use it for nearly everything we build that requires a server-side component. All I was trying to say (in a direct reply to Jeff) was that I think that putting Rails on hold for 2-3 years while merging in Merb (or the Merb team, depending on how you want to look at it) wasn't, in retrospe…

Jeremy, I think you know better, but you find this argument too convenient to give up. We did not "put Rails on hold". You could just look at the commit logs, but let me be more explicit.

* December 23, 2008: Merge announced

* March 15, 2009: Rails 2.3 released

* June 25, 2009: Rails XSS protection plugin for Rails 2.3 is released

* July 20, 2009: Rails 2.3.3 is released

* July 29, 2009: The first version of bundler (0.3.0) is released

* February 3, 2010: Bundler 0.9.0, the first "modern" version of Bundler, is released with support for Rails 2.3.5

* February 4, 2010: The first Rails 3.0 beta is released

* May 22, 2010: Rails 2.3.6 is released

* June 8, 2010: The first beta of Bunder 1.0 is released

* July 26, 2010: The first Rails 3.0 RC is released

* August 29, 2010: Bundler 1.0 is released

* August 29, 2010: The first Rails 3.0 final is released

As you can see, activity in Rails hardly ground to a halt during the time period we were working on Rails 3. We didn't even ship Rails 2.3 until three months after the merge, and continued active development for some time thereafter. And during this time, we backported two major new Rails 3 features, Bundler and Rails XSS, to Rails 2.3, actively releasing new versions of Rails 2.3 to take advantage of these backports.

Further, Rails 3 itself was a MAJOR feature release. Saying that Rails was "put on hold" for 2-3 (?!) years to merge in the Merb team is like claiming that Obama is going on an international apology tour. See below for a summarized list of important features.

I won't even talk about the improvements in Rails 3.1 or 3.2, which were possible because of the firmer footing we put the entire project as part of Rails 3 development. And this analysis doesn't even cover the major ways that the project structure changed during that time (full embrace of GitHub, significant increase in long-term contributors, acceleration of the guides project and other improvements to documentation).

---

Rails 2.3 was a major Rails release, with the following features:

* Completion of the Rack integration work begun earlier in the Rails 2.3 series

* Full integration of the Engines feature that was first softly integrated in Rails 2.2

* Localized views

* Support for public HTTP caching

* Ruby 1.9 support

* Nested Attributes (in both ActiveRecord and ActionView)

* Nested Transactions, even in MySQL

* A whole slew of other significant ActiveRecord improvements (http://guides.rubyonrails.org/2_3_release_notes.html#active-...)

* Unified rendering (render :foo, render "foo", etc.)

* HTTP Digest Auth

* Various performance improvements

* Rails application templates

* A whole lot else, see http://guides.rubyonrails.org/2_3_release_notes.html

---

Rails 3.0.0 was a major Rails release. Here are a few of the important features, but summarizing them all would be difficult:

* Incorporated direct support for Bundler, and drove the initial Bundler feature-set.

* Many architectural improvements, which drove improved, more stable third-party libraries in the Rails 3.x era (http://guides.rubyonrails.org/3_0_release_notes.html#rails-a...)

* A much bigger emphasis on eating our dog food: Rails 3 internals use exposed public APIs that any third-party extension can use. In fact, ActiveRecord itself is built as an extension!

* TMail, used by Rails 2.3, was unmaintained and extremely buggy (it often crashed when reading mail). The `mail` gem, written from Rails 3, is a ground-up rewrite.

* The ActiveRecord query interface is a night-and-day difference from the Rails 2.3 query interface. Users of ActiveRecord can now mix and match query parts (where clauses, group, order, limit) without having to worry about how to describe everything in terms of a single hash. This is probably the biggest change to the way developers use a major Rails component since the embrace of REST in Rails 1.2.

* ActionMailer finally got the update it needed. By Rails 2.3, ActionMailer had become a red-headed stepchild, sharing many features of the mainline render system on an ad-hoc basis. That meant inconsistencies galore. In Rails 3.0, ActionMailer got updated to share code and interface with ActionController, locking the two together to avoid another redheaded stepchild problem.

* Large improvements to Internationalization.

* ActiveModel makes it possible to use parts of ActiveRecord without using its SQL persistence layer. Apps have used this to spruce up plain Ruby objects, and libraries like Mongoid have used this to make alternate persistence libraries feel like the ActiveRecord people know and love.

* The router was completely rewritten, adding commonly requested features like the ability to match on any element of the request (commonly used for subdomain matching) and optional segments.

* The new ActiveRecord, ActionMailer and Router APIs maintained backwards compatibility with the older APIs until Rails 3.1 or 3.2, making upgrading plausible for more people.

---

Rails 2.3.3 was a minor update, with the following features:

* `touch` in ActiveRecord, to update a record's timestamp manually or automatically when associated records change

* Improved support for legacy schemas in ActiveRecord

* A general-purpose JSON encoding API and support for the `json` and `yajl` backends

* Other features: http://weblog.rubyonrails.org/2009/7/20/rails-2-3-3-touching...

Rails 2.3.6 through 2.3.9 (The Bridge to 3.0) was a significant update, with the following features:

* Direct support for the Rails XSS plugin

* Support for permanent and signed cookies

* Support for table-name-prefixes for all ActiveRecord classes in a module

* Lots of 3.0 ActiveSupport backports and improvements

* Improved support for Ruby 1.9

* See more at http://weblog.rubyonrails.org/2010/5/22/ruby-on-rails-2-3-6-...

Re: Why critics of Rails have it all wrong (and Ruby's bright multicore future)

#72

To pour a little cool water on this bombastic post -- I have much love and respect for Rails. We (NYT Interactive News) continue to use it for nearly everything we build that requires a server-side component. All I was trying to say (in a direct reply to Jeff) was that I think that putting Rails on hold for 2-3 years while merging in Merb (or the Merb team, depending on how you want to look at it) wasn't, in retrospe…

I may be wrong but I can't help seeing a little anti-Katz bias there.

Beyond this 'cheap' psychological interpretation, I think the merb merge was mainly paying the huge technical debt 'young rails' contracted in its fast growth.

Rails 3 set the ground for the future. All big project go through this teenage phase, and if Rails 4 has so much potential today is because the 'alias_method_chain' and other quick hacks were cleaned out with well thought architectural principals - even though rack and streaming don't play well...

Oh god and I haven't read the whole post yet...

Re: Why critics of Rails have it all wrong (and Ruby's bright multicore future)

#73
post #62
post #61

(I'm a full time Ruby/Rails programmer, and I have been for five years.) There's a major flaw in the R/R culture: they have no interest in maintaining stable APIs. If you want to upgrade your Rails app to the latest version of some library, you might as well do a rewrite of your entire app. So many of the APIs change from release to release that most of your gems will stop working unless you upgrade. When you upgrade…

and by the way, I can't recommend Node either. As far as I can tell, they're eagerly making these same mistakes.

Node is no panacea, but that's not quite true about stable APIs. npm is great about maintaining separately versioned libraries and reducing conflicts.

In your package.json can specify what version of a library to use and npm mostly figures it out for you. For instance, I'm still intentionally using an older version of Express (2.5.9 instead of 3.0.x) and npm hasn't had a problem figuring out deps.

Part of the reason this works is that the npms you install are kept in the local folder, not stored globally as many other package managers do, so some other random app on you box won't trample your delicate library configuration.

Re: Why critics of Rails have it all wrong (and Ruby's bright multicore future)

#74
I read this article a few weeks ago as a result of Tony writing "debunking the Node.js gish gallop" in response to my "Rails, Node, and the web apps of today" blog post.

I have a response coming in the next week/2 weeks, so I won't go into much here, but I will say that Tony's efforts to defend Rails are admirable; despite some snarkiness and elements of being reactionary, he raises good points in his posts.

One quick question. Tony, what are your thoughts on Elixir?

Re: Why critics of Rails have it all wrong (and Ruby's bright multicore future)

#75
post #20

Earlier quoted context omitted.

"Rails" is a collection of libraries and conventions, just as "Sinatra + ActiveRecord" is. There's nothing inherent in it that makes it "worse" than Sinatra (which I love, by the way) for JSON APIs. Use Rack, pick your favorite gems, and go to town. Why mess with all the other Sinatra junk when you can have a simple config.ru for your app and just write a simple call method and you're good to go? You don't need all t…

You cannot really compare Sinatra with Rails. Rails has scaffolding, DB migrations and all this ultra-highlevel stuff rendering debugging to pure guess-work. Reminds me of doing template-metaprogramming with C++. If it works it's great and the performance rocks, if not you are left alone with cryptic errors and nobody can help you.

If you want Sinatra with scaffolding there is Padrino which I personally find to have superior scaffolding compared to rails.

Re: Why critics of Rails have it all wrong (and Ruby's bright multicore future)

#76
post #73
post #62

Earlier quoted context omitted.

and by the way, I can't recommend Node either. As far as I can tell, they're eagerly making these same mistakes.

Node is no panacea, but that's not quite true about stable APIs. npm is great about maintaining separately versioned libraries and reducing conflicts. In your package.json can specify what version of a library to use and npm mostly figures it out for you. For instance, I'm still intentionally using an older version of Express (2.5.9 instead of 3.0.x) and npm hasn't had a problem figuring out deps. Part of the reason…

If you use ruby with bundler you get same behaviour. Something like bundler should have been built into rubygems in the first place.

Re: Why critics of Rails have it all wrong (and Ruby's bright multicore future)

#77
post #13

I agree a lot with this but it contains its own absolutely huge non-sequitur: How on earth is Cramp an example of damn simple websockets in Rails? It's Ruby, not Rails. It's also probably worth mentioning that it literally only works with Thin, is unmaintained, largely undocumented, and that the latest master on GitHub doesn't actually work. Not really the best example to pick!

Cramp is based on Rack, just like Rails... there is nothing stopping you from using the two in conjunction.

Re: Why critics of Rails have it all wrong (and Ruby's bright multicore future)

#78

Earlier quoted context omitted.

Yeah. Just read the top comment (as I write this): "You don't need all the ceremony and structure of Rails and MVC." I think the problem with this outlook is that you don't need it...until you, you know, need it. Rails has a lot of niceties that you lose with Sinatra. Why not start from a superlight Rails app (using any of the many gems or ActionController::Metal options) and then add on bits and pieces when you need…

For me personally it's because Rails is so fucking slow these days. That's it, I don't mind having all that structure and ceremony sitting there. It doesn't stop me from architecting things however I please in lib/ and app/models/. But when it takes seconds for a brand new app to run `rake -T` it forces me to look for speedier alternatives. Speed will probably be what ultimately pushes me off Ruby as my bread and but…

Do not blame ruby for the failings of rails.

Personally I have never had any problems with speed when developing large projects with Ramaze, Sinatra or Padrino. In my experience this only happens to Rails. No clue why though. Maybe some gems used by Rails take too long to load.

Re: Why critics of Rails have it all wrong (and Ruby's bright multicore future)

#79
post #45

Having developed software on both Rails and Django, I prefer the latter. Reasoning: python's community seems more professional. They have well-defined language change and enhancement processes (the PEP), good docs online, almost every question imaginable has been answered already somewhere, and the performance ain't too bad. Plus the code smell overall is just... lesser. Then again, I came from a background of C and…

Last I checked out Django they had just added a bunch of features from Rails 1.2. (Edit: sorry, Rails 2.1)

Python suffers from their web framework community being too fragmented, so none of the projects are as mature as Rails.

Re: Why critics of Rails have it all wrong (and Ruby's bright multicore future)

#80

I read this article a few weeks ago as a result of Tony writing "debunking the Node.js gish gallop" in response to my "Rails, Node, and the web apps of today" blog post. I have a response coming in the next week/2 weeks, so I won't go into much here, but I will say that Tony's efforts to defend Rails are admirable; despite some snarkiness and elements of being reactionary, he raises good points in his posts. One quic…

I'm friends with Jose and quit developing my language Reia because I thought Elixir was better. I've since gone on to develop Celluloid and haven't looked back ;)
Post reply on HN