Yukihiro Matsumoto wrote:
> In message "Re: Joel Spolsky on languages for web programming"
>     on Fri, 1 Sep 2006 20:30:02 +0900, "Dido Sevilla" <dido.sevilla / gmail.com> writes:
> > (2) it's known to be slow, so if you become The Next MySpace, you'll
> >     be buying 5 times as many boxes as the .NET guy down the hall.
> (2) Although Ruby runs slower than other languages in those
>     micro-benchmarks, real bottleneck in the most application lies in
>     either network connection or databases.  So we don't have to buy 5
>     times as many boxes.

Agreed. I manage engineering at Edgeio (http://www.edgeio.com/). We
don't use Rails, but we do use Ruby extensively on our _backend_. All
of our backend was initially written in C++, but I decided to start
migrating it to Ruby because:

 1) It massively cut complexity. As an example I replaced a very
primitive, simple messaging middleware system with 700 lines of Ruby
that was significantly more advanced. Adding the same features to the
C++ version would easily have brought it to 3000-4000 lines of code.
More importantly, it took less time to write the Ruby version than to
write the much more primitive C++ code. And that system was my first
ever Ruby app, while I've been doing C/C++ for more than 10 years.

 2) We hardly ever max out CPU's. We _can't_ buy boxes with slow enough
CPU's to make it become an issue for most of our servers. The messaging
middleware app handles millions of messages per day and rarely takes up
10% of a single CPU on the servers it runs on.

3) Most of the CPU time used by our Ruby apps is spend waiting for IO.
For the messaging middleware server, a conservative estimate is that
about 80% of the time is spent _in the kernel_ in read() or write()
syscalls. So even assuming that we could get a 10 times speedup of the
code we have written from moving the code back to C/C++, that would
only translate to a reduction in CPU use from 10% to 8.2% (reducing
time spent in userspace from 2% to 0.2%). Heck, even a 100 times
speedup of the userspace code would still only reduce the CPU use from
10% to 8.02%...

4) Servers are cheap. Engineers are not. A relatively senior engineer
easily costs USD 8k-12k a month (salary+social costs). A single
man-month of wasted effort could buy me a lot of extra processing
power.

5) When we scale, the limitations we run into are from most to least
important: disk io capacity, memory, network latency, cpu. Optimizing
algorithms to minimize disk writes, minimize memory usage (granted,
this is an area were we have to be careful with Ruby) and minimize
latency are all more important than reducing cpu usage. As a result,
because we'll generally have to buy/lease more servers based on io
capacity and memory, we have a lot of wasted CPU capacity. For _most_
(not all) of our backend code, spending time speeding up the code would
not save us anything.

6) IF/when we have to rewrite things in C/C++ to speed it up at any
time, it'll still be far more effective to translate small, isolated
parts of working, well tested Ruby code directly and create extensions
of them, than to write the whole apps as C/C++.

Vidar