6 ms·

My latest anti-java rant

5 points by scumola 17y ago

vital101 17y ago
"It’s not as slow as it used to be, but it’s still pretty un-optimized. It doesn’t run “close to the metal” like C and assembly does." While everyone likes to have efficiency, being readable and/or easy to use sometimes trumps it. Would you really write a program like <insert large Java program here> in assembly, just because it would be faster?
- pmccool 17y ago
  I'd go further and say that readability and/or ease of use _often_ trumps efficiency. I/O tends to be the bottleneck at least as often as CPU, apart from anything else. I agree with the point about writing in assembly language. This rant is basically arguing for speculatively micro-optimising _every line of code_ by choosing a supposedly faster language.
  - scumola 17y ago
    I'm the author of the original post. The article isn't about optimizing every line of code, it's about not being lazy and choosing a language that you might have to do a little more work in for a massive decrease in bloat and execution time. One tool isn't always the right one for every problem. Don't use a hammer to screw in a screw. Sure, the screw will go in, but with just a little more effort (using a screwdriver) the task will be done much better. It's about wasting money & resources because a programmer doesn't want to write a little extra code to manage memory or watch return codes.
    - pmccool 17y ago
      I'll put it another way. Most code isn't performance-critical. If you choose to write everything in, say, assembler, most of it will give you little or no gain. Assembler's harder to write than Java, so every line is costing you money, whether it actually runs faster or not. The _effect_ is the same as speculatively optimising every line: substantial cost, uncertain benefit, potential to introduce bugs, etc etc.
- locopati 17y ago
  The thing about efficiency is that efficiency from one person's perspective is not the same as efficiency from another's. It may _run_ more efficiently, but maintenance efficiency decreases and extendability efficiency increases. So, you've traded a marginal short-term gain for long-term decreases in efficiency.
- scumola 17y ago
  C and assembly can be written very legibly.
foldr 17y ago
It's weird to criticize Java for being slow. These days it's pretty much As Fast as C, unless you have a huge amount to gain from unboxed arrays of non-primitive types, or manual memory management. (Possible, but not terribly likely.)
prodigal_erik 17y ago
The JVM has never been 1000x slower than native code. Fourteen years ago it was occasionally as much as 10x slower. What's the penalty these days, maybe 10%? And in return we don't risk undefined behavior if anyone who worked on the project ever made a single mistake? Java is a mediocre language at best, it truly epitomizes everything pg said about Blub, but I'm still glad we didn't use C. And assembly? Seriously? All but the tiniest processors are superscalar now, and the performance of code depends on obscure details about how instruction scheduling fits into pipelines. The way I hear it, there are only a handful of people in the world who can actually do that better than their compiler, and I'm not going to become one of them. There are too many other things to learn that I can keep using over more time.
- scumola 17y ago
  I'm the author of the original article. What about bloat? It's hard to compare java to C applications because people don't tend to write the exact same app in more than one language, but compare Azurus to utorrent. Sure, Azurus has many more bells and whistles than utorrent does, but are you willing sacrifice an entire machine's CPU/memory to a single app just to get some special features? I doubt it. utorrent is the most popular torrent client because of this very fact. If Azurus weren't just a resource hog, it would be the most popular because of its features, but it isn't. People don't need a million features. They want an app that runs quickly and efficiently and gets the job done. The same thing with web app development. Just because you work for a company with a huge budget doesn't mean that you should squander the company's money on hardware when it could be done with less. If your whole programming department thinks that hardware is cheap, then before you know it you've got 500+ machines to run a simple website. We're no longer talking pennies here. We're talking hundreds of thousands of dollars and tens of thousands of dollars monthly. That would hire a whole staff of C programmers. There exist many C libraries that provide the same functionality that java provides. You guys should just bite the bullet, commit yourselves to doing a little manual memory management, drag out your favorite debugger and try writing you next app in C or C++. I'd bet that you'd be very surprised at how very do-able, writing a current-day app in C or C++ actually is compared to java. Come on, where are my fellow C programming brethren? I know you're out there! Take a break from your desktop app coding and back me up on this! :)
