From: Richard Conroy Date: 2006-09-13T22:14:58+09:00 Subject: Re: Joel Spolsky on languages for web programmingr On 9/13/06, Bira wrote: > On 9/13/06, Richard Conroy 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.