Yawn. Yet another misinformed "Ruby/Rails can't scale" article.
Seems to me the main problem is that his "MIT trained" friend had no experience building a scalable web service. He would've botched it up in PHP, Python, Java, whatever. There's nothing about his main mistakes- running your database on a shared server, naive (ab)use of SQL- that is unique to Rails.
And this bit: "pull entire tables into Ruby, the most beautiful computer language ever designed, and filter down to the desired rows using Ruby and its “ActiveRecord” facility" is completely incorrect and makes it obvious Philip Greenspun knows less than nothing about what he's ranting about.
If this wasn't a RoR hatchet job, why put it in the title and sprinkle sarcastic jabs all over the article?
Regarding his recommendation at the end, if someone suggested a server with 32GB of memory to run a site that has "About one user every 10 minutes", I would think "damn, this doesn't scale" :)
It was in the title because many of the snooty programmers who think they're so much smarter than the .NET guys, and who go off and build overly-complicated things that don't work just for the sake of building something complicated, are in love with Ruby on Rails. It doesn't attack RoR so much as a subset of the RoR community.
It pretty much abstains from the topic of RoR as a language and framework.
well it would be bad advice for the programmer to simply throw away all of his work at that moment and start from scratch - regardless of what you think of the technology he used
I don't think it was implied at all, especially since he recommended using it at the end. It's implied only if you read the title and nothing more.
What was both implied and directly stated was that a cloud-based architecture is often not the best idea for a lot of people, despite the modern mania for it.
Phil specifically addresses the idea that he is dissing RoR in a comment.(emphasis mine)
"Angry Rails Enthusiasts Whose Comments I Deleted: A lot of the comments were of the form “Your assertion that it is impossible to build a responsive Web site with Ruby on Rails is wrong. Rails is in fact great if programmed by a great mind like my own.”
The problem with this kind of comment is that I never asserted that Ruby on Rails could not be used effectively by some programmers.
The point of the story was to show that the MIT-trained programmer with 20 years experience and an enthusiasm for the latest and greatest ended up building something that underperformed something put together by people without official CS training who apparently invested zero time in exploring optimal tools.
Could some team of Rails experts have done a better job with mitgenius.com? Obviously they could have! But in the 2+ years that our MIT graduate worked on this site, he apparently did not converge on an acceptable solution.
My enthusiasm for this story has nothing to do with bashing Ruby or Rails. I like this story because (1) it shows the fallacy of credentialism; a undergrad degree in CS is proof of nothing except that someone sat in a chair for four years (see http://blogs.law.harvard.edu/philg/2007/08/23/improving-unde... for my thoughts on how we could change the situation), (2) it shows what happens when a programmer thinks that he is so smart he doesn’t need to draft design documents and have them reviewed by others before proceeding (presumably another set of eyes would have noticed the mismatch between data set size and RAM), (3) it shows that fancy new tools cannot substitute for skimping on 200-year-old engineering practices and 40-year-old database programming practices, and (4) it shows the continued unwillingness of experienced procedural language programmers to learn SQL and a modicum of RDBMS design and administration, despite the fact that the RDBMS has been at the heart of many of society’s most important IT systems for at least two decades."
That is exactly what I understood from the article.
I don't see any rails bashing in the original article and you would have to cherry pick phrases to get that idea. I read the HN comments first and thought phil had gone off on a rant against RoR t judge from some comments here.
that will teach me to read HN comments before reading the original article!
It doesn't show any of that because it's all made up. He just slapped together a story that would appeal to someone like you based on your preconceptions, but there is no actual argument. The whole thing could be reduced to "idiots can't write software" and it would lose no substance.
Even some of these points that are supposed common sense engineering wisdom are specious. Do you need to draft design documents to build a workable product? Of course not! Is the first thing you should do when you start a new website to buy $20k worth of hardware? No! Do you need enough RAM to hold your entire database? Maybe it's the best optimization you can do, but it's far from a foregone conclusion.
Why I am I so vitriolic? Because the article is not truthy. The quote above says "MIT-trained" in the same sentence as "without official CS training." Uh, it doesn't get much more official than MIT. Suggesting that a programmer with 20 years experience couldn't get a single web page to load faster than 5 minutes is a flight of fancy plain and simple.
I might as well write a long-winded story about how Microsoft hired a Chimpanzee to program the next version of Word, and failed, therefore mammals make terrible programmers and furthermore decided to use C based on ill-informed simian whimsy.
I think he only reason it's still in there at the end is just so the site doesn't have to be rewritten. He's just changing the hardware to something beefier instead of optimizing it.
It's sad that rails, by default though it may not be the case anymore, makes n+c requests to the database when you load a page that lists n objects. It can be fixed in one line of code per page.
Well actually that's not true. You use the best tools for the job. Front end can be done in PHP/Ruby/Django quickly while the entire back-end can be written in java or lisp. It all depends on what you need and what is the fastest, most scalable way to accomplish it.
That is true intelligence.
In my eyes Good and Trendy vs Good and Not Trendy is irrelevant. They are both good, so solve the problem.
Oh and "rails does not prove your smarts" should be:
"Using technology X does not prove your smarts." because there will always be another X. Today its Rails, tomorrow its Open Sails, and the day after we all go back to Lisp.
pull entire tables into Ruby, the most beautiful computer language ever designed
I read that as sarcasm. He is a Lisper, after all. I think his point is that he does know less than nothing, but he still came up with a solution, at least for the time being.
I recall having an email conversation with him about PHP vs his TCL home grown stack years ago. His response said only amateurs would use PHP (Are Facebook and Yahoo amateurs?).
Anyway I use Rails now and he long ago lost my respect for being too narcissistic and closed minded.
He might be out of touch with the gadget side of web applications (can phillg make rounded corners with Processing.js or Raphael.js or Shoooes? I don't think so.) but his server architect credentials are untouchable. The fucker started a social networking site for photographers in 1993. He taught web application development at MIT and the book he coauthored is still used today.
And if you think there is anything "modern" to scaling web applications, you would be wrong. When push comes to shove, everybody reaches out to their Unix system call manpages and pulls out 20+ year old profiling tools. It's the front-end that's sassy ;-)
I agree some tools never go away, but I hope you're not literally saying that no advances have been made in scaling techniques in the past decade or so.
Almost a decade ago I worked on a large scale site that ran on PHP3, MySQL 2 (before it had replication), and depended on a hardware load balancer. Today, between RoR, Memcached, Amazon AWS, etc. etc. I can build and scale out an app 10x faster and cheaper than I would've been able to a decade ago. (Hey, isn't this the fundamental rationale behind YC?)
Even ignoring new software, the availability of cheap memory and gigabet networking alone inform different architecture decisions than 1993.
Server performance hacks age the best out of all the performance optimization techniques I can think of. The same socket descriptor multiplexing tricks that were used to make news servers pump gigabytes of alt.binaries.* a day, in that age of "megabit networking", can be used today to push html and a few pngs very comfortably. Why? because network capacity, memory size and processor speed are growing orders of magnitude faster than network service consumers are being created, making the old network performance hacks far more powerful today (solely focusing on human users here, though even software "users" can be tolerated with more intelligent "push" architectures allowing the server to deliver content to its subscribers at its earliest convenient time.)
Also, changes in kernel architectures and the addition of fast and faster system calls only makes it better, but not different.
Unix (mostly BSD) ftp servers were at some point in the not-so-distant history the only places to get software; Simtel.net run on ONE server with no load balancing. Email? anon.benet.fi scaled really well. Not to long ago, single Unix servers were household names and their admins and systems hackers were Gods.
Yeah, okay, but this article should be titled "Virtualization and the importance of being stupid"
This has next to nothing to do with Ruby or Rails. He's right on the count that you should go with the options that work, but the key lesson here isn't that mongrels don't work, it's that shared hosting sucks for their purposes.
Also, ActiveRecord isn't a replacement for SQL. It is a convenience layer on top of SQL. I love my ORMs (and i've enthusiastically moved to DataMapper), but guess what i was doing today? Yep, that's right, i was writing SQL :P
When anyone says "XYZ technology can't ABC" it's usually not a fault of XYZ technology but a lack of that anyone's understanding of the technology. Ruby can scale. Java can be fast and Microsoft can be secure.
It's external vs internal motivation. In the first case, it's the world's fault if it doesn't work. In the second, it's due to a lack of understanding of how the world works.
Seems to me the main problem is that his "MIT trained" friend had no experience building a scalable web service. He would've botched it up in PHP, Python, Java, whatever. There's nothing about his main mistakes- running your database on a shared server, naive (ab)use of SQL- that is unique to Rails.
And this bit: "pull entire tables into Ruby, the most beautiful computer language ever designed, and filter down to the desired rows using Ruby and its “ActiveRecord” facility" is completely incorrect and makes it obvious Philip Greenspun knows less than nothing about what he's ranting about.