Re: Joel Spolsky on languages for web programmingr

Ruby
1

Ah, yes, the increasingly blurry line between Languages and their
Standard Libraries is fast becoming a sordid love-triangle between
Languages, their Standard Libraries, and their Virtual Machine. I
suspect Microsoft did themselves a disservice when they started calling
all of their products Dot Net. It has caused just as much confusion as
it would if I were to start calling all of my employees George.

It appears that when Kate refers to .Net, she is referring strictly to
the CLR (Common Language Runtime, technically an abstract machine) that
executes the bytecodes that result from compiling a (for example) C#
application. However, the CLR is not easily divorced from the " .Net
Framework ", a very large class library which includes complete support
for ASP.Net web development, and is arguably a “web framework”. The CLR
relies on classes in the .Net Framework, which in turn relies on
services in the CLR, in a somewhat incestuous relationship.

Kate, I gather it annoys you just as much as it annoys me when people
refer to writing VB.Net or C# code as “Writing in .Net”. Please be
careful not to make a similar mistake by equating .Net with the CLR.
ASP.Net is a complete web framework, and although it is IMHO old and
cranky and becoming frail in its advancing years, and not nearly as much
fun as Rails, in its youth it served its purpose well, to provide a web
framework that still looked like simple ASP, with a “Visual
Component”-based API that, while not ideal for web development, was very
comforting to the hordes of Visual Basic developers migrating to the
.Net platform.

Frank

2

On Wed, Sep 13, 2006 at 11:14:41AM +0900, Frank Davis wrote:

Kate, I gather it annoys you just as much as it annoys me when people
refer to writing VB.Net or C# code as “Writing in .Net”. Please be

Of course, she was the first to say “in .NET”, as I recall. The rest of
us were talking about writing for .NET, or developing with .NET – not
“writing in .NET”. If that was the point of contention, she completely
misunderstood what was being said before that.

(assuming “Kate” means “she”)

3

Bringing the debate back on topic,

Joel revisits his claims in his original article, particularly
the Ruby-is-slow claim.

4

On 9/13/06, Richard C. [email protected] wrote:

Bringing the debate back on topic,
Ruby Performance Revisited – Joel on Software

Joel revisits his claims in his original article, particularly
the Ruby-is-slow claim.

I’ve read that - aren’t his arguments a bit out-of-date, in the sense
that they’ve been answered on this list several times? More
specifically, I’m thinking of that huge “For Performance, Write it in
C” thread, in which the conclusion seemed to be that the choice of
algorithm had a much greater impact than the choice of language.

5

On 9/13/06, Richard C. [email protected] 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 :).

6

On 9/13/06, Bira [email protected] wrote:

I’ve read that - aren’t his arguments a bit out-of-date, in the sense
that they’ve been answered on this list several times? More
specifically, I’m thinking of that huge “For Performance, Write it in
C” thread, in which the conclusion seemed to be that the choice of
algorithm had a much greater impact than the choice of language.

Haven’t read those threads - I scanned them a few times like I did
with the unicode ones, but I got out quick. I am thick-skinned but
not fireproof.

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.

Language hybrid projects are rarely fun, especially if the second
language
came in unforeseen, or as a workaround to a problem that the first
couldn’t deal with.

The language bridge and marshalling can end up dominating the design
and dumbing down the strengths of your original language choice.

7

It is not just the choice of algorithm that can affect performance, even
greater performance boosts can be had at the design stage. A bad design,
ie doing unnecessary work, will cripple any implementation / language.
If the data being passed through your system is being processed in any
way that is unnecessary to the task at hand then it does not matter how
efficiently it is doing that unnecessary task.

When you are looking at systems rather than programs the performance
boost will come from the design (or architecture as some people like to
call it). It’s a rare designer that can say “we don’t need to do that”
or “that is not a feature, it is an encumbrance”. People seem to confuse
sophistication with complexity. Complexity is bad.

If you take a framework in one language and reimplement it in Ruby then
it is quite likely that the Ruby version will be much slower, no
surprise here. However if you take the problem the framework was being
used to solve and solve it from scratch in Ruby you will get a much
better result.

8

DHH tore him a new one last night:

http://www.loudthinking.com/arc/000598.html

9

On 9/13/06, Bira [email protected] wrote:

On 9/13/06, Richard C. [email protected] 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.

10

On 9/13/06, James Edward G. II [email protected] wrote:

James Edward G. II

What are their release dates? Have all of the library/ plugin and
existing code problems been addressed? How Rails compatible
are they? Has the rush to be version compatible with various
libraries introduced any exploits? Can I patch my customers
installations right now?

Basically “How soon can I hot swap my interpreter in my rails
app with No ill effects”.

I am talking about how long it takes to:

  • produce a X.0.0 revision
  • produce a version with all the library issues worked out by the
    community
    (either a X.0.(1…n), or more correctly, rev all the main libraries)
  • build confidence in a particular version