pmccool 17y ago
The anti-GC part of this rant is especially hard to take. I've had the misfortune of having to debug various memory allocation problems in C. That's something I don't miss at all. To bag GC for performance without mentioning reliability is just wrong.
- scumola 17y ago
  I'm the author of the original post. It's not difficult. Get a good debugger, and you're job is easy. Use a memory allocation tracker while you debug, then switch back when you're done. It's not hard, just takes a little more time. Don't be lazy. Use ccmalloc: No recompilation is needed to use ccmalloc; simply link it with -lccmalloc -ldl or ccmalloc.o -ldl When you've found and fixed your leak, stop linking with the library and you're done. Why switch to a GC architecture because you don't want to do something easy like this?
  - foldr 17y ago
    > It's not difficult. Get a good debugger, and you're job is easy. Easy for a sysadmin to say! How many web apps have you written in C lately? > It's not hard, just takes a little more time Yeah -- just long enough to go out of business ;)
  - pmccool 17y ago
    I wasn't just talking about memory leaks. Memory allocation in C is a rich source of bugs. Even assuming they are "easy to fix", that's still a poor second to "never happened in the first place". GC isn't free, sure, but it has definite advantages.
- prodigal_erik 17y ago
  The weird thing is how many projects resort to reference counting, which is just like GC only far more expensive (now every single p1=p2 requires two checks for null, an atomic increment and decrement, and a conditional branch around a dtor call!) and less reliable.
  - 17y ago
endtime 17y ago
This isn't really an inspiring criticism of Java. There are far better reasons to dislike Java than that it's not C. Here is a decent reddit thread discussing why people don't like Java: http://www.reddit.com/r/programming/comments/9dzpu/ask_reddit_why_does_everyone_hate_java/ http://www.reddit.com/r/programming/comments/9dzpu/ask_reddi.... The most succint answer just links this: http://ws.apache.org/xmlrpc/apidocs/org/apache/xmlrpc/server/RequestProcessorFactoryFactory.html http://ws.apache.org/xmlrpc/apidocs/org/apache/xmlrpc/server...
jjonte 17y ago
I can't really tell if the author is joking (it reads a little sarcastically), but assuming he's not, the counter argument is really easy. While you're spending days writing mallocs and copying function pointers in C, your competitor is using one of these "lazy programmers" languages and implementing features in hours. Features that are going to take you days to write. Once scale is needed, your competitor just goes out and spends $700 on a cheap server and matches your performance. Ultimately it comes down to time vs. money. It sounds like the author still thinks all computers cost hundreds of thousands of dollars.
- brazzy 17y ago
  The key words to understand the author are buried in there: "As a sysadmin". For sysadmins, the time saved in development means nothing, while every additional machine (and especially the infrastructure to run them as a cluster) means more work. Still, shouldn't even a sysadmin appreciate the increased reliability and especially security that modern languages bring?
  - vetinari 17y ago
    Exactly, as a sysadmin, he should appreciate, that he is not solving buffer overflows all the time. Regarding the more work, as a sysadmin, it is his job to make the machines run the application. His salary and benefits are part of the cost using the higher level languages/additional computers. His rant could be taken as "lazy sysadmin" problem, while what he is ranting against was just costs/benefits decision.
    - scumola 17y ago
      I'm the author of the original post. Sysadmins don't solve buffer overflows, that's a programmer's job. True, my rant could be takes as a "lazy sysadmin", but I have a CS degree and have a programming background. Personally, I'd prefer to re-write this code myself in C than see this kind of hardware waste. That's not being lazy, it's being respectful of the power at my disposal. Use the machine's power on doing actual work, don't waste the machine's power on programmatic overhead that could be avoided by making a different choice.
