My latest anti-java rant
badcheese.com
badcheese.com
And assembly? Seriously? All but the tiniest processors are superscalar now, and the performance of code depends on obscure details about how instruction scheduling fits into pipelines. The way I hear it, there are only a handful of people in the world who can actually do that better than their compiler, and I'm not going to become one of them. There are too many other things to learn that I can keep using over more time.
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.
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.
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.
Ok, and I've seen Java apps not do that. Argument by anecdote is bankrupt.
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.
Here is a decent reddit thread discussing why people don't like Java: http://www.reddit.com/r/programming/comments/9dzpu/ask_reddi.... The most succint answer just links this: http://ws.apache.org/xmlrpc/apidocs/org/apache/xmlrpc/server...
While everyone likes to have efficiency, being readable and/or easy to use sometimes trumps it. Would you really write a program like <insert large Java program here> 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.
Easy for a sysadmin to say! How many web apps have you written in C lately?
> It's not hard, just takes a little more time
Yeah -- just long enough to go out of business ;)
Disclaimer: I've mostly worked in GC environments.
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.
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.
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 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!
No, it's not. Modern JVMs produce extremely fast code. For numeric calculations, there's essentially no difference in speed between Java and C. (After all, why would there be? The JVM has static type info and is emitting assembly.) This was true even in 2004, so it's really long overdue that you move on from 1995 :)
http://www.idiom.com/~zilla/Computer/javaCbenchmark.html
>If you were to write your code in something more "close to the metal"
C is close to the PDP-11; it's not particularly close to modern hardware.
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.
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 cheaper than the alternatives (e.g. hiring a few "C experts" or "spending a month on optimizations").
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.
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.
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.
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 includes parsing, compiling to bytecode and interpreting it, while the Java version has already been parsed and compiled. I would like to know what explains this almost tenfold difference between Java and Python startup times. I suspect it might have to do with the security features of Java?
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.