Comment by jsjenkins168 | Hacker News Reader

Comment by jsjenkins168 | Hacker News Reader

If true, this is a pretty big blow to the viability of RoR as a large-scale platform, at least as it is right now.

I've always thought RoR's tight coupling with traditional SQL would be a serious scaling issue. RDBMSs in the traditional sense just dont scale easily. Google figured this out a while ago (hence BigTable). And RoR reads and writes soo much that you are left with a burden on the DB that might have been better mitigated by doing more of the processing client side and persisting with a simplified cloud-based service rather than a single, central RDBMS.

Not to stir up a hornets nest, but I really think this is a limitation of RoR that should be addressed in the future. Abstract out the SQL so other methods of persistence are possible.

EDIT: I am not trolling RoR. I am simply proposing that it might be better to be able to use it with something other than traditional SQL for persistence of data, so that traditional RDBMS can be replaced with a simplified cloud-based service such as SimpleDB.

I speculate this might be possible now using Ruby -> JRuby -> JPA -> SimpleJPA (or any other MySQL/SimpleDB wrapper) -> SimpleDB. I dont want to even get into how much work that would be though. It needs to be easier I think.

Startup idea maybe?

Rails, and the alternatives mentioned don't really make sense for a messaging application. You wouldn't write the back end for Gchat or AIM in Rails (or PHP, or Django), either. Rails would be fine as the web front end that talked to another messaging system. I've interviewed with the twitter guys and been to their talks and they definitely are NOT doing the right thing. However, "the right thing" is not easy and there are few people around and available who can do it.

edit: their best bet is to try to find someone who is burned out from working on wall street applications.

Just curious, what would you write the backend for AIM in? I don't have any experience developing messaging-type apps.

C.

Erlang is a fine option. So is C.

Dang - I was going to say Erlang. This is an ideal application for Erlang... scalability and uptime. There's a reason it's heritage is in the teleco industry.

I went and had a look at the slides for their 'scaling twitter' presentation, and it looks like they had a look at Erlang and reacted with some silly "ooh, it looks ugly" sort of comment. Seems pretty silly to reject something out of hand that is very much along the lines of what you need.

Java would work extremely well.

>Rails would be fine as the web front end that talked to another messaging system.

Which is exactly what they're doing:

http://rubyforge.org/projects/starling/

Twitter isn't a messaging application in the traditional sense (as in IM or phone networks) because it doesn't involve real-time synchronous communications. All communications in Twitter are asynchronous as in most database-backed webapps and I think it should be possible to scale Twitter with Rails assuming you know how to scale the database tier.

Having said that, it would still be fun to rewrite Twitter in Erlang... :)

Wall street types are used to working on serious hardware though (I am not a wall street person, but work for a fortune 500 type place).

One of our Oracle databases sits on a 24 core itanium box

That sort of hardware + Oracle can munch through some serious work - perhaps that is the database solution, but I believe it doesn't come cheap!

The scaling problems have little to do with rails. They admitted their problems were at the database level eons ago. I imagine "the switch" has more to do with the new chief architect switching to his favorite horse. Two whipping boys for the price of one: the old platform, and the old architect.

The new rewrite will give the new architect time to vest, until it fails, like big rewrites usually do. If you're not sure how to fix things, the big rewrite is a perfect solution, really.

I know rails itself is sound, my comments are directed more towards rails/DB integration. The database always seems to be the real bottleneck..

Since Ruby gives you such great flexibility, it wouldn't be that hard to hack things around a bit to redirect data requests to some other source.

I don't see that as the problem.

The rails DB integration lets you use the database directly whenever it suits you. At that point it's more a matter of arranging your data so that it lets you work around the key pain points. Since you can access the data directly when needed in rails, how will a new framework help if your problem is in the database?

Reply on news.ycombinator.com