Not a bad troll. Not the best I've ever read, but not bad, either.
First, this isn't a troll. The guy posted a blog post on his own blog. He didn't post off-topic content to a thread and didn't try to provoke an argument in an otherwise civil conversation. The only possible way that you can characterize this as a troll is that he uses some crude language, and says some things that are unpopular on HN. But say what you will about the content, he didn't try to make you read it.
Second, the guy has a point. I've had a rant like this building in my craw for a long time, and this guy nailed nearly every point I've wanted to make. From a software engineering perspective, web development is in the dark ages. What's worse, it's a luddite process -- a totally self-made exile from the benefits of 50 years of progress: Type safety is shunned. Language efficiency is ignored. Data structures beyond the hash table are exotic and rare (and worse, I've met more than one "professional" web developer who couldn't tell me the difference between open and closed hashing!)
I understand very well that programmer time is more valuable than computer hardware, and that the speed/development time trade-off is often biased toward development time. But if you ask me, what was once an intelligent guideline is now becoming a cult. It is possible to do rapid development in a compiled language, and there are some really good reasons -- beyond execution speed -- to revisit the idea.
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.
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.
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".
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.
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.
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.
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.
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.
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.
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.
(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.)
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?
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.
But what I don't agree is using just C. C is too low level and is a horrific unfit task for web development. Instead C++ would be a good fit (and writing in C mixed in). The STL/Boost provide a wonderful abstraction layer that does pretty much anything you throw at it with ease, plus there are lot of other libraries for anything else you can ever think of. I've written several web applications in C++, and it was actually very much like writing in Python/PHP/Ruby and at time prefered writing it in C++ after writing a poc in a scripting language. They were just a little bit less readable but very clean, but the biggest plus the the multiple magnitude performance increase of the application it self with FastCGI. (all these applications were serious number crunchers and had lot of CPU and Memory Bound problems).
tldr; C for web dev painful, C++ with STL/Boost good/easy/fast/clean.
Also I've heard of wt, a C++ web framework although I've never used it http://www.webtoolkit.eu/wt
The old blog software, Typo, is nowhere near as good as Wordpress. I only used it because it was written in Ruby on Rails and I am a Ruby on Rails coder. This is a very poor means of choosing software.
SSP results in web pages as compiled machine language.
The HTML file is translated into a new Smalltalk method, the tags become Smalltalk message sends, and the HTML between the dynamic tags just become accesses into an Array. Because Array access is optimized and JITed as machine code, the only message sends are due to the dynamic tags. When the webpage/method is JITed, you have a web page compiled into machine code.