51–60 of 177 posts
It's a valid point. I wrote the Mibbit backend from scratch in Java for these reasons. I can only start to imagine the horror I would be enduring if I'd chosen a scripting language. Having said that, choose the right tool for the job. edit: Downmod me all you like. A scripted language wouldn't handle 2k req/sec on a couple of VPSs.
Bloggers, please try a kinder, gentler tone, one that suggests you and I are colleagues. One that suggests you have discovered some neat thing and won't I have a look at it and isn't it interesting to play "what if" games with it and maybe, just maybe I might experiment with it.
Looking back on my own posts, I would say the strongest ones are those where I found a more reasoned voice. An essay can be strongly opinionated without being imperative.
It's a valid point. I wrote the Mibbit backend from scratch in Java for these reasons. I can only start to imagine the horror I would be enduring if I'd chosen a scripting language. Having said that, choose the right tool for the job. edit: Downmod me all you like. A scripted language wouldn't handle 2k req/sec on a couple of VPSs.
But as your web application database grows more complex and larger, how do you intend to make them keep up with the 2k req/sec load?
People often seem to think a db is the only way to write any webapp, and that everything must depend on the db. That's bad architecture.
In the case of Mibbit, db access is only done for writes, lazily, in the background.
The bottlenecks for me, are CPU, network, and ram. And yes, you can throw servers at it, if you're frivolous and don't intend to make any money. I decided to go the other way and be profitable ;)
Arguably, all the languages that show up down near C in the Shootout would be fine languages to write webservices in, since nearly all of them are as fast as C without the eXtreme danger.
Some web services are "shovel strings from the DB out to the user", like CMSs, but for those that aren't, this isn't a terrible point.
(It's easy to forget when you're the type of person who hangs out on HN, but for most people, compiled == C, or C++ if you're lucky.)
Personally I'd go with perl - as thats the language Im most comfortable with.
I'm not sure I'd throw away the scripting languages entirely, but making it easy to integrate c or c++ into these languages in this manner is probably a good idea. It's not that hard to write very highly optimized c++ and it can have a huge impact on performance... at least that has been my experience.
While the article was inflammatory, I think the guy has a valid point. He just needs better people skills ;)
Earlier quoted context omitted.
If your site starts to take a performance hit in rendering pages, you can simply write a module in C to handle the part of the script that's using an excessive amount of CPU time, and keep the rest in script. But for most web apps, rendering HTML pages from script is not the bottleneck, it's the interaction with the database, and the solution is intelligent caching to reduce load on the database. The tools to mitigat…
Reread what you wrote :) Once you lower the the db io issues, rendering does become the bottleneck. Luckily rendering scales just by adding more servers. Rewriting templating code in C though rarely adds more speed, most dynamic languages tune their string handling as much as possible. Also, utilizing http caching mechanisms are a (quite underused) great solution for lowering load.
It is highly unlikely that happens. Once you lower your DB issues, if the application is responsive enough you start working on other features. By the time you're done the application got new users and the DB is a problem again ... it's a cycle :)
Fortunately HTTP servers do scale by caching and load-balancing.
The author of the post probably never worked in real-world conditions. You first have to have users and real needs for scaling, and that doesn't happen unless you deliver a useful application first, and you also have to deliver it pretty fast, otherwise you might lose to a competitor with the same idea.