5 ms·

I'm the author of the original post. I agree that I/O is going to be slow in any language, so I agree with you there. However, your point about a single serve

• moe 17y ago
  Now we're not talking pennies anymore. We're talking tens of thousands of dollars. Do the math. If 4 devs cost $1500 in a day then "tens of thousands of dollars" is not much in comparison. I think you, like many devs including myself, might be suffering from "big figure anxiety". A $50k investment for a rack looks mighty intimidating at first. But break it down in excel and in most cases you'll find it turns out way cheaper than the alternatives (e.g. hiring a few "C experts" or "spending a month on optimizations").
  • scumola 17y ago
    Let's say that servers cost $1500 each and a rack of 20 servers costs $1500/mo for hosting costs. Programmers make $80k/yr. Let's also say that C is twice as slow to develop for and let's say that Java requires twice as much hardware to run. One java programmer writes an app that takes a rack of equipment to run and writes it in 6 months. Meanwhile, a C programmer takes 12 months and only 1/2 rack of machines. After a year, the java app costs $40k in programming costs and an initial cost of $60k for hardware, so $100k. A year later, hosting costs rack up another $18k. The C app costs $80k in programming costs, $30k for hardware, so $110k. A year later, hosting costs rack up another $9k, so we're about even. You may argue that C takes > 2 times to write, and I will argue that java bloat requires more than a 2x hardware purchase, so we're talking pretty much a wash here. I don't think that your cost argument holds much water.
    • InclinedPlane 17y ago
      You're missing the key points. The most important determining factor for the hardware footprint and overall throughput performance for the vast majority of web applications is not in the front-end but in the database. It doesn't matter if you write your front-end in C, PHP, or even LOL code the database calls are still going to dominate the hardware needs and performance characteristics of your application by a factor of 10-100. Spending your entire development budget to shave 10% or 1% of your hardware and performance overhead down to 5% or 0.5% is silly, which is why nobody does that. Moreover, going down the list of low hanging fruit in terms of reducing cost and rendering time per page-view the option to switch to a "more efficient" language is so far down the list that it's almost never reached. Indeed, it's often more important to switch to a language that makes it easier to scale out to more hardware than it is to switch to a language which is abstractly faster at individual optimizations (again, macro-optimization trumps micro-optimization). The biggest performance improvement efforts tend to be orthogonal to development language entirely. For example, tuning your database design and DB server parameters, using extensive caching, cutting down on http request overhead, etc. It's telling that a company like facebook (which has no shortage of developer talent) chose to spend its efforts on making PHP faster by building a new compiler for it rather than moving away from PHP to some other hypothetically more efficient language. Efficiency is an important factor in web development, it can affect end-user performance, costs, and profitability. But it's rarely as significant as many people make it out to be. It's more important to build something that people care about than it is to build something extremely efficient. For the vast majority of sites, increasing the popularity of your site by 10-100x is far more important than reducing the server footprint by 2x, or even 10x.
    • moe 17y ago
      Well, I can only second what InclinedPlane already said and would like to add: While your idealized calculation [naturally] supports your point, it doesn't match up with what I've seen in reality. In most companies you don't have one programmer per rack but many programmers per rack. The hosting costs are usually dwarfed by the programmer salaries, often as much as to make the former appear as a rounding error. Consequently you should in almost all cases optimize for developer-performance, not for software performance.