Live data from Hacker News

My latest anti-java rant

badcheese.com

21–30 of 48 posts

Re: My latest anti-java rant

#21
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?

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.

Re: My latest anti-java rant

#22

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? Al…

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! :)

Re: My latest anti-java rant

#23
post #14

Earlier quoted context omitted.

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.

Re: My latest anti-java rant

#24
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?

C and assembly can be written very legibly.

Re: My latest anti-java rant

#25
post #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.

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.

Re: My latest anti-java rant

#26

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

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.

Re: My latest anti-java rant

#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 library and you're done. Why switch to a GC architecture because you don't want to do something easy like this?

Re: My latest anti-java rant

#28

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

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!

Re: My latest anti-java rant

#29
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…

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.

Re: My latest anti-java rant

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

Post reply on HN