These processes take time. Less than 12 months seems woefully
optimistic. 18-24 months maybe? Longer?

11

On Wed, 13 Sep 2006, Richard C. wrote:

What are their release dates? Have all of the library/ plugin and
existing code problems been addressed? How Rails compatible
are they? Has the rush to be version compatible with various
libraries introduced any exploits? Can I patch my customers
installations right now?

Basically “How soon can I hot swap my interpreter in my rails
app with No ill effects”.

You can’t. You won’t be able to. Fortunately, Ruby encompasses a much
larger world than Rails. The Ruby that YARV runs is different from your
1.8.4 or 1.8.5 ruby version, and Rails will have to change to accomodate
it, not the other way around.

Kirk H.

12

On Sep 13, 2006, at 8:14 AM, Richard C. wrote:

Currently there is nothing on the Ruby radar for that. I mean Ruby
2.0 is in early discussion phase…

$ ruby_yarv -ve 'puts “In the early discussion phase!”'ruby 2.0.0
(Base: Ruby 1.9.0 2006-04-08) [i686-darwin8.7.1]
YARVCore 0.4.1 Rev: 527 (2006-07-19) [opts: [direct threaded code]
[inline method cache] ]
In the early discussion phase!

James Edward G. II

13

On 9/13/06, Richard C. [email protected] wrote:

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.

As I’ve said before “For Performance, write it in C” is merely the
thread’s title. What actually went on in there is that a lot of people
disagreed rather strongly with this proposal and presented several
alternatives that presented satisfactory performance both in Ruby an
in other languages (the Ocaml example comes to mind as being faster
than the C one for a specific test case).

When I say that you should read that thread, it’s not because I want
to convince you to “write it in C for performance”. I don’t. I’m just
pointing out that an extensive discussion on Ruby’s performance and
what is being done to improve it has already taken place. If it’s
something you’re really interested in, you should look at it, since it
contains many good messages from both sides of the issue.

14

On Sep 13, 2006, at 9:53 AM, Richard C. wrote:

In the early discussion phase!

James Edward G. II

You are changing your story below. I will try to address your
points, but you originally said Ruby 2.0 is in the early discussion
phase. I showed you a running interpreter. To me, those are opposites.

Ruby 2.0 has been in development for for years, literally. We now
have a functional VM. My opinion is that it is in late development.

What are their release dates?

I believe the current plan is to release Ruby 1.9 on Christmas,
2007. It’s a little over a year out. If you look back at how many
years it has been planned/developed, that furthers my claim of late
development.

This jump to 1.9 is basically an attempt to get an improved Ruby in
your hands as fast as possible. Everything for 2.0 isn’t ready yet,
but important people know so things need fixing sooner and we have
some solutions now. See how well your needs are being considered?

In your earlier post, you criticized Ruby because other languages are
evolving to get faster and Ruby is not. That upset me because you
casually diminished the hard work of everyone who has gone to great
lengths to make Ruby faster for years now. They are nearing the end
of their journey and you are calling for them to get started. I feel
that shows a huge disrespect for their efforts.

Have all of the library/ plugin and existing code problems been
addressed?

If all the problems had been solved, the release date would be today.

How Rails compatible are they?

I know there have been recent efforts in this direction. I believe
some progress is being made here.

Has the rush to be version compatible with various
libraries introduced any exploits?

Ruby 1.9 and up will introduce some incompatibilities. The goal is
to correct some mistakes in the language all at once, so users only
need to go through one big transition.

I’m sure language exploits are being addressed as a natural part of
the development process.

Can I patch my customers installations right now?

Ruby 1.9 is a development branch. Patch at your risk, obviously.

These processes take time. Less than 12 months seems woefully
optimistic. 18-24 months maybe? Longer?

It has taken much longer in fact. The point is that is is
happening. Some people are working very, very hard to improve Ruby
in many areas and making great progress. Others are writing emails
about how nice it would be if people tried to improve Ruby.

James Edward G. II

15

On 9/13/06, Bira [email protected] wrote:

As I’ve said before “For Performance, write it in C” is merely the
thread’s title.

My bad, knee-jerk reaction. I hope you can understand - between
all the responses generated by Joels posts, both in agreement and
against, I haven’t seen anything along the lines of:
“Heres how I did CPU-intensive stuff in my Rails app without
resorting to OS executables or C extensions”. I expected to see
one by now, especially now that Joel has backed it up with
realistic examples.

What actually went on in there is that a lot of people
disagreed rather strongly with this proposal and presented several
alternatives that presented satisfactory performance both in Ruby an
in other languages (the Ocaml example comes to mind as being faster
than the C one for a specific test case).

I read some of the thread. I missed many of the good counterarguments
then. I will drill down then.

When I say that you should read that thread, it’s not because I want
to convince you to “write it in C for performance”. I don’t. I’m just
pointing out that an extensive discussion on Ruby’s performance and
what is being done to improve it has already taken place. If it’s
something you’re really interested in, you should look at it, since it
contains many good messages from both sides of the issue.

