New Community Website

Ordinarily, you'd be at the right spot, but we've recently launched a brand new community website... For the community, by the community.

Yay... Take Me to the Community!

The Community Blog is a personal opinion of community members and by no means the official standpoint of DNN Corp or DNN Platform. This is a place to express personal thoughts about DNNPlatform, the community and its ecosystem. Do you have useful information that you would like to share with the DNN Community in a featured article or blog? If so, please contact .

The use of the Community Blog is covered by our Community Blog Guidelines - please read before commenting or posting.

The Tortoise and the Hare

C# vs Ruby

Over the last couple of days there has been a running debate concerning the scalability of Ruby.  In his post on the Language Wars, Joel Spolsky argued that Ruby on Rails was not yet a safe bet when building large scale web applications.  Joel's primary argument was that there is not a lot of real world experience available to know how well Ruby will scale or how easy it will be to overcome other technical obstacles that occur on most projects.

For some reason this has sparked a bit of backlash.  Joel revisited this topic a few days later and said:

I understand the philosophy that developer cycles are more important than cpu cycles, but frankly that's just a bumper-sticker slogan and not fair to the people who are complaining about performance.

This did not sit well with Jeff Atwood who believes that Joel may have jumped the shark, or Phil Haack who thinks Joel may be reaching and believes that Ruby on Rails can use the same performance optimization techniques employed by other languages (including  Wasabi, which is the DSL used for writing FogBugz).

Both of these posts miss the original point that Joel was trying to make:  Ruby is still not a mature language, and Ruby on Rails is even less mature.  There is no evidence yet that Ruby or Ruby on Rails applications will scale to the level typically required for many large scale web applications.  There are well documented performance issues, that Joel rightly points out.

Phil believes that developer productivity is an important consideration when building an application and that early in product development, this productivity should trump raw language performance.  I reject this view when you are talking about using an immature language.

Developer productivity is not just a matter of how many lines of code it takes to write an application.  It is also measured by the tools available to help develop and maintain the code.  Can I easily refactor my code?  Are common design patterns well documented for the language?  Are common anti-patterns documented?  Are solutions to common technical problems readily available and functional in the chosen language?  What kind of debugging tools are available?

When a developer is forced to use immature tools, a greatly reduced body of knowledge about how to solve common problems using a given language and must also accept a large performance penalty, then I would argue that this is probably not a language that should be near the top of the list when choosing a language for your next large scale application.

Jeff throws up a strawman argument that because Joel uses Wasabi for developing Fogbugz, then his arguments against Ruby are without merit.  This is a totally fallacious argument.  Joel chose to develop a Domain Specific Language to meet his needs when developing Fogbugz.  His company knows the complete set of requirements for both the language and the target application.  As application requirements evolve, Joel is free to evolve his DSL to solve those problems in a very efficient manner.  Since Wasabi is written in C#, evolving the DSL is not a herculean task.  The tools for maintaining Wasabi are mature and the body of knowledge is quite large.  His DSL is nothing more than a very intelligent code generator.  This however is completely different from the original argument against using Ruby on Rails for a generic large scale web development, where the success of your company may be on the line.  If you run into a roadblock in Ruby or Ruby on Rails, there is no guarantee of a cheap or easy fix.  In fact, because of the immaturity of the platform, there is a much greater risk that you will run into a roadblock.  And there is a good chance that you may well be the first person to document this technical hurdle.  At this point, developer productivity drops to zero.

As we have found with DotNetNuke: identifying and resolving performance problems are hard enough when you have mature tools available for troubleshooting, and when you have lots of developer knowledge available to aid in solving tough technical problems.  To choose a language where you are almost guaranteed to have more technical challenges, while also having a smaller developer base, and immature tools does not seem to me to be a good bet.  Choosing Ruby on Rails for your web project necessarily carries a much larger risk than using one of the proven stacks.


There are currently no comments, be the first to post one.

Comment Form

Only registered users may post comments.


Aderson Oliveira (22)
Alec Whittington (11)
Alessandra Davies (3)
Alex Shirley (10)
Andrew Hoefling (3)
Andrew Nurse (30)
Andy Tryba (1)
Anthony Glenwright (5)
Antonio Chagoury (28)
Ash Prasad (37)
Ben Schmidt (1)
Benjamin Hermann (25)
Benoit Sarton (9)
Beth Firebaugh (12)
Bill Walker (36)
Bob Kruger (5)
Bogdan Litescu (1)
Brian Dukes (2)
Brice Snow (1)
Bruce Chapman (20)
Bryan Andrews (1)
cathal connolly (55)
Charles Nurse (163)
Chris Hammond (213)
Chris Paterra (55)
Clint Patterson (108)
Cuong Dang (21)
Daniel Bartholomew (2)
Daniel Mettler (181)
Daniel Valadas (48)
Dave Buckner (2)
David Poindexter (12)
David Rodriguez (3)
Dennis Shiao (1)
Doug Howell (11)
Erik van Ballegoij (30)
Ernst Peter Tamminga (80)
Francisco Perez Andres (17)
Geoff Barlow (12)
George Alatrash (12)
Gifford Watkins (3)
Gilles Le Pigocher (3)
Ian Robinson (7)
Israel Martinez (17)
Jan Blomquist (2)
Jan Jonas (3)
Jaspreet Bhatia (1)
Jenni Merrifield (6)
Joe Brinkman (274)
John Mitchell (1)
Jon Henning (14)
Jonathan Sheely (4)
Jordan Coopersmith (1)
Joseph Craig (2)
Kan Ma (1)
Keivan Beigi (3)
Kelly Ford (4)
Ken Grierson (10)
Kevin Schreiner (6)
Leigh Pointer (31)
Lorraine Young (60)
Malik Khan (1)
Matt Rutledge (2)
Matthias Schlomann (16)
Mauricio Márquez (5)
Michael Doxsey (7)
Michael Tobisch (3)
Michael Washington (202)
Miguel Gatmaytan (3)
Mike Horton (19)
Mitchel Sellers (40)
Nathan Rover (3)
Navin V Nagiah (14)
Néstor Sánchez (31)
Nik Kalyani (14)
Oliver Hine (1)
Patricio F. Salinas (1)
Patrick Ryan (1)
Peter Donker (54)
Philip Beadle (135)
Philipp Becker (4)
Richard Dumas (22)
Robert J Collins (5)
Roger Selwyn (8)
Ruben Lopez (1)
Ryan Martinez (1)
Sacha Trauwaen (1)
Salar Golestanian (4)
Sanjay Mehrotra (9)
Scott McCulloch (1)
Scott Schlesier (11)
Scott Wilkinson (3)
Scott Willhite (97)
Sebastian Leupold (80)
Shaun Walker (237)
Shawn Mehaffie (17)
Stefan Cullmann (12)
Stefan Kamphuis (12)
Steve Fabian (31)
Steven Fisher (1)
Timo Breumelhof (24)
Tony Henrich (3)
Torsten Weggen (3)
Tycho de Waard (4)
Vicenç Masanas (27)
Vincent Nguyen (3)
Vitaly Kozadayev (6)
Will Morgenweck (40)
Will Strohl (180)
William Severance (5)
What is Liquid Content?
Find Out
What is Liquid Content?
Find Out
What is Liquid Content?
Find Out