Author Topic: Ruby at Thoughtworks  (Read 725 times)

Offline Harkins

  • Level 28
  • **
  • Posts: 424
  • Reputation: +11/-2
  • Coder, blogger, entrepreneur.
    • View Profile
    • Push CX - Blog
Ruby at Thoughtworks
« on: June 12, 2009, 10:36:28 AM »
A nice article about the experience that ThoughtWorks (a large software consultancy) has had with Ruby. For the folks just interested in performance, the important bit is:

Quote
Is Ruby Slow?

In a word "yes". Search around for benchmarks on the net and you'll find numerous surveys that show that, even by the standards of scripting languages, Ruby is a tortoise.

On the whole, however, this has been irrelevant to us. Most of our uses of Ruby are in building database backed websites. I've visited many projects over the decades like this, using Ruby and other technologies, nearly every project has spent time working on performance issues and in almost every case those performance issues are database access. People spend time tuning SQL not tuning their processing code. So since most applications are I/O bound, the use of a slow language for processing doesn't make any appreciable impact to the overall performance of a system.

This is pretty much the same experience I had with the Python web framework Django at the Washington Post during the election season (which is the long-winded way of saying "very busy" without being allowed to give out the traffic numbers). Almost every performance issue we had was making sure the database could keep up with the amount of traffic. The only time I can remember the app servers had issues was once when we had to parse large XML files full of polling/voting results (1-200MB) and once when a library we were using had a memory leak. We we able to solve all our issues by replacing old db hardware and, more importantly, by using memcached.

Anyways, I really liked the last paragraph of what I quoted above. My experience and research consistently points at the database as the most common bottleneck for speed and scaling (especially during scaling; shared-nothing design makes app servers scale nearly linearly) with client issues (DNS, caching, other YSlow stuff) in second. So it's kind of frustrating to see people hamstringing themselves to save on variable access -- making code less maintainable to make the least-relevant parts of the system faster isn't a good bargain.

Visit #bbg on irc.freenode.net to talk browser games anytime.

Offline Scion

  • Level 27
  • **
  • Posts: 402
  • Reputation: +11/-0
    • View Profile
Re: Ruby at Thoughtworks
« Reply #1 on: June 12, 2009, 01:08:52 PM »
My thoughts on Ruby ( and other supposedly slow environments ) is that In the whole 95% of people wont ever build applications whre that becomes a serious issue....

and if it is then Ruby may not be th best choice going foward.

What they loose in performance they make up for in developer productivity.....particularly if your doing prototyping.

Offline JGadrow

  • Level 35
  • **
  • Posts: 1,133
  • Reputation: +23/-2
    • View Profile
Re: Ruby at Thoughtworks
« Reply #2 on: June 12, 2009, 09:00:48 PM »
I've had people try and get me into Ruby and one of these days I'll actually pick it up and play with it. But, my major problem is really just the syntax. There are two types of programmers: those who love c-style syntax and those who hate it. I happen to be one of the former.

For some reason (probably because I've been working with it for so many years) it just reads a lot clearer to me. Ruby is, technically, slower (I did work at a position that utilized Ruby for part of its business and PHP for another); however, it's probably accurate to state that most projects won't really notice a difference. Unless, of course, the code itself is performing a lot of the complex operations: data file parsing, file operations, image manipulation, etc.

Also, it's important to remember that Ruby is still a young language and each iteration of its development increases its maturity. Heck, most languages have at least a little room for improvement. Some people are reporting massive performance gains from simply upgrading their systems to use PHP 5.3. Without changing a line of code due to optimizations that have been made behind the scenes. So, who's to say that Ruby won't have a sudden leap in speed sometime in the near future.

My advice: Determine a language that's comfortable for you and suits your business goals. Or, try and learn the languages one-by-one. It's kind of like working with spoken languages: you'd be surprised how learning one can help you to understand another.
Idiocy - Never underestimate the power of stupid people in large groups.


Offline Harkins

  • Level 28
  • **
  • Posts: 424
  • Reputation: +11/-2
  • Coder, blogger, entrepreneur.
    • View Profile
    • Push CX - Blog
Re: Ruby at Thoughtworks
« Reply #3 on: June 12, 2009, 09:27:13 PM »
Ruby *is* C-style syntax. The only big new thing is blocks (lambdas).

Check out PostScript, Lisp, Haskell, or Brainfuck... then Ruby will look more like C, heh.

Visit #bbg on irc.freenode.net to talk browser games anytime.

Offline JGadrow

  • Level 35
  • **
  • Posts: 1,133
  • Reputation: +23/-2
    • View Profile
Re: Ruby at Thoughtworks
« Reply #4 on: June 12, 2009, 09:35:18 PM »
Code: [Select]
class String
    def NullOrEmpty?
    (self == nil || self == "")
    end
end
puts "test".NullOrEmpty?
puts "".NullOrEmpty?

Doesn't look much like C to me. It's defintely more 'c-like' than other languages. However because of lack of semi-colons and braces and usage of end statements, I'd qualify it more as BASIC syntax.

But, yes, I agree that it's much better than:

Code: [Select]
Point subclass: #GriddedPoint
        instanceVariableNames: ''
        classVariableNames: ''
        poolDictionaries: ''
        category: 'Exercise11.5'!


!GriddedPoint methodsFor: 'accessing'!

x: xInteger
        "Set the x coordinate gridded to 10 (using rounding, alternatively I could
        use truncating)."

        super x: (xInteger roundTo: 10)!

y: yInteger
        "Set the y coordinate gridded to 10 (using rounding, alternatively I could
        use truncating)."

        super y: (yInteger roundTo: 10)! !

!GriddedPoint methodsFor: 'private'!

setX: xPoint setY: yPoint
        "Initialize the instance variables rounding to 10."
       
        super setX: (xPoint roundTo: 10) setY: (yPoint roundTo: 10)! !
Idiocy - Never underestimate the power of stupid people in large groups.


Offline Chris

  • Game Owner
  • Level 35
  • *
  • Posts: 2,217
  • Reputation: +28/-1
    • View Profile
Re: Ruby at Thoughtworks
« Reply #5 on: June 13, 2009, 04:32:44 AM »
No semicolons? No bracers? This is... this is... perversion! :D

Offline Harkins

  • Level 28
  • **
  • Posts: 424
  • Reputation: +11/-2
  • Coder, blogger, entrepreneur.
    • View Profile
    • Push CX - Blog
Re: Ruby at Thoughtworks
« Reply #6 on: June 13, 2009, 08:29:42 AM »
If by "perversion" you mean "readable"... yeah. Beyond the word "end" I don't really see a resemblance to Basic.

The Ruby code you pasted is a lot like C++ -- though the NullOrEmpty? function has an implicit return, methods defined by an operator (def instead of function), there's infix operators for testing equality and doing a logical OR, and object methods are called with a . operator. To me, Ruby looks like a C language without most of the redundant punctuation ({}, (), ;). (Fun fact: Rails' ActiveSupport library provides basically this function as <a href="http://dev.rubyonrails.org/browser/trunk/activesupport/lib/active_support/core_ext/blank.rb">blank?</a>.)

Visit #bbg on irc.freenode.net to talk browser games anytime.

Offline Scion

  • Level 27
  • **
  • Posts: 402
  • Reputation: +11/-0
    • View Profile
Re: Ruby at Thoughtworks
« Reply #7 on: June 13, 2009, 02:10:59 PM »
while were on the ruby bashing bus....

I tried it and didnt like it... I miss my syntatical markers...the braces and so on....

also im not all that comfortable working with very sucint languages....perl just gives me the hebe-jebes. Id rather type out twice as much in code and be able to read it without having to ask myself....um what does that mean again....

ok I guess if i had to id be able too ....after all ive lost track of the number of languages that ive worked with.... but for something at home...well id rather work with something that reads well.... at least to my tired old eyes ;)

Offline JGadrow

  • Level 35
  • **
  • Posts: 1,133
  • Reputation: +23/-2
    • View Profile
Re: Ruby at Thoughtworks
« Reply #8 on: June 13, 2009, 10:34:18 PM »
while were on the ruby bashing bus....

I'm not 'bashing' Ruby... simply stating my quirky reason for not having tried it yet. :) I DO intend to try it one of these days.
Idiocy - Never underestimate the power of stupid people in large groups.


 


SimplePortal 2.3.3 © 2008-2010, SimplePortal