This morning I read a post from Rob Conery about Ruby on Rails and I think that while many of his points are valid they can be applied to any technology or platform. It’s easy to fall in love with a technology and then when you find out it isn’t perfect there is some backlash, no framework/technology/person/company is perfect. I think all of the problems Rob talks about can be found in just about any technology or language.
First Rob brings up DHH. I would rather have one foul-mouthed opinionated dane than a corporation with a foul-mouthed litigious CEO at the top. Microsoft has plenty of incredible and awesome people working there like ScottGu, John Lam, or the new Phil Haack and Hanselman… but the rails community has plenty of great people as well. Look at Thomas Fuchs (committer), Tobia Lutke (committer), Andy Hunt, Chad Fowler, etc. And personally I would rather someone say “fuck you” than smile and nod while calling someone a Mort. One is at least straightforward and honest instead of condescending.
DHH might reject tons of community feedback, but I can submit a patch to Rails at any time. And while it might get rejected that is much better than what I can do with .NET which is to simple submit a form where it will most likely be rejected. I would guess that Microsoft probably rejects a higher percentage of community feedback than the rails team does.
The CDBaby example is flawed because it is more about the problems with doing an ambitious re-write with a new technology than about anything else. You could substitute different technologies and it would be completely believable. If you read his post most of the issues he has are about changing technology, not rails specifically. Look at the second to last sentence:
“Ok. All that being said, I’m looking forward to using Rails some day when I start a brand new project from scratch, with Rails in mind from the beginning.”
I think the Twitter performance is also a moot point. When you get to that level of traffic you are going to have to do some drastic things, you would have to do the same thing in .NET I am sure. I find it encouraging that it is so easy to re-write part of your ruby code in C to make it perform better, what do you think they do in the .NET framework? C extensions in Ruby aren’t that hard.
Lots of people got really excited about Rails and when they realized it isn’t perfect and isn’t going to single handedly solve all their problems there is going to be some backlash.
I have realized that nothing is perfect, but I enjoy writing applications in rails. So I am going to keep learning and embracing it, warts and all. The same way I have been using and embracing .NET (warts and all) for the last seven years (and for years to come I am sure).
-James
{ 10 comments }
Ruby is slow, I need to write an extension for it in C.
Great, now you have two problems.
C extensions in Ruby aren’t that hard.?… except you have to know C…
C extensions in .NET are not* required, you can’t even compare Ruby vs .NET in terms of performance
Eber,
I am not saying Rails is better than .NET in performance, it’s a trade-off. You trade-off some performance for productivity… but if there is a performance issue you can fix it with a little C.
Knowing a little C is easy, it’s not like they are rewriting the framework in C. You could always pay someone to write the 100 lines anyway.
That’s a great post, but if you take 2 teams, both working to capture the same market (1 RoR and 1 asp.net)…
It IS very likely that the rails team finishes first, captures the market, creates a huge user base that you will find difficult to convert…
Basically whoever gets there wins, provided your app doesn’t suck. Twitter is in a good place. They proved that they have a niche market that can be successful. Now they have to deal with there problems, and it doesn’t mean “rewrite it in php” because you’ll face similar issues.
Anyway back to our team. Google buys team 1 (ror) and the original guys retire in the south of France drinking wine and eating cheese.
And I’d also like to comment that it only takes 1 or 2 really smart people to write the critical sections of code in assembly or C for major projects, and everyone else can just benefit. Can’t write an algorithm in C?
Go back to school or hire someone who can.
The whole point of my post is that the Rails team is arrogantly ignoring the one major issue facing them: Ruby’s perf. There are many things they can do on this front, but instead say “it’s your problem”.
RE CD Baby – come on. It’s a commerce store front. Are you telling me that a 2-year rewrite, which amounted to nothing, is meaningless to you?
Finally – I love Rails, as I mention twice in my intro. I want to see it mature into the platform it should become without falling into ego wars.
Imagine if I told the SubSonic community “perf is your problem”. I’d be hung from the highest tree possible.
Ben,
I agree totally, that is why I am spending so much time learning rails.
Rob,
I agree with you that from a community perspective they would be better off paying more attention to the performance issues, but I really don’t think there is a performance issue for 99% of applications and so I think it’s being blown out of proportion.
CD Baby doesn’t surprise me because I see projects fail all the time, it is rarely a technology issue. Look at Twitter, it has all kinds of problems but is insanely successful.
I agree that there are some problems, and I would hate to see it turn into ego wars. But I don’t think those problems are much worse than any other technology.
One day I hope we are working on a rails app together.
@Rob,
It’s not Ruby’s performance. It’s Rails’ performance. It’s important to be clear about that. Ruby isn’t that fast, but it isn’t that slow either. The Ruby I write today is routinely faster than the c# I wrote in the past. First, not everything in Ruby is slower: Regexps are much much faster in Ruby, so parsing routines are much simpler/faster. Second, it’s much easier to change directions with a design in Ruby, and it’s those sorts of changes that give you orders of magnitude more performance. C extensions for more performance are 1 in a million situations.
@Eber,
100 lines of code is a very local optimization. You’re right about not falling back to C in .NET. Which means when you have a performance problem in .NET, it’s more than likely a fundamental design flaw and 100 lines of anything aren’t going to fix it. It’s much easier to re-mold a design into a performant image in Ruby, which is where all the big wins are anyways.
@Avery,
You aren’t the only one, so no offense.
But where is everyone getting the impression optimizing Twitter was easy? In the scaling Twitter presentation it certainly didn’t look easy. They threw out abstractions every step of the way and went with denormalization, and lots of custom SQL to the point of basically using ActiveRecord as a fancy version of ADO.
They ripped out RJS as well, but frankly I think people need to just learn JavaScript anyways, so serves ‘em right.
Oh, and everyone talks about shard-ing Twitter’s databases as a solution. That’s crazy-talk to me. 600rps is not enough to take on all the pain of splitting your database out into read-only slaves and a write-only master. It’s a nightmare! That people seem to accept that as a legitimate solution (that last I heard Twitter hadn’t actually implemented yet) is just… insane frankly.
No… it wasn’t easy, and it wasn’t right. It’s easy for me to arm-chair quarter-back, but it’s a pretty safe bet that projects like Merb and DataMapper could have let them keep 90% of Rails goodness, leave out the 10% bad, and stand a good chance of doubling (or more!) performance in the process.
Rails isn’t the only game in town, and it’s certainly not the best Ruby has to offer. It’s beautiful sure, and the alternatives would do well to ape most of it’s API, but the implementation is… lacking.
Plus DHH is an egomaniac. Ezra (author: Merb) manages to be nice and soliciting of community feedback while kicking Rails’ arse in the performance game at the same time.
@Avery – You should go look at all of the first movers who litter the IT landscape. Even in the current market you see plenty of examples of first movers who are now struggling to keep up with the latecomers. So being first to market is not all that it is cracked up to be.
Also, I think Rob’s point was more about the attitude of the Rails team than it was about performance. If they tell you to piss off on something as important as scalability, then it is sure to affect other parts of the platform and community. This is just a symptom of a larger problem. To me this is the equivalent of the “Runs on My Machine” mentality.
@brinkman – Being first to market doesn’t guarantee success, but it can sure help. I do agree his post is more about the attitude of the team, but personally I don’t have a problem with that when you consider it’s an open source MIT licensed project. They don’t owe us anything.
We can continue to speculate about whether DHH/Rails are listening to the community’s requests for performance, or we can just look at the numbers that clearly show it ain’t:
http://railsexpress.de/blog/articles/2007/09/18/rails-edge-performance
The fact that every version of Rails has been slower than the version before it is Not a Good Thing. Consider also the equally disturbing statistics about the interpreter it’s built upon:
http://shootout.alioth.debian.org/gp4/benchmark.php?test=all&lang=all
Second slowest of all languages when everything is considered. And about twice as slow as PHP. Again, Not a Good Thing.
Mind you, I want Rails to succeed as much as anybody — I’m half way through programming a web site that is written in RoR. But it doesn’t give me a warm fuzzy feeling to hear DHH and the Rails community marginalize the problem, saying it is 1% of websites that need speed, or saying that we save developer cycles so who cares about performance or saying we can write things in C.
The truth is, regardless of your needs, a naturally fast framework is a framework that allows programmers to spend time programming instead of spending time understanding advanced caching techniques and multi-database transactions. I love how powerful RoR makes me as a developer, but as long as DHH & others continue to label performance as “not important to improve,” Rails runs the risk of being supplanted by something uglier but more practical.
Comments on this entry are closed.