I guess I am looking for the short form. Ruby/Rails isn’t getting
anywhere
near our project(s) unless I prove the case for it. And I have to do
that
research in between all the work I am meant to be doing.

I guess I will mine that discussion again. I would just like to know
whether certain truisms from other languages still hold, like if you
are in a pinch, unburden the memory recycler, or consider bitwise
operation. Solutions like those might just be enough - go all Yoda
on optimisation or something.

Down the line, possibly in the lifetime of our project, JRuby might
be a fallback plan with which we can preserve platform neutrality.

In the meantime I want to see what non-fallback plans I can find,
that are more appropriate in a Rails context.

16

On 9/13/06, James Edward G. II [email protected] wrote:

You are changing your story below. I will try to address your
points, but you originally said Ruby 2.0 is in the early discussion
phase. I showed you a running interpreter. To me, those are opposites.

Well no I am not changing my story, but I do switch between personal
opinion and PHB-style devils advocacy too much for my own good.
I concede that the ‘early discussion’ comment was flippant
and didn’t convey what I really meant: that Ruby 2.0 ‘community/user’
discussion was at an early stage. I have seen the proposals and
what is intended.

To properly restate my opinion:
I worry about Rails performance, for much the same reasons that Joel
identified in his original article, and followed up with on his second.
The Rails stack is fine as long as you don’t do anything CPU intensive
(i.e. use much Ruby code in your controllers). The very example that
Joel cited (HTML graphing) is precisely the issue I noticed in the first
piece of Rails code I ever wrote that was worth showing off.

I haven’t found found any satisfactory answers for ‘how much is too
much’
Ruby code in your Rails app, but I would like to know before I commit
to a project that might need it. It contributes to the perception of
‘Rails
performance’ that Joel mentioned. The fact that community driven
solutions to pure-Ruby performance are years away means that this is an
issue you are going to have to live with for some time, and you are
going to have to steer away from doing anything CPU related for the
foreseeable future.

Ruby 2.0 has been in development for for years, literally. We now
have a functional VM. My opinion is that it is in late development.

Not something I dispute - I have read some of Matz’ posts on it -
Ruby 2.0 is a significant change, and I have read his migration
plans (break stuff early and get it over with in 1.9 to make pure
2.0 migration smoother). I am going to snip your technical details,
I did know the answers, but I was speaking in PHB-mode.

In your earlier post, you criticized Ruby because other languages are
evolving to get faster and Ruby is not. That upset me because you
casually diminished the hard work of everyone who has gone to great
lengths to make Ruby faster for years now.

I was frustrated myself and it came across. It was not my intention
to dismiss the careful efforts of the Ruby-dev team. I am aware that
Ruby has a huge installed base, particularly in its country of origin
and that this is what slows down development. Keeping compatibility
and providing easy migration paths closes down convenient options for
rapid gains. Commercial language vendors take note.

But my frustration comes from the fact that ‘Rails performance’ due
to ruby performance continues to be unanswered. As far as I am
concerned Joel nailed key concerns with using Rails as a primetime
framework. I was expecting this concern to be addressed by now,
and the only place I can really expect it to be answered is here.

If I google or usenet-dive I just get the usual FUD or zealotry. I just
would like to know what experienced Railsers think about the
suitability of Rails for CPU intensive page serves (i.e. non-pure
Rails Stack, Lots of Ruby in controllers). Basically Rails outside
the sweetspot (and while we are at it, how big is the sweet spot).

And with one main caveat: you have limited or possibly zero control of
the server(s)

  • no possibility to convert slow code to C
  • no possibility of using OS features

The only code you can ship is ruby/rails code that you write, a platform
specific Ruby installer and whatever gems that have no binary component.
Maybe you are hosted and can’t even dictate your Ruby version.

I want to know if CPU intensive Ruby code in Rails controllers Is
Considered
Harmful or Risky, or is otherwise a real concern. I think it is and I
would like
to hear practical stories on it.

I would like to know how an experienced Rails developer implemented
non-trivial HTML charting or bayesian filtering withpout resorting to OS
executables or C. And also how the optimisation process hit their
developer cycles and what approaches worked for them (and what dead
ends they encountered).

If I am walking on quicksand I would like to know. I could go with Rails
and be aware of what to avoid.

17

On Wed, Sep 13, 2006 at 08:25:04PM +0900, Richard C. wrote:

Bringing the debate back on topic,
Ruby Performance Revisited – Joel on Software

Joel revisits his claims in his original article, particularly
the Ruby-is-slow claim.

My knee-jerk reactions on first reading:

  1. He doesn’t understand duck typing very damned well.

  2. His performance figures are ridiculous.

  3. He still seems incapable of understanding that it’s sometimes a
    good idea to use libraries written in a language other than the
    project’s core language.

  4. He sure is hung up on benchmarks.

  5. He backpedals very quickly in the last paragraph on his original
    suggestion that Ruby is almost universally unsuitable for production
    development.