Recent Criticism about Ruby (Scalability, etc.)

F

forrie

I presume most people here read today's article on Slashdot which had
some critique about Ruby and scaling to a large architecture. Though
the article didn't seem to elaborate into specifics, I'm interested in
other people's feedback and perspective on this.

I'm currently learning Ruby. One of the first questions I had (and
Googled for) had to do with scalability, for large enterprise-class
applications. I found a couple of articles, but haven't yet tested
this in a lab setting. Then there is Parrot, which I've not used
yet.
From what I have learned in the past (and that may not be very
complete yet!), Java scales very well due to it's VM. I think Java is
considered a static-typed language versus dynamically-typed language
(a la Ruby), whatever differences that means at that level.

Due to the growing popularity of Ruby and Rails, I would imagine this
would be of importance. Pardon if I've missed something (I have
searched, and am searching) - that being the case, URLs to articles
would be appreciated.

I remember a previous gig where we used Java heavily and the scaling
was pretty linear. Need more space? Add another blade and so on...
probably not the most optimal method - considering their load
balancing was based on connections not actual system load, etc.


Thanks!
 
T

Tim Hunter

I presume most people here read today's article on Slashdot which had
some critique about Ruby and scaling to a large architecture. Though
the article didn't seem to elaborate into specifics, I'm interested in
other people's feedback and perspective on this.

I'm currently learning Ruby. One of the first questions I had (and
Googled for) had to do with scalability, for large enterprise-class
applications. I found a couple of articles, but haven't yet tested
this in a lab setting. Then there is Parrot, which I've not used
yet.

complete yet!), Java scales very well due to it's VM. I think Java is
considered a static-typed language versus dynamically-typed language
(a la Ruby), whatever differences that means at that level.

Due to the growing popularity of Ruby and Rails, I would imagine this
would be of importance. Pardon if I've missed something (I have
searched, and am searching) - that being the case, URLs to articles
would be appreciated.

I remember a previous gig where we used Java heavily and the scaling
was pretty linear. Need more space? Add another blade and so on...
probably not the most optimal method - considering their load
balancing was based on connections not actual system load, etc.


Thanks!

Hmmm...Are you talking about the Derek Silvers CD Baby blog post? Derek
was talking about Ruby on Rails, not Ruby, and none of his 7 reasons had
to do with the scalability of RoR.

Or have I missed another Ruby post on Slashdot today?

In any case, this is a Ruby-specific list. There's tons of people on the
Ruby On Rails mailing list that would love to debate this issue with
you. See http://www.rubyonrails.com/community.
 
P

Phlip

forrie said:
I presume most people here read today's article on Slashdot which had
some critique about Ruby and scaling to a large architecture.

Nope.

I go with Dave Thomas's verbiage "Ruby stays out of your way". That says it
all - dynamic typing, clear simple statements, endless extensibility, and
realistic scaling, all in a nutshell.
I remember a previous gig where we used Java heavily and the scaling
was pretty linear. Need more space? Add another blade and so on...

That's not scaling! (Okaaay, that's only one aspect of scaling!)

How did your Java design itself scale? The rate you add new features - did
it go up or down over time? _That's_ scaling. If the rate doesn't slow down,
you have time to tune your code to speed it up and handle more users...
 
M

M. Edward (Ed) Borasky

Tim said:
Hmmm...Are you talking about the Derek Silvers CD Baby blog post? Derek
was talking about Ruby on Rails, not Ruby, and none of his 7 reasons had
to do with the scalability of RoR.

Or have I missed another Ruby post on Slashdot today?

In any case, this is a Ruby-specific list. There's tons of people on the
Ruby On Rails mailing list that would love to debate this issue with
you. See http://www.rubyonrails.com/community.

I recently rejoined the Rails list, mostly because I'm looking for a
Rails application to include in my benchmark suite. "forrie" posted a
similar question on the Rails list and I answered it there.

But ... you're right -- the article on Slashdot is just a pointer to the
O'Reilly Ruby blog entry about the CD Baby migration from PHP to Rails
and back to PHP, with very little about scalability.

So ... while I've got your attention, I'm *still* looking for an open
source Rails application to add to my benchmark suite. So far, what's on
the Rails site in that category is rather out of date, but I think there
are one or two there I can use (rTPlan and Substruct). What I need is an
open source Rails application *with complete installation and
configuration instructions* -- that is, don't assume I wrote the thing
and know how to set up the databases, etc. :)
 
J

Jeremy McAnally

Have you looked at Beast?

http://beast.caboo.se/

I recently rejoined the Rails list, mostly because I'm looking for a
Rails application to include in my benchmark suite. "forrie" posted a
similar question on the Rails list and I answered it there.

But ... you're right -- the article on Slashdot is just a pointer to the
O'Reilly Ruby blog entry about the CD Baby migration from PHP to Rails
and back to PHP, with very little about scalability.

So ... while I've got your attention, I'm *still* looking for an open
source Rails application to add to my benchmark suite. So far, what's on
the Rails site in that category is rather out of date, but I think there
are one or two there I can use (rTPlan and Substruct). What I need is an
open source Rails application *with complete installation and
configuration instructions* -- that is, don't assume I wrote the thing
and know how to set up the databases, etc. :)


--
http://www.jeremymcanally.com/

My free Ruby e-book:
http://www.humblelittlerubybook.com/book/

My blogs:
http://www.mrneighborly.com/
http://www.rubyinpractice.com/
 
C

Chad Perrin

Geez - I wish I could trash-talk Rails like that. I need a way to get my
blog entries to the top of the commented-on lists!

Oh, here:

http://www.oreillynet.com/onlamp/blog/2007/09/big_requirements_up_front.html

That's actually quite good. Thanks for the URL -- I enjoyed the read.

I had a forehead-smacking moment while reading that, where I realized
that *of course* it's true that after two years of not getting anything
substantially right, there's obviously something else wrong besides
choosing the wrong tool (if it's wrong for that purpose at all, which
does not appear to be a settled matter from where I'm sitting).

Hell, two years should be enough time to get something working in COBOL,
let alone Rails.
 
R

Ruby Maniac

Geez - I wish I could trash-talk Rails like that. I need a way to get my
blog entries to the top of the commented-on lists!
Oh, here:

That's actually quite good. Thanks for the URL -- I enjoyed the read.

I had a forehead-smacking moment while reading that, where I realized
that *of course* it's true that after two years of not getting anything
substantially right, there's obviously something else wrong besides
choosing the wrong tool (if it's wrong for that purpose at all, which
does not appear to be a settled matter from where I'm sitting).

Hell, two years should be enough time to get something working in COBOL,
let alone Rails.

--
CCD CopyWrite Chad Perrin [http://ccd.apotheon.org]
Leon Festinger: "A man with a conviction is a hard man to change. Tell him
you disagree and he turns away. Show him facts and figures and he questions
your sources. Appeal to logic and he fails to see your point."

Ruby scales just fine as long as you are willing to throw a ton of
compute hardware at it !

I believe Twitter is successfully using Ruby for their site but then
they have also invested in a ton of servers dedicated to running
hundreds of Mongrels.

So yeah, get out your checkbooks and write more checks for more
servers and sure Ruby scales just fine !

Ruby Rocks !
 
G

Glenn Gillen

So yeah, get out your checkbooks and write more checks for more
servers and sure Ruby scales just fine !

Ruby Rocks !

2 years x 1 developer @ $70k = 58x Dell PowerEdge 860 Quad Core Xeon
X3210s

Job Security Rocks!
 
R

Ruby Maniac

2 years x 1 developer @ $70k = 58x Dell PowerEdge 860 Quad Core Xeon
X3210s

Job Security Rocks!

Ruby is infintely scalable as long as you got the bucks to pay for all
that hardware ! (*Just forget the fact that another language might
have saved some money in compute gear. I mean, don't even think about
this at-all. Why are you still reading this sentence? I told you to
forget about what those 58 server cost... Money is irrelevant to those
who love Ruby! *)

Ruby Rocks !
 
M

M. Edward (Ed) Borasky

Chad said:
I had a forehead-smacking moment while reading that, where I realized
that *of course* it's true that after two years of not getting anything
substantially right, there's obviously something else wrong besides
choosing the wrong tool (if it's wrong for that purpose at all, which
does not appear to be a settled matter from where I'm sitting).

Hell, two years should be enough time to get something working in COBOL,
let alone Rails.

I don't think it was a matter of not getting something working -- IIRC
CD Baby did *work* when it was in Rails. In reality, I think it was that
he didn't understand MVC, Ruby or Rails when he started the migration --
it just looked cool, so he went out and hired a Rails programmer to do it.
 
J

John Joyce

I don't think it was a matter of not getting something working -- IIRC
CD Baby did *work* when it was in Rails. In reality, I think it was
that
he didn't understand MVC, Ruby or Rails when he started the
migration --
it just looked cool, so he went out and hired a Rails programmer to
do it.
Question is, why is his site important enough to warrant him writing
on anything?
It's still a crappy looking site, always has been. I could care less
what he has to say for or against a language or framework. (which he
can't seem to understand the difference or separation between)
He did say he was not fond of frameworks. So he sticks to PHP alone
which is a mishmash of functions.
I don't think that guy is qualified to say much about building software.
2 years to rebuild in Rails?! How?!
Simple. You can't force an existing database structure onto a
framework that has an ORM. Doesn't work well if at all.
You can migrate the data. easy.
 
G

Giles Bowkett

Question is, why is his site important enough to warrant him writing
on anything?

Actually, CD Baby is a godsend to a large number of small-scale
musicians. I think the "Code Monkey" guy sells all his music through
them.

A lot of the reactions here are just defensive. But there's no point
being defensive because the whole thing really isn't that important.
It's one guy who tried to do a massive rewrite and found out that
incremental rewrites are better. Mix in a bunch of language-crazy
programmers who care way too much about Language X vs. Language Y, put
them all together on Slashdot - where people with nothing to do come
to dis each other - and you've got a so-called big deal.

So, the moral(s) of the story:

1. Code Monkey like Fritos
2. Slashdot people argue about everything
3. Incremental rewrites pwn from-scratch rewrites

Yay. The end.

(Notice the absence of any lesson about PHP, Ruby, or Rails.)

--
Giles Bowkett

Blog: http://gilesbowkett.blogspot.com
Portfolio: http://www.gilesgoatboy.org
Tumblelog: http://giles.tumblr.com/
 
B

Brad Phelan

Ruby said:
Ruby is infintely scalable as long as you got the bucks to pay for all
that hardware ! (*Just forget the fact that another language might
have saved some money in compute gear. I mean, don't even think about
this at-all. Why are you still reading this sentence? I told you to
forget about what those 58 server cost... Money is irrelevant to those
who love Ruby! *)

Ruby Rocks !

The 58 servers next year will cost half as much. The developer next year
will cost the same or more.

I work in embedded systems. The hardware / software cost analysis turns
out different here. An embedded system will typically be deployed on
thousands and sometimes millions of devices. Here it is worth saving
pennies on compute hardware by spending big $$$ on software development
and trying to keep the code as small and optimized as possible. You will
still find many cheap 8bit and 16bit computers running your cars, phones
and refrigerators. The cost of finding developers who can deal properly
with those sorts of devices is not cheap.

However for a web server with a hardware deployment footprint orders of
magnitude lower than an embedded systems deployment it doesn't make
sense to try to save money on hardware. Where you will blow your budget
is with the software developers.

With regards to Python/Ruby speed issues. I am currently watching a
complex scheduling algorithm ticking by very slowly in a shell while I
write this post. The algorithm should should have been written in C/C++
and not in Python/Psyco or Ruby and I am going nuts waiting for it to
complete.

( BTW I didn't write it )

B
 
M

M. Edward (Ed) Borasky

Brad said:
With regards to Python/Ruby speed issues. I am currently watching a
complex scheduling algorithm ticking by very slowly in a shell while I
write this post. The algorithm should should have been written in C/C++
and not in Python/Psyco or Ruby and I am going nuts waiting for it to
complete.

( BTW I didn't write it )

"Complex scheduling algorithm" means different things to different
people. Is it slow because the algorithm sucks or slow because it's not
written in C/C++? What kind of scheduling is it -- combinatorial?
 
C

Christoffer Lernö

Question is, why is his site important enough to warrant him
writing on anything?
It's still a crappy looking site, always has been. I could care
less what he has to say for or against a language or framework.
(which he can't seem to understand the difference or separation
between) He did say he was not fond of frameworks. So he sticks to
PHP alone which is a mishmash of functions.
I don't think that guy is qualified to say much about building
software.
2 years to rebuild in Rails?! How?! Simple. You can't force an
existing database structure onto a framework that has an ORM.
Doesn't work well if at all.
You can migrate the data. easy.

There is a lot of things that can go wrong when you do a rewrite,
especially when you do a rewrite in a new language and framework.

In this particular case, from what I understand was the main problem
was basically that he had a working platform in PHP, and he wanted to
improve that. His experience from building the system in PHP would
help immensely if he would rewrite it in... PHP. With Rails, I
suspect his PHP experience would work against him, both leading him
towards solutions more suitable for PHP than Rails, and also
effectively steering him away from the easiest Rails-like solutions.

In addition he had problems getting the other systems - already tuned
for use with his old PHP code - to play with Rails. Again this is
only natural if you have built a significantly large system already.

These two factors alone can explain why building the system in Rails
took so long.

So I think there's no need to be so judgemental here. I didn't feel
it was a criticism against Ruby, just a warning that even the best
regarded framework isn't a guarantee for success, and you should go
into everything with your eyes wide open.

So no need to be rude to him.


/Christoffer
 
F

Florian Gilcher

At first, let me point out this post from the Ruby on Rails weblog:

http://weblog.rubyonrails.com/2007/9/25/designing-scalable-architectures

I saw the presentation myself and Jasons point was the following: as
Rails doesn't implement a stateful wrapper for HTTP as some other
Frameworks (like Webobjects) do, it is scalable by default. The "throw
more servers at it" works. The speed of the Framework is of no interest
in this case, but with the correct hardware and application layout,
Rails scales pretty linear. The thing is: Rails may have some small
features that support you in scaling, but most of this work is still
yours, Rails or not.
Scalability is much more an architectural thing then a language issue.
Often, fine-tuning your servers is much more worthwhile than fine-tuning
your application.

The post on Slashdot was a typical for Slashdot: harsher then necessary.
The only thing that this poor guy stated, was that he was much more
proficient in PHP than in Ruby and his environment was a
PHP-environment. As it is entirely possible to write good Software (and
Frameworks) in PHP, so I do support his reasons. But they are heavily
bound to his environment, so his reasons might not be the applicable to
yours.

Greetings
Skade
 
C

Chad Perrin

Ruby scales just fine as long as you are willing to throw a ton of
compute hardware at it !

I believe Twitter is successfully using Ruby for their site but then
they have also invested in a ton of servers dedicated to running
hundreds of Mongrels.

So yeah, get out your checkbooks and write more checks for more
servers and sure Ruby scales just fine !

Assuming about an 80k salary and a 2,000 dollar server, a server is worth
about 50 hours of programmer time.

I just figured I'd provide a simple starting place for comparing the cost
of software development with that of hardware upgrades.
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Members online

No members online now.

Forum statistics

Threads
473,744
Messages
2,569,484
Members
44,903
Latest member
orderPeak8CBDGummies

Latest Threads

Top