Web Applications Should Be Compiled

"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.

Well, if I were forced to write in C these days, I would seriously write a C/C++ generator in Lisp to speed the time to market.

But if I could do it where nobody was watching, I would use a different compiled language, Lisp (SBCL) that would get good enough performance and get to market before the manly C/C++ coder.

So on a semi-serious note, why is (apparently) nobody going for the real performance kill, which is to write a framework in hand-coded assembler? Would it be twice as fast as C?

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. "

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.

Sounds like this guy was fucked over by a contractor.