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…
My latest anti-java rant
11–20 of 48 posts
Re: My latest anti-java rant
#12The 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.
Disclaimer: I've mostly worked in GC environments.
Re: My latest anti-java rant
#13Wins 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
#14I 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…
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
#15Earlier 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.
Re: My latest anti-java rant
#16Moreover, 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
#17The 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.
Re: My latest anti-java rant
#18I 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?
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"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 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"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?