Item — HN Reader

"Your comment adds less to an intelligent discussion than does the article you're calling a troll."

Sometimes the truth is very simple. It can be considered a troll because it is in the tone "if you don't do as I say you are an idiot, like everyone else".

Second: not all scripting languages are interpreted on the fly. In fact, many of the most popular frameworks load objects once and keep their compiled forms in memory. Even for languages that run under VMs, some of them run under JIT that, in the end, results in machine-language-like times.

Third: I have profiled a lot of web applications and most of the time they are either waiting for the pipe to deliver a request or waiting for the database to deliver the data. Very few web applications I know of do heavy processing. For those, I agree compiled code may help.

and, finally, by the time the guy finishes his C code, an equivalent competing application that uses Rails will be approaching the millionth registered user.

2 comments

Even though the tone of the article was abrasive, it was far more interesting and insightful than the one-line comment to which I responded. Your asserted arguments for dynamic languages are well-trodden ground:

Assertion: "Some scripting languages are as fast as compiled languages."

No, not really. I challenge you to prove that statement with a non-trivial benchmark.

Assertion: "most of the time, web apps are waiting for something external to respond"

This doesn't survive a few seconds of thoughtful analysis. If a web app is spending most of it's time blocking for I/O, it's poorly designed. There's no reason that it can't be handling other requests while waiting for a DB response or a pipe. And once you've allowed for that possibility, you're back to a situation where you can handle more requests with faster software.

Empirically, this is obviously true: languages like Ruby and Python don't hold a candle to Java when it comes to web application speed. We choose them because of developer convenience, nothing more. Which brings us to...

Assertion: "C programming is terrifically slow for development. <insert snarky comment about Rails applications with a million users here>"

Ignoring the fact that there are other compiled languages than C (that are probably better choices for web development), I can tell you from experience that by the time your Rails app reaches a million registered users, 80% of your week is going to be spent either working around the myriad scalability flaws in Rails and the dog-slow nature of Ruby, or installing hardware to accommodate the load. Scaling Rails is a nightmare.

Now, it may be true that you can develop that Rails app a bit faster than you could a webapp in a compiled language, but it's a wild exaggeration to suggest that the difference is more than a few weeks of skilled developer time. It's a fallacy to imply that all compiled-code projects end up in death-march hell. Truth be told, the real reason that web apps can be written so quickly is because they're easy, and they tolerate a lot of development error. So long as there are good string processing facilities, the choice of language is a fairly minor point.

"Scaling Rails is a nightmare."

I find this similar to Woody's fear in the following exchange:

Cliff Clavin: Boy oh boy, talk about your lucky days, huh, I just found twenty smackers back there in the pool room. And to celebrate my good fortune, I'm going to buy a round a drinks for all my friends.

Carla Tortelli: What are you going to do with the other nineteen bucks?

Sam Malone: Woody, that could be your twenty dollar bill, the one you lost.

Woody Boyd: Hey yeah, you know I was in the pool room earlier.

Cliff Clavin: Hey, wait a second. Let's be fair about this. Give me the serial number.

Sam Malone: Oh, come on man. Nobody knows serial numbers.

Woody Boyd: L21886119B

Cliff Clavin: [hands the bill to Woody] That's amazing.

Sam Malone: How did you do that?

Woody Boyd: I memorize the serial numbers on all my currency.

Sam Malone: Why?

Woody Boyd: For just such an occasion. Tell you though, I pray every day I don't get rich.

http://www.imdb.com/character/ch0003010/quotes

Not quite a perfect analogy, but my point is worrying about scaling is a very good problem to have, and is likely to be accompanied by the resources to fix it. Twitter is the poster child for Rails scaling problems, but they re-wrote the parts they needed to write, and people kept using it because they liked the service even when they did have scaling problems.

Twitter isn't really the poster child for Rails scaling. A huge chunk of their traffic isn't handled by Rails, and their web interface is fairly perfunctory.

In any case, at this point I think it's fairly safe to say that I have some direct experience scaling Rails, and it's not as easy as the hand-wavers suggest. It's certainly worth a bit of work early on to avoid the nightmares that come with trying to scale something like Rails later on.

Not to be too silly, but if someone wrote a web framework in C++ that was 10% more difficult than Rails, I'd still consider it. The distribution of suck for Rails is exponential over time, so the expected value of suck is much higher than it initially seems.

"A huge chunk of their traffic isn't handled by Rails, and their web interface is fairly perfunctory."

I guess I wasn't clear enough. I meant they rewrote the parts that didn't scale in another language. Scala, I believe. Is that incorrect?

So, my point then is that writing it in Rails to quickly get it in front of users and quickly iterating on features turned out to be worth it, even though they had to rewrite large portions in another language once they had a lot of users. Do you disagree? I'm not a Rails developer, but this is my understanding of how Twitter development played out, and it seems to have worked very well for them.

I'm curious, if you would accept 10% more difficult, would you also accept 20%? 50%? I'm wondering just how exponential the suck can get.

"There's no reason that it can't be handling other requests while waiting for a DB response or a pipe."

Concurrent request processing most likely belongs in the server, not in the application.

"Scaling Rails is a nightmare."

For someone who complains of "well-trodden ground" in others' arguments, you certainly seem to have a deeply-rooted belief in the myth that particular languages and/or frameworks "scale" or "don't scale".

Is it a still just a belief in a myth if you've experienced it first-hand?

OK, so show me a language or framework which has a button you push, or something similar, to scale without any hassle.

The lack of a push-button solution for all scaling problems does not mean that Rails doesn't suck at scaling.

So how do you figure that it sucks? And don't say "Ruby is too slow" or I really will write you off as reciting tired old myths.

Write me off if you like, but here's a short list (just off the top of my head) that we've encountered while trying to scale Rails:

Rails has terrible support for database replication (we've had to roll our own). Its caching architecture is laughably bad, and the implementation was/is buggy (again, we rolled our own), and there's next to no support for the kind of robust page cache expiration mechanisms that are necessary to run a large, dynamic site (Observers are only a start). Rails is a memory hog, takes too long to start, has poor translation and locale support, and simply passing a request through ActionController adds huge overhead that cannot be escaped.

And even though you don't want to hear it, Ruby is slow -- even after working around all of the above, we still had to implement a fast page caching layer just to work around the general, all-purpose slowness of Ruby.

But like I said, write me off if you want.

"If a web app is spending most of it's time blocking for I/O, it's poorly designed. There's no reason that it can't be handling other requests while waiting for a DB response or a pipe"

If your request-handling logic is responsible for concurrent requests, your application (and the platform it runs on) is poorly designed. This belongs to a thread/process dispatch mechanism in the platform, not inside your app. When one thread waits for the database, I am sure the processors can be busy with other requests.

"Scaling Rails is a nightmare."

No. It's not. There is little reason for it to be. While I am no Rails expert (I use Django and was a Plone guy not that long ago), the scalability issues most people have happen because of RDBMS concurrency much more than any problem with Rails itself. Like I said before, that time spent waiting for the database to respond is time spent in the database working. It is incredibly rare to have a front-end having heavier usage than the database that feeds it.

If you want your applications to scale, design it around the database limitations. Use C, C++ (I would prefer ObjC), Java or Assembly if you want, but faster request processing won't get you past database scalability issues.

Using C* or Java will only push back your release date.

In my experience once you get over a few hundred thousand users and have tweaked your web server/proxy setup and tuned your database, you will still have major slowness and memory issues with your Rails code. I.e. it's usually not the database's fault.

Also you might want to look at the profile of the guy who said that rails scaling is a nightmare. I wouldn't use the word nightmare as I'd prefer to think my professional life story wasn't written by Kafka. But, I don't know anyone who has scaled a big Rails site and thought it was a pleasant or fun experience. Most guys who say that it's no big deal haven't really done it.

I will concede that, according to my very limited Rails experience, it generates a lot of database chatter when compared to hand-coded queries. Still, this is mostly a database scaling problem.

The beauty of the ORM is that you can replace the underlying layer without disrupting the code running on top or add fancy things like local memory caching or a networked memcached store. I insist that if your application was built from the start with this kind of issue in mind, it will be easy to scale it if and when the time comes. Until then, you are solving a problem you don't know you have.

This gets harder the lower-level your language gets.

Did you just write that most web-apps aren't I/O bound? Because that sounds completely backwards.

No. Obviously, any individual request/response is I/O bound. But the server doesn't have to be I/O bound.

The top line in a gprof profile of an evented C web server had better be select() (or equivalent) or read() (or equivalent). So I don't follow you here.

Yes, the average server thread is going to spend far more time blocked on I/O than not. But the server should be able to handle more than one request simultaneously.

(Or you can use an event model; the point is, if your server is spending all of its CPU time blocked while under load, then something is wrong.)

Now you're not following me, timr. An evented server can handle 10,000 connections simultaneously. Run it under load, profile it. Select is at the top of the profile. The program spends all its time in the kernel, waiting on I/O.

That evented server is also faster than the threaded version of same.

What's the compute task you think a program is bottlenecking on in an application that does nothing but shovel data out of a database into a socket based on a btree key?

You're overgeneralizing. Where your server spends its time depends entirely on the profile of your app. If your pages render (on average) in less time than they wait for I/O, then your server will spend most of its time blocked on I/O.

I suspect that you're thinking of something like a lightweight proxy server, that waits for incoming requests, then quickly hands them off to an app server that does most of the work. That's trivial. If you just profile just the webserver process, then yes, you would expect that most of its time would be spent in wait. But while the proxy server is blocked on I/O, the app server is doing a ton of other things for any non-trivial page rendering.

This is worth repeating: only small part of request lifetime is spent in application code so you should worry about performance of the programming language only if you profiled your app and saw, that this is indeed a bottleneck.