jpr 17y ago
Rather strange rant. I hope it was trying to be funny, but if so, it failed miserably. Anyway, what I find interesting is that Java really is very slow in one thing: startup time. My completely unscientific test concluded that a hello world -program in written in Java takes about 0.110 seconds to run, while the C version took about 0.003 seconds. What's interesting, Python version takes about 0.015 seconds, which includes parsing, compiling to bytecode and interpreting it, while the Java version has already been parsed and compiled. I would like to know what explains this almost tenfold difference between Java and Python startup times. I suspect it might have to do with the security features of Java?
- makecheck 17y ago
  If you ran the Python version more than once, check for a new file with a "c" suffix; that could skew your performance measurement.
- scumola 17y ago
  I'm the author of the original post. cross-platform benchmarks like this typically don't represent real-world apps. They're usually tiny benchmarks that test one or two things, but don't really hit the nail on the head when it comes to resource bloat or garbage collection or things that happen to an application that runs for days, weeks or months at a time. Yea, startup time is going to be faster in C or C++ because there isn't anything to start up. C just starts running and after the OS has the application scheduled, it starts doing real work, not pre-allocation of things and all of the overhead that's involved with languages like java, python, ruby, perl, ... For small applications, startup time is important. In unix/linux, when you string a bunch of apps together on a command-line, startup time is very important. So, don't dismiss startup time. Secondly, let's talk socket pools, file handle pools, garbage collection, and all of the many things that java gives you to get better performance out of a language that is literally the elephant (bloated, slow thing) in the room.
littleidea 17y ago
I'd comment on the blog if I didn't have to login. Wins prize for most naive rant this week. There are a lot better reasons to hate on java, but speed really isn't one in 2010. I'd love to see the rewrite of one of the apps he's complaining about in C and blog post about that. --omg-optimized
- scumola 17y ago
  I'm the author of the original post. Re: login, sorry, it's drupal and I turned off anonymous comments for spam reasons. :) I'm sorry that you think that I'm naive. I'm 41 years old and have a CS degree. I've been a linux programmer and sysadmin since 1993, before linux had a 1.0 kernel (0.99.9.45 or something like that when I installed my first linux machine). My background is in programming and I spent my college career in 1990-1994 writing mostly C code. Java is slow, although most java programmers don't want to admit it. When you take into account resource bloat, java is still a horrible choice for almost any application unless you work for a company with a lot of money that's willing to just throw money at hardware because the software developers say it's needed. If you'd like to compare apples-to-apple, it's going to be hard because people don't usually write the exact same app in more than one language unless they're doing benchmark tests of something simple (usually hello world, or a matrix operation or something), but not real world applications. I realize that I'm sticking my neck out there for criticism, but I'm ok with it. A lot of web programmers are java engineers - young kids coming out of school with a java background and they don't want to even deal with C because they don't want to do the manual memory management or watch for return codes, but instead just wrap the whole function in a try/catch handler. To me, it's laziness. C and C++ are almost the same syntactically to java. You guys can write C or C++, you just choose not to. For me, being a sysadmin for a living now, this is just a lazy and wasteful choice. If you were to write your code in something more "close to the metal" just think how much more awesome your programs could be!
  - foldr 17y ago
    >Java is slow No, it's not. Modern JVMs produce extremely fast code. For numeric calculations, there's essentially no difference in speed between Java and C. (After all, why would there be? The JVM has static type info and is emitting assembly.) This was true even in 2004, so it's really long overdue that you move on from 1995 :) http://www.idiom.com/~zilla/Computer/javaCbenchmark.html http://www.idiom.com/~zilla/Computer/javaCbenchmark.html >If you were to write your code in something more "close to the metal" C is close to the PDP-11; it's not particularly close to modern hardware.
InclinedPlane 17y ago
In many cases macro-optimization trumps micro-optimization. C/C++ might be closer to the metal and in extremely simple applications incrementally (or perhaps significantly) faster, but if the difficulty of using C for web app development results in an extremely sub-optimal solution then you'd have been better off with a more advanced language like Ruby or even Java. Moreover, the long pole in almost every web application of any significance today is the database. Whether you're using C++ or PHP is irrelevant if just waiting on a SQL statement to execute dominates the performance of your app by an order of magnitude or more. Additionally, there's frequently a lot of room for optimization in any web app. Techniques like CSS spriting, serving static content from a cookie-less domain, and aggressive caching can make far more of a difference to overall performance than choice of language. Finally, throwing hardware at the problem almost always makes sense as long as you can get away with it. A $1500 server is roughly equivalent to the cost of a single day of development for a talented team of only 4 devs (keep in mind that the cost of employing developers includes not just their base salary but also other costs like administration, 401k matching, health insurance, payroll taxes, etc, which nearly doubles the nominal per hour cost). Until you're perhaps $20-50k in the hole it probably doesn't make sense to consider putting serious effort into re-engineering your software from the ground up for scalability.
- scumola 17y ago
  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 server being equal to the salary of 4 FTEs, in my experience, we're not talking about a single machine. Commonly, we're talking about dozens or racks worth of machines. Now we're not talking pennies anymore. We're talking tens of thousands of dollars. This is wasteful of our current massively-powerful machines.
  - 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").
olefoo 17y ago
I think the source of the OP's pain can be traced to the fact that while Java is reasonably competent as a programming language, it's complete and utter crap as an operating system. It replaces the finely honed tools of a modern operating system with it's own inferior versions, the process model is replaced by threads, shared libraries are implemented as "Beans" and come with an impressive armature of support infrastructure that could be dispensed with in favor of a simple configuration file. Sadly, it is the faults of java that pre-adapted it to success in a corporate environment; it creates an impression of vast complexity in even simple tasks and allows for large budgets and swollen headcounts that translate into more power for the leadership of projects in which it is used.
- scumola 17y ago
  Woohoo, sing it, brother! :)

5 points by scumola 17y ago

"It’s not as slow as it used to be, but it’s still pretty un-optimized. It doesn’t run “close to the metal” like C and assembly does." While everyone likes to have efficiency, being readable and/or easy to use sometimes trumps it. Would you really write a program like <insert large Java program here> in assembly, just because it would be faster?

pmccool 17y ago
I'd go further and say that readability and/or ease of use _often_ trumps efficiency. I/O tends to be the bottleneck at least as often as CPU, apart from anything else. I agree with the point about writing in assembly language. This rant is basically arguing for speculatively micro-optimising _every line of code_ by choosing a supposedly faster language.
- scumola 17y ago
  I'm the author of the original post. The article isn't about optimizing every line of code, it's about not being lazy and choosing a language that you might have to do a little more work in for a massive decrease in bloat and execution time. One tool isn't always the right one for every problem. Don't use a hammer to screw in a screw. Sure, the screw will go in, but with just a little more effort (using a screwdriver) the task will be done much better. It's about wasting money & resources because a programmer doesn't want to write a little extra code to manage memory or watch return codes.
  - pmccool 17y ago
    I'll put it another way. Most code isn't performance-critical. If you choose to write everything in, say, assembler, most of it will give you little or no gain. Assembler's harder to write than Java, so every line is costing you money, whether it actually runs faster or not. The _effect_ is the same as speculatively optimising every line: substantial cost, uncertain benefit, potential to introduce bugs, etc etc.
locopati 17y ago
The thing about efficiency is that efficiency from one person's perspective is not the same as efficiency from another's. It may _run_ more efficiently, but maintenance efficiency decreases and extendability efficiency increases. So, you've traded a marginal short-term gain for long-term decreases in efficiency.
scumola 17y ago
C and assembly can be written very legibly.

foldr 17y ago

It's weird to criticize Java for being slow. These days it's pretty much As Fast as C, unless you have a huge amount to gain from unboxed arrays of non-primitive types, or manual memory management. (Possible, but not terribly likely.)

prodigal_erik 17y ago

The JVM has never been 1000x slower than native code. Fourteen years ago it was occasionally as much as 10x slower. What's the penalty these days, maybe 10%? And in return we don't risk undefined behavior if anyone who worked on the project ever made a single mistake? Java is a mediocre language at best, it truly epitomizes everything pg said about Blub, but I'm still glad we didn't use C. And assembly? Seriously? All but the tiniest processors are superscalar now, and the performance of code depends on obscure details about how instruction scheduling fits into pipelines. The way I hear it, there are only a handful of people in the world who can actually do that better than their compiler, and I'm not going to become one of them. There are too many other things to learn that I can keep using over more time.

scumola 17y ago
I'm the author of the original article. What about bloat? It's hard to compare java to C applications because people don't tend to write the exact same app in more than one language, but compare Azurus to utorrent. Sure, Azurus has many more bells and whistles than utorrent does, but are you willing sacrifice an entire machine's CPU/memory to a single app just to get some special features? I doubt it. utorrent is the most popular torrent client because of this very fact. If Azurus weren't just a resource hog, it would be the most popular because of its features, but it isn't. People don't need a million features. They want an app that runs quickly and efficiently and gets the job done. The same thing with web app development. Just because you work for a company with a huge budget doesn't mean that you should squander the company's money on hardware when it could be done with less. If your whole programming department thinks that hardware is cheap, then before you know it you've got 500+ machines to run a simple website. We're no longer talking pennies here. We're talking hundreds of thousands of dollars and tens of thousands of dollars monthly. That would hire a whole staff of C programmers. There exist many C libraries that provide the same functionality that java provides. You guys should just bite the bullet, commit yourselves to doing a little manual memory management, drag out your favorite debugger and try writing you next app in C or C++. I'd bet that you'd be very surprised at how very do-able, writing a current-day app in C or C++ actually is compared to java. Come on, where are my fellow C programming brethren? I know you're out there! Take a break from your desktop app coding and back me up on this! :)

pmccool 17y ago

The anti-GC part of this rant is especially hard to take. I've had the misfortune of having to debug various memory allocation problems in C. That's something I don't miss at all. To bag GC for performance without mentioning reliability is just wrong.

scumola 17y ago
I'm the author of the original post. It's not difficult. Get a good debugger, and you're job is easy. Use a memory allocation tracker while you debug, then switch back when you're done. It's not hard, just takes a little more time. Don't be lazy. Use ccmalloc: No recompilation is needed to use ccmalloc; simply link it with -lccmalloc -ldl or ccmalloc.o -ldl When you've found and fixed your leak, stop linking with the library and you're done. Why switch to a GC architecture because you don't want to do something easy like this?
- foldr 17y ago
  > It's not difficult. Get a good debugger, and you're job is easy. Easy for a sysadmin to say! How many web apps have you written in C lately? > It's not hard, just takes a little more time Yeah -- just long enough to go out of business ;)
- pmccool 17y ago
  I wasn't just talking about memory leaks. Memory allocation in C is a rich source of bugs. Even assuming they are "easy to fix", that's still a poor second to "never happened in the first place". GC isn't free, sure, but it has definite advantages.
prodigal_erik 17y ago
The weird thing is how many projects resort to reference counting, which is just like GC only far more expensive (now every single p1=p2 requires two checks for null, an atomic increment and decrement, and a conditional branch around a dtor call!) and less reliable.
- 17y ago

endtime 17y ago

This isn't really an inspiring criticism of Java. There are far better reasons to dislike Java than that it's not C. Here is a decent reddit thread discussing why people don't like Java: http://www.reddit.com/r/programming/comments/9dzpu/ask_reddit_why_does_everyone_hate_java/ http://www.reddit.com/r/programming/comments/9dzpu/ask_reddi.... The most succint answer just links this: http://ws.apache.org/xmlrpc/apidocs/org/apache/xmlrpc/server/RequestProcessorFactoryFactory.html http://ws.apache.org/xmlrpc/apidocs/org/apache/xmlrpc/server...

jjonte 17y ago

I can't really tell if the author is joking (it reads a little sarcastically), but assuming he's not, the counter argument is really easy. While you're spending days writing mallocs and copying function pointers in C, your competitor is using one of these "lazy programmers" languages and implementing features in hours. Features that are going to take you days to write. Once scale is needed, your competitor just goes out and spends $700 on a cheap server and matches your performance. Ultimately it comes down to time vs. money. It sounds like the author still thinks all computers cost hundreds of thousands of dollars.

brazzy 17y ago
The key words to understand the author are buried in there: "As a sysadmin". For sysadmins, the time saved in development means nothing, while every additional machine (and especially the infrastructure to run them as a cluster) means more work. Still, shouldn't even a sysadmin appreciate the increased reliability and especially security that modern languages bring?
- vetinari 17y ago
  Exactly, as a sysadmin, he should appreciate, that he is not solving buffer overflows all the time. Regarding the more work, as a sysadmin, it is his job to make the machines run the application. His salary and benefits are part of the cost using the higher level languages/additional computers. His rant could be taken as "lazy sysadmin" problem, while what he is ranting against was just costs/benefits decision.
  - scumola 17y ago
    I'm the author of the original post. Sysadmins don't solve buffer overflows, that's a programmer's job. True, my rant could be takes as a "lazy sysadmin", but I have a CS degree and have a programming background. Personally, I'd prefer to re-write this code myself in C than see this kind of hardware waste. That's not being lazy, it's being respectful of the power at my disposal. Use the machine's power on doing actual work, don't waste the machine's power on programmatic overhead that could be avoided by making a different choice.

jpr 17y ago

Rather strange rant. I hope it was trying to be funny, but if so, it failed miserably. Anyway, what I find interesting is that Java really is very slow in one thing: startup time. My completely unscientific test concluded that a hello world -program in written in Java takes about 0.110 seconds to run, while the C version took about 0.003 seconds. What's interesting, Python version takes about 0.015 seconds, which includes parsing, compiling to bytecode and interpreting it, while the Java version has already been parsed and compiled. I would like to know what explains this almost tenfold difference between Java and Python startup times. I suspect it might have to do with the security features of Java?

makecheck 17y ago
If you ran the Python version more than once, check for a new file with a "c" suffix; that could skew your performance measurement.
scumola 17y ago
I'm the author of the original post. cross-platform benchmarks like this typically don't represent real-world apps. They're usually tiny benchmarks that test one or two things, but don't really hit the nail on the head when it comes to resource bloat or garbage collection or things that happen to an application that runs for days, weeks or months at a time. Yea, startup time is going to be faster in C or C++ because there isn't anything to start up. C just starts running and after the OS has the application scheduled, it starts doing real work, not pre-allocation of things and all of the overhead that's involved with languages like java, python, ruby, perl, ... For small applications, startup time is important. In unix/linux, when you string a bunch of apps together on a command-line, startup time is very important. So, don't dismiss startup time. Secondly, let's talk socket pools, file handle pools, garbage collection, and all of the many things that java gives you to get better performance out of a language that is literally the elephant (bloated, slow thing) in the room.

littleidea 17y ago

I'd comment on the blog if I didn't have to login. Wins prize for most naive rant this week. There are a lot better reasons to hate on java, but speed really isn't one in 2010. I'd love to see the rewrite of one of the apps he's complaining about in C and blog post about that. --omg-optimized

scumola 17y ago
I'm the author of the original post. Re: login, sorry, it's drupal and I turned off anonymous comments for spam reasons. :) I'm sorry that you think that I'm naive. I'm 41 years old and have a CS degree. I've been a linux programmer and sysadmin since 1993, before linux had a 1.0 kernel (0.99.9.45 or something like that when I installed my first linux machine). My background is in programming and I spent my college career in 1990-1994 writing mostly C code. Java is slow, although most java programmers don't want to admit it. When you take into account resource bloat, java is still a horrible choice for almost any application unless you work for a company with a lot of money that's willing to just throw money at hardware because the software developers say it's needed. If you'd like to compare apples-to-apple, it's going to be hard because people don't usually write the exact same app in more than one language unless they're doing benchmark tests of something simple (usually hello world, or a matrix operation or something), but not real world applications. I realize that I'm sticking my neck out there for criticism, but I'm ok with it. A lot of web programmers are java engineers - young kids coming out of school with a java background and they don't want to even deal with C because they don't want to do the manual memory management or watch for return codes, but instead just wrap the whole function in a try/catch handler. To me, it's laziness. C and C++ are almost the same syntactically to java. You guys can write C or C++, you just choose not to. For me, being a sysadmin for a living now, this is just a lazy and wasteful choice. If you were to write your code in something more "close to the metal" just think how much more awesome your programs could be!
- foldr 17y ago
  >Java is slow No, it's not. Modern JVMs produce extremely fast code. For numeric calculations, there's essentially no difference in speed between Java and C. (After all, why would there be? The JVM has static type info and is emitting assembly.) This was true even in 2004, so it's really long overdue that you move on from 1995 :) http://www.idiom.com/~zilla/Computer/javaCbenchmark.html http://www.idiom.com/~zilla/Computer/javaCbenchmark.html >If you were to write your code in something more "close to the metal" C is close to the PDP-11; it's not particularly close to modern hardware.

InclinedPlane 17y ago

In many cases macro-optimization trumps micro-optimization. C/C++ might be closer to the metal and in extremely simple applications incrementally (or perhaps significantly) faster, but if the difficulty of using C for web app development results in an extremely sub-optimal solution then you'd have been better off with a more advanced language like Ruby or even Java. Moreover, the long pole in almost every web application of any significance today is the database. Whether you're using C++ or PHP is irrelevant if just waiting on a SQL statement to execute dominates the performance of your app by an order of magnitude or more. Additionally, there's frequently a lot of room for optimization in any web app. Techniques like CSS spriting, serving static content from a cookie-less domain, and aggressive caching can make far more of a difference to overall performance than choice of language. Finally, throwing hardware at the problem almost always makes sense as long as you can get away with it. A $1500 server is roughly equivalent to the cost of a single day of development for a talented team of only 4 devs (keep in mind that the cost of employing developers includes not just their base salary but also other costs like administration, 401k matching, health insurance, payroll taxes, etc, which nearly doubles the nominal per hour cost). Until you're perhaps $20-50k in the hole it probably doesn't make sense to consider putting serious effort into re-engineering your software from the ground up for scalability.

scumola 17y ago
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 server being equal to the salary of 4 FTEs, in my experience, we're not talking about a single machine. Commonly, we're talking about dozens or racks worth of machines. Now we're not talking pennies anymore. We're talking tens of thousands of dollars. This is wasteful of our current massively-powerful machines.
- 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").

olefoo 17y ago

I think the source of the OP's pain can be traced to the fact that while Java is reasonably competent as a programming language, it's complete and utter crap as an operating system. It replaces the finely honed tools of a modern operating system with it's own inferior versions, the process model is replaced by threads, shared libraries are implemented as "Beans" and come with an impressive armature of support infrastructure that could be dispensed with in favor of a simple configuration file. Sadly, it is the faults of java that pre-adapted it to success in a corporate environment; it creates an impression of vast complexity in even simple tasks and allows for large budgets and swollen headcounts that translate into more power for the leadership of projects in which it is used.

scumola 17y ago
Woohoo, sing it, brother! :)