Richard Conroy
9/13/2006 1:15:00 PM
On 9/13/06, Bira <u.alberton@gmail.com> wrote:
> On 9/13/06, Richard Conroy <richard.conroy@gmail.com> wrote:
> > IMO "For Performance, Write it in C" taken as it is written, seems
> > like a copout. If you are considering a language/framework/whatever
> > as your candidate for a new project, you usually want the answer
> > to be singular.
>
> That's just the thread's title, and if I recall correctly you've just
> restated one of the very first dissenting arguments that were
> presented in it. It's really best to read the original from the
> archives rather than repeating the entire discussion :).
And if you take it back into the context of this thread, and some
of the arguments that were raised here, dropping down to C
pisses all over your developer cycles and makes a load of its
own problems too, especially if you really need platform
independence or don't have the staff who are confident to write
the C stuff.
"For Performance, Write it in C" really means "Do Without That Feature"
for a lot of people. If people suspect that they need a lot of those
DWTF's in their web app, then arguments for Rails start to look
shaky (and this is On-Topic for *this* thread).
I already hit upon an example that joel mentioned (in-HTML graphing).
I noticed that DHH made a really crap attempt at countering that.
One time image resize? WTF? Why couldn't he have just showed
the Railsy way of doing HTML graphing in a performing way or just
admitted that there was no Ruby+Rails ONLY way of doing it.
Also for people who look at languages that are evolving,
"For Performance, Write it in C" means "Get Lost, be happy with
its current level"
I went through the evolution of Java during its early days, which
was hyped as cross-platform for free, and twice as productive
as C++ to develop in.
Then the benchmarks rolled in, with Java looking 20x slower than
C++ or whatever and the same "fixes/arguments" were proposed:
-write it in C, call through JNI (aka ditch dev cycles & WORA)
-developer cycles are more important
But what also happened, while all the arguing was going on,
was that the performance aspect got itself fixed. People beavered
away at it, released specs and eventually pre-release runtimes
that were faster. Basic CPU utilisation issues simply dissappeared,
so that you could write various looping, parsing, string manipulatation
tasks without having to heavily optimise them afterward.
I think the Jython community had to go through similar stuff, but
I can't recall it too well, but in the end they just fixed their performance
issues.
Currently there is nothing on the Ruby radar for that. I mean Ruby
2.0 is in early discussion phase, and there seems to be something
inherently risky about using the alternatives (JRuby and YARV(?) )
in a production Rails project.
While I am comfortable enough that issues like multinational Rails
will disappear from the concern list over the next year (by people
implementing successful multi-national Rails apps with stuff like
Globablize and blogging their results), I don't see performance
going away soon.
Nobody expects to start writing scientific research algorithms
in Ruby, but they want the confidence that extended looping,
XML parsing or whatever-formatting will still work without
requiring heavy optimization right off the bat. They want to
write their code the way they are used to and keep their
developer cycles, and not have to bother about optimising
until later in the project, rather than later in the day.