I still don’t get the fascination with Ruby on Rails


Published on May 26th, 2007
7 Comments

Blogging live from BarcampSheffield where the technology of the minute still seems to be Ruby on Rails. I detest RoR.

RoR is offered as a platform that is quick to scale, because the framework that it sits upon can be scaled horizontally. This means that when you run out of capacity for your application, you can drop another identically configured box in to the cluster. This really isn’t the case, even for companies who have lots of VC cash to burn through. If you colo in a typical London Datacentre, you will typically only be allowed to draw 8A of current. A modern ‘enterprise’ server has a significant power draw, so you don’t get to keep adding boxes.

You also can’t just keep ordering power feeds, as even if the Datacentre owner will let you, you still need to deal with excess heat.

Scaling does not mean “Allows you to throw money at the problem”, it means “Can deal with workload”.

The RoR ‘Live’ demonstration was being developed on a 1.2GHz laptop, and had one user at the start (the demonstrator). The guy needed to apologise for the poor performance of the application! For anyone trying to solve the problem of scale, I repeat the advice I always offer in person - checkout mod_perl. When you can design your application to run as Apache modules, you will find you can deal with workload much more effectively (read: quickly!) than by buying lots of kit. When you want to scale horizontally (as, actually, you should for redundancy), you still can, it’s just a case of managing sessions.

Anyway, Barcamp has been very useful. Check out the Barcamp photos on flickr. No idea who set out to embarrass Plusnet (the hosts) following news last week.. :-)


Comments

7 Responses to “I still don’t get the fascination with Ruby on Rails”

  1. Stubbs Says:

    To be fair Andy, the same comments could aimed at any system that you don’t design properly, it’s not just down to a flaw in Ruby or Rails.

  2. andy Says:

    This comment was passed to me by Adam Bardsley, the demonstrator


    I was going to explain in a comment that the laptop is not only a 1.2Gz but it is also very old and and takes a good minute just to run the java eclipse editor. I wouldn’t use this as an argument that says java is good enough for serious use :)

  3. andy Says:

    Thanks for writing. The first thing I want to say is that I enjoyed your demonstration and was impressed with the web-app that you wrote in double quick time.

    My opinion is that :

    • Rails adds an overhead, so you need to scale sooner.
    • Scaling isn’t free, every n’th box you add costs you more than the previous one you added. Servers eat power and generate heat, its getting very hard to deal with these problems
    • If scaling is important you are better designing a webapp with access to the apache request cycle. mod_perl lets you generate light, and fast web applications and certainly suits my clients better than Rails would.
    • Good to meet you yesterday.

  4. Adam Bardsley Says:

    Rails does indeed add an overhead but you eight that against the amount of flexibility, productivity and quailty of code you can create. I actually regret the demo only really showed how quickly you can do things rather than foxussing on the clever programming tactics you can use to make very easily understandable code.

    On the performance side people are actually working on an event based proxy that should massively increase speed as well as adding flexibilty to your scallinbg solution : http://swiftiply.swiftcore.org/ for anyone whose interested

  5. craiga Says:

    Talk of performance weighted against flexibility, productivity or code quality is a specious argument. You can write good or bad code in any language, though I’ll concede that some (PHP) tend more one way than the other. Similarly, flexibility and productivity are features of the programmer, not the language.

    It is interesting that you mention the “clever programming tactics” that ostensibly make Ruby more understandable. It is nice that some of what makes Perl great has made it in there, but therein lies the problem.

    One of the primary criticisms levelled against Perl is that too many people use clever tricks that are infinitely more readable to them, but only serve to obfuscate for other programmers. Cleverness, when applied to programming, isn’t always all it’s cracked up to be. Elegance is a far greater substitute:

    “Debugging is twice as hard as writing the code in the first place. Therefore, if you write the code as cleverly as possible, you are, by definition, not smart enough to debug it.” – Brian W. Kernighan

    As a final point, I would suggest that better (or at least less painful) integration of Ruby and Apache would be a better long term performance (and security, and configurability) gain than adding another layer to the stack.

  6. Ian Lonsmith Says:

    Adam Bardsley wrote:
    [...] but you eight that [...] foxussing [...] your scallinbg solution [...] anyone whose interested

    Are you drunk?

  7. MG Says:

    Sorry to comment on an old post like this, but the RoR craze worries and annoys me too. It seems no real thought has been given to what happens when the application is built - sure it speeds up development but an application does not stop existing when development is finished

    * There are maintenance issues caused by all the ‘magic’ - I am of the opinion that to be a good developer you need to understand what happens in an application at a low level so optimisations can be targeted where required. Ruby seems to encourage abstraction and this can lead to scant regard being paid to sensible database design and unnecessary bloat.

    * Hosting / Server Admin is a hit and miss affair - early RoR evangelists sung the praises of fastcgi which I have found to be like plain old cgi but patched up with speed-laced chewing gum. Then there are things like lighttpd and WEbrick, the latter is too small and the former unreliable. I have been pointed in the direction of NGINX but am a bit wary of it. So I have settled for my current preferred solution of Apache 2.2 with mod_proxy_balancer as a front to a mongrel_cluster - I have yet to test this in anger but it at least uses a known application at the front end. It seems odd to me though that what is bandied about by the developer crowd as a fantastically elegant solution generates applications destined to live out their lives in what can best be described as a compromise.

    I find it a bit like someone coming up with a fantastic new way to build a car really quickly and ignoring the fact they are completely un-drivable. Maybe I am missing a trick, but surely a decent mod_ruby can’t be too hard to come up with?

Leave a Reply

You must be logged in to post a comment.