6 ms·

Ranting aside, this seems like a valid complaint. Scaling and performance seem to be reasonably important in web applications, so why not write them in C? If th

Ranting aside, this seems like a valid complaint. Scaling and performance seem to be reasonably important in web applications, so why not write them in C? If the only complaint is the lack of good tools, why not build those tools? Disclaimer: I don't actually work on web apps, and therefore have no experience with these things.

burke 17y ago
The increased productivity of writing in a scripting language typically outweighs the cost of extra servers. Whereas with a desktop application, you only have X resources to allocate to a task, you can always "just throw more servers at" a web application to some degree. It is done occasionally though; last I heard, large portions of Amazon.com were written in C.
sounddust 17y ago
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 mitigate these problems are already written in C (memcached, etc).
- zepolen 17y ago
  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.
  - bad_user 17y ago
    > Once you lower the the db io issues ... 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.
  - swombat 17y ago
    Reread what you wrote :) Once you lower the the db io issues, rendering does become the bottleneck. Not really. Sending and receiving data to/from the browser becomes the bottleneck. If it takes 50ms to receive the query from the browser, 0.1ms to retrieve the data from the cache, 10ms to render it, and another 50ms to send it back to the browser - the bottleneck is now network communications with the browser. There are, unfortunately, limits on how much that can be improved.
    - zepolen 17y ago
      App servers don't handle the spoon feeding of clients, front end webservers do, at least in any sane architecture.
vidarh 17y ago
Because most scaling problems in web apps are ultimately architectural. Yes, you may need to buy a second server sooner rather than later if you run Ruby instead of finely tuned C or C++, but for most apps you're going to need to worry about a second database server and replication before that, and long before reaching either you will have enough traffic that you'll need to prepare to handle front-end scaling properly soon anyway. An example - from messaging middleware, not web frontends since it's somewhere I do have proper data: I did a messaging middleware system in C a couple of years back. It's easy. I've done it before. After a while needs were changing and I decided to try writing the replacement in Ruby. It was a lot quicker to write (1/10th of the code size for roughly the same feature set). We were handling 3-4 million events a day, which could easily result in 2-10 messages each. The Ruby replacement spent 10% of a single 2Ghz Xeon core handling those messages. Of that 90% was spent in the kernel handling system calls that would've been roughly the same in a C/C++ version. Even if the Ruby part of the equation was 10 times slower for the userland part, the most we'd have saved for our load was 0.9% of a single core. The most we'd save overall, regardless of scale, would be around 9-10%. Doesn't mean there aren't things for which a language like C is better suited - I did my MSc. thesis on reducing error rates for OCR, and some of the image processing I did was prototyped in Ruby, but then translated to C for the final version because processing literally would've taken days for things that took less than an hour in C. But scaling is very often constrained by other things than the performance of the laguage you write your app in. Especially in the web space where most interesting apps are database backed. If your DB gets maxed out, having a hyper-optimizing compiler is not going to help you. If your app isn't designed to be scale across multiple servers (or at least cores - these days you can rent managed hosting on a 24 core server for less than $1k/month) you could very likely be screwed in ways that no compiler will save you from. The extra developer time spent doing web development in low level languages is unlikely to be worth it unless you're at a massive scale. If you can fit in 24 cores with a language like Ruby, your best case saving from switching to a compiled language these days is around $10k/year on hosting if you're ok with a single server, and about $20k if you want redundancy. That doesn't pay for a lot of wasted developer time. Most web apps can fit in that, and for the lucky (or unlucky, depending on reason) that need to scale beyond that, the CPU time spend on the actual web app is likely to be a relatively small fraction of the total CPU time spent (on databases etc.) - architectural decisions is likely to be a far more important cost driver than the language of the web frontend. As for developer availability - good luck to him finding good C programmers, and even more so finding good C programmers who aren't expensive and knows web development.
cromulent 17y ago
To me, C makes a lot of sense for software that doesn't change all the time. The point in the article about being an engineer is valid. However, most website projects are business-driven, which means that you are constantly changing and refactoring stuff as misunderstandings get cleared up, design flaws emerge, business models change, minds change, etc etc. Business software projects are not just engineering, and if you treat them as such you will endure pain. The analogy with a house is odd - if a house was purely an engineering problem, then they would probably all be built out of precast concrete or something, not "wood and steel". Aesthetics, tastes, budgets, and tradition all have an impact, and nearly every house is unique, so you use the "best tool for the job" - the one that is the easiest to customize on-site.
- piramida 17y ago
  True, if house building was business-driven (instead of solely architect-driven) then it would make more sense to use materials more suitable for iterative process. Like cardboard boxes... When requirements change weekly and by the projects end your original project description is only useful as a piece of history - then using concrete would mean lots of demolition work in the process.
weavejester 17y ago
The usual performance bottleneck in a website is the database, which is usually written in either C or C++ anyway. Other parts of a web application are less likely to cause performance issues, and can usually be scaled horizontally by adding more servers.
eli 17y ago
But the DMBS is written in C (or similar). And that's usually where the heavy lifting takes place.

burke 17y ago

The increased productivity of writing in a scripting language typically outweighs the cost of extra servers. Whereas with a desktop application, you only have X resources to allocate to a task, you can always "just throw more servers at" a web application to some degree. It is done occasionally though; last I heard, large portions of Amazon.com were written in C.

sounddust 17y ago

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 mitigate these problems are already written in C (memcached, etc).

zepolen 17y ago
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.
- bad_user 17y ago
  > Once you lower the the db io issues ... 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.
- swombat 17y ago
  Reread what you wrote :) Once you lower the the db io issues, rendering does become the bottleneck. Not really. Sending and receiving data to/from the browser becomes the bottleneck. If it takes 50ms to receive the query from the browser, 0.1ms to retrieve the data from the cache, 10ms to render it, and another 50ms to send it back to the browser - the bottleneck is now network communications with the browser. There are, unfortunately, limits on how much that can be improved.
  - zepolen 17y ago
    App servers don't handle the spoon feeding of clients, front end webservers do, at least in any sane architecture.

vidarh 17y ago

Because most scaling problems in web apps are ultimately architectural. Yes, you may need to buy a second server sooner rather than later if you run Ruby instead of finely tuned C or C++, but for most apps you're going to need to worry about a second database server and replication before that, and long before reaching either you will have enough traffic that you'll need to prepare to handle front-end scaling properly soon anyway. An example - from messaging middleware, not web frontends since it's somewhere I do have proper data: I did a messaging middleware system in C a couple of years back. It's easy. I've done it before. After a while needs were changing and I decided to try writing the replacement in Ruby. It was a lot quicker to write (1/10th of the code size for roughly the same feature set). We were handling 3-4 million events a day, which could easily result in 2-10 messages each. The Ruby replacement spent 10% of a single 2Ghz Xeon core handling those messages. Of that 90% was spent in the kernel handling system calls that would've been roughly the same in a C/C++ version. Even if the Ruby part of the equation was 10 times slower for the userland part, the most we'd have saved for our load was 0.9% of a single core. The most we'd save overall, regardless of scale, would be around 9-10%. Doesn't mean there aren't things for which a language like C is better suited - I did my MSc. thesis on reducing error rates for OCR, and some of the image processing I did was prototyped in Ruby, but then translated to C for the final version because processing literally would've taken days for things that took less than an hour in C. But scaling is very often constrained by other things than the performance of the laguage you write your app in. Especially in the web space where most interesting apps are database backed. If your DB gets maxed out, having a hyper-optimizing compiler is not going to help you. If your app isn't designed to be scale across multiple servers (or at least cores - these days you can rent managed hosting on a 24 core server for less than $1k/month) you could very likely be screwed in ways that no compiler will save you from. The extra developer time spent doing web development in low level languages is unlikely to be worth it unless you're at a massive scale. If you can fit in 24 cores with a language like Ruby, your best case saving from switching to a compiled language these days is around $10k/year on hosting if you're ok with a single server, and about $20k if you want redundancy. That doesn't pay for a lot of wasted developer time. Most web apps can fit in that, and for the lucky (or unlucky, depending on reason) that need to scale beyond that, the CPU time spend on the actual web app is likely to be a relatively small fraction of the total CPU time spent (on databases etc.) - architectural decisions is likely to be a far more important cost driver than the language of the web frontend. As for developer availability - good luck to him finding good C programmers, and even more so finding good C programmers who aren't expensive and knows web development.

cromulent 17y ago

To me, C makes a lot of sense for software that doesn't change all the time. The point in the article about being an engineer is valid. However, most website projects are business-driven, which means that you are constantly changing and refactoring stuff as misunderstandings get cleared up, design flaws emerge, business models change, minds change, etc etc. Business software projects are not just engineering, and if you treat them as such you will endure pain. The analogy with a house is odd - if a house was purely an engineering problem, then they would probably all be built out of precast concrete or something, not "wood and steel". Aesthetics, tastes, budgets, and tradition all have an impact, and nearly every house is unique, so you use the "best tool for the job" - the one that is the easiest to customize on-site.

piramida 17y ago
True, if house building was business-driven (instead of solely architect-driven) then it would make more sense to use materials more suitable for iterative process. Like cardboard boxes... When requirements change weekly and by the projects end your original project description is only useful as a piece of history - then using concrete would mean lots of demolition work in the process.

weavejester 17y ago

The usual performance bottleneck in a website is the database, which is usually written in either C or C++ anyway. Other parts of a web application are less likely to cause performance issues, and can usually be scaled horizontally by adding more servers.

eli 17y ago

But the DMBS is written in C (or similar). And that's usually where the heavy lifting takes place.