Furthermore, C# on .NET has available similar libraries to take a lot of the pain out of the programming, jut like Rails does. I’m personally most familiar with a framework called Gentle which is an ORM that I’ve written extensions to to make it more “rails like” and take some of the grunt work out of building an application. It still needs a lot of work, and the Gentle project appears nearly dead due to lack of support, further vexing my decision…

The other two guys are NOT MS types, so I can completely understand them not wanting to do the investment needed to get into .NET. So, I am at a sort of cross roads of decisions, and I’m not comfortable with any answer.

I don’t know enough about YARV to make any claims of faith. I assume that most languages and technologies can be made to perform better, if enough effort it put into them.

That’s interesting. I have build web applications in .NET (VB) for the last 4 years. Even though I recognize that .NET is a powerful platform, I find that Rails is so much better. This last comment should be taken with a grain of salt however… since I only worked with version 1.1. I heard things have changed a little since then But, it’s like I’ m just fed up with .NET. My last full year as a .NET developer bored me to death, I swear. When I decided to try RoR, it was like my saving grace.

Never heard about that Gentle framework. If it helps building .NET applications faster than it’s good news.

@Chris

Well, if Ruby 2.0 becomes much faster like you said, it will be in part because of YARV which is planned to be integrated in this version.

Btw, that’s one awesome website! I just rated it on StumbleUpon… I hope it will bring you some well deserved traffic. Do you use AJAX to load content or is it only preloaded javascript?

First, are you talking about Ruby or are you talking about Ruby on Rails? Two very separate things.

Ruby, like you say, is slower than Python. Whether this will still be true when Yarv comes along we don’t know. Either way, I say it doesn’t matter. It doesn’t matter because the vast majority of a program isn’t all that affected by computation speed, especially when talking about a web application. Not only that, but if your program is sluggish, you can easily profile your application and, if it’s not possible to optimize it more, replace the bottleneck entirely with C. It’s actually very easy to do in Ruby.

Now for Rails. The twitter case I’m not really happy about people using as an example of scalability. First off, they can get up to 12,000 hits/second. That’s a massive amount of traffic. Their first bottleneck was computational but when they added more mongrel servers, this bottleneck was resolved. Their complaint is that it’s difficult to connect one application to multiple databases with Rails. As DHH pointed out, this is true of any single-stack framework. This however, has nothing to do with the speed of Ruby. Twitter’s bottleneck is the database connection. Changing to Yarv, even if Yarv is two, three or 100 times faster will do nothing for them since it won’t affect their bottleneck. They might be able to run less mongrel servers but overall there will be no change. So really it’s a Rails framework problem (the ability to easily connect to multiple database), not a Ruby problem.

And when thinking about whether you should adopt RoR or not based on scalability issues, consider when you’ll be getting to 12,000 hits/second and whether by then the ability to connect to multiple databases will be included in Rails, either because the Twitter guys figured it out and published how or someone else did. Even the twitter guys didn’t say it’s impossible. I’ve never tried so I don’t know myself. They just said it’s not as easy as everything else in Rails and that’s why they were complaining.

Selling Ruby and Rails as a platform to mgmt was much, much harder than implementing it.

I’ve ported Perl scripts to Ruby which have then been significantly faster on Ruby, not because the language is faster but because the libraries used have been better written, have used C extensions, and any number of factors. A great coder in Ruby will kick an average Python programmer in the ass, so it’s not always down to the speed of the language but the programmer.

One great example of this is in the land of SQL. It seems most developers have only a basic knowledge of SQL (particularly people who write forum software for some reason..) and design some absolutely hideous databases and queries and expect the RDBMS to sort it all out (which it doesn’t). It’s not rare for a semi-competent SQL developer’s code to outperform crappy SQL code by 10 to 100 times or more, simply because they know what they’re doing and can compress an operation into, say, 10 rapid database operations rather than 1 humongous join that takes five minutes to run.

So.. more Ruby performance is always a good thing, but more important is skill, understanding algorithms, and being able to see the big picture of optimization rather than the raw speed of the language.

If you threw me in a Formula 1 car, I bet I’d still drive like crap, and Michael Schumacher could probably beat me in a Mercedes SL no troubles. It’s the skill, not the tool.

2) Yes I have faith in YARV. I have to have faith in it :).

http://eigenclass.org/hiki/non-synthetic-benchmarks-for-yarv

http://shootout.alioth.debian.org/gp4sandbox/benchmark.php?test=all&lang=ruby&lang2=yarv

http://shootout.alioth.debian.org/gp4sandbox/benchmark.php?test=all&lang=all

He hasn’t run the 2nd batch of tests like h said, but it’ll be interesting to see those results too.

I’ll be at RailsConf ‘07 and I’ll have to say, this session:
http://conferences.oreillynet.com/cs/rails2007/view/e_sess/14480
on scaling Rails apps on Amazon’s EC2 service has me quite excited.

Connecting to multiple databases has been sorted out.