Live data from Hacker News

My latest anti-java rant

badcheese.com

41–48 of 48 posts

Re: My latest anti-java rant

#41
post #34
post #21

Earlier quoted context omitted.

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 th…

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…

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.

Re: My latest anti-java rant

#42
post #17

Earlier quoted context omitted.

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.

You say reference counting is far more expensive, but that's only in CPU cycles. Compare Python (reference-counted) and Java (garbage collected), and Java's memory use is 3x greater for similar programs, at least in my experience (also in the computer language benchmark game). Reference counting is a form of garbage collection, it's just eager rather than lazy, and that eagerness pays off in predictably lower memory…

You can save memory by writing a file a byte at a time rather than allocating a buffer. The reason you don't is that it's more efficient to batch that work. Well, the same is true of GC. If you have a million dead objects and a thousand live ones, doing bookkeeping for each dead object is far more expensive (in cycles and bus bandwidth) than just having a copying collector rescue the live objects and then reuse those memory pages en masse.

Once your program's memory footprint is small enough to fit on the machines you're using, making it smaller takes more runtime work but has little benefit.

Re: My latest anti-java rant

#43
post #27
post #5

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.

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…

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.

Re: My latest anti-java rant

#44
post #25
post #19

Earlier quoted context omitted.

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.

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…

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.

Re: My latest anti-java rant

#45
post #35
post #26

Earlier quoted context omitted.

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 wastefu…

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…

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.

Re: My latest anti-java rant

#46
post #31
post #22

Earlier quoted context omitted.

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…

Somewhat tangentially: I run a useful app, JBidWatch (a nice, free eBay "sniping"/monitoring tool) on my Windows XP desktop. I started it 1 week ago following a reboot. One week later I noticed the PC's mem usage was nearing the amount of physical memory and investigated; one contributor turned out to be the JVM session running this app: according to Task Manager, this app (actively monitoring no items during the wee…

This sounds like a memory leak (probably sticking items in a hashmap and never bothering to remove them), or nothing has forced a major GC. Java apps that grow in memory usage without bound aren't demonstrating problems with Java - they're demonstrating poor programming. JIT'ing and GC algorithm improvements over the past few years have invalidated a lot of the original complaints raised against Java.

Re: My latest anti-java rant

#47
post #45
post #35

Earlier quoted context omitted.

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…

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…

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.

Re: My latest anti-java rant

#48
post #45
post #35

Earlier quoted context omitted.

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…

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…

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.

Post reply on HN