Hacker News Reader

Comment by jjonte | Hacker News Reader

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.

View on HN

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?

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.

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.

Sorry, I was inprecise. Of course sysadmins do not solve buffer overflows, they solve what happens when someone exploits one.

I understand what you are saying, you see that the flight to the moon was done by something equivalent to C64 and today we are allow wasting orders of magnitude more computing power.

What I'm trying to tell you, look at the whole picture. There is a cost associated with writing and maintaing software. That hand optimized assembly application is going to be more expensive (and take longer to deliver) than the Java/c#/whatever equivalent. There is another cost associated with purchasing and operating hardware (that includes paying sysadmins, for example). The business has to consider what is more effective, and usually HL language/more HW is the more efficient solution.

What, more efficient, you say? We were talking about wasting the computer power. Yes, more efficient overall. We have a method for measuring wasting resources - money. You are going either waste some money on hardware/electricity/floor space/sysadmins, or programmers/time to deliver/managing larger team/managing recruiting and retaining competent programmers. Not only is the former cheaper, it is also easier to quantify and manage. It is no wonder, that you do not see companies taking the later approach.

At the end, what most people do not understand (not only technical people, but most people) is that successful enterprise is not a 100% efficient one. There is going to be waste, but it must be in the right spot. Actually, conceptually it is similar to profiling, you don't optimize spots that do not matter in the big picture. And computing power does not matter for most business, it is a cheap resource. People, on the other hand, is not.

I'm the author of the original article. A typical server costs $1500 (DELL, HP) nowadays, but I've seen java apps commonly take up a whole rack of servers, not just one. This is a base cost of $30k and > $1500/mo for rackspace, A/C, power, bandwidth and maintenance. That's one-half of an FTE up-front and one FTE's salary reoccurring. I hear from java developers, "I'll need 6x 3Ghz, quad-core, dual-cpu machines for this (pretty simple) app I'm writing". Are you f-ing kidding me? Do you know what you could do with that kind of hardware if you wrote it in a different language? Your app is basically a glorified web server that does one thing that apache doesn't do out of the box. It sickens me to see this kind of waste because of the programmer's language choice.

That's one-half of an FTE up-front and one FTE's salary reoccurring.

Only if your FTEs are very cheap. Most I know wouldn't get out of bed for less than $50k+.

But even if it was half a man-year upfront and one recurring - that's still a no-brainer (remember we're talking an entire rack here, which goes quite a way for most apps). If that rack enables your 5 programmers to work only 10% faster (completely theoretical ofcourse, but for the sake of the argument...) then it has already more than paid for itself.

Your argument is quite old nowadays (I remember the heated efficiency debates in the 90s) and has long been decided. Hardware is so cheap now that in most cases it really is demonstrably more cost effective to throw hardware at certain problems.

It depends on the constants. For example, we rewrote our critical path app server in Java, and now it can handle 6x the load compared to our predecessors' PHP version. Twitter was getting crushed by Ruby performance, so they went to Scala on the JVM. These were clearly worth doing. But using C would only net a few more percent in performance and at best 50% less memory required, at a huge stability risk.

I've seen java apps commonly take up a whole rack of servers, not just one

Ok, and I've seen Java apps not do that. Argument by anecdote is bankrupt.

Reply on news.ycombinator.com