Live data from Hacker News

My latest anti-java rant

badcheese.com

11–20 of 48 posts

Re: My latest anti-java rant

#11
post #9

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

If you ran the Python version more than once, check for a new file with a "c" suffix; that could skew your performance measurement.

Re: My latest anti-java rant

#12
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.

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.

It seems to me like the endgame of most memory management problems is static buffers and pools for speed/low fragmentation, and GC for everything else; manual allocations are just too fiddly for most coders to favor them for optimization.

Disclaimer: I've mostly worked in GC environments.

Re: My latest anti-java rant

#13
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

Re: My latest anti-java rant

#14
post #8

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…

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?

Re: My latest anti-java rant

#15
post #10

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.

Also, reference counting can't handle cyclic structures gracefully. Just say no to it.

Reference counting can also become extremely complex (and error prone) in a multi-threaded environment.

Re: My latest anti-java rant

#16
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.

Re: My latest anti-java rant

#17
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.

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 usage.

Re: My latest anti-java rant

#18
post #14
post #8

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…

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.

Re: My latest anti-java rant

#19
post #2

"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 in assembly, just because it would be faster?

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.

Re: My latest anti-java rant

#20
post #2

"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 in assembly, just because it would be faster?

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.
Post reply on HN