The second coming of Java

By | December 11, 2012
Share on FacebookShare on Google+Tweet about this on TwitterShare on LinkedInEmail this to someone

This article was originally posted by Robert X. Cringely at I, Cringely blog last year. Has this prediction come true? What do you think? Share your opinion with us!

There’s a continuous revolution taking place in web development as platforms and tools evolved first to handle dynamic pages and now cloud services. But sometimes what goes around comes around so I’m predicting a resurgence of Java and Java-like languages as rotating storage goes into decline. Here’s why.

In the beginning of the web we wrote web apps with Perl and C++ because that’s all we had. This sucked.

C++ is awesome for anything requiring intense performance but because it operates at a comparatively low level (closer to the silicon) C++ is very hard for dopes like me to use. And in a way it’s an insult to the language, which gets bored waiting for databases and network requests.

To avoid the complexities of C++ we turned to Perl which was fast to write in but wasn’t ready to be a web server. And Perl had no frameworks to help write web apps so we wrote a lot of boiler plate crap every time just to get started. Sure CPAN eventually brought libraries to help but it was still fragmented.

When Java arrived it wasn’t so interesting that we had Java, it was interesting that we had the Java Virtual Machine. JVM’s took care of cleaning up memory and automatically profiling and optimizing our programs — tasks that had to be done by hand back in C++.

Java also had threading really well integrated from the start so we could handle many requests at once which was starting to become a problem by 2005 or so. Multicore’s introduction hit just at the right time for Java, too. Compiled Java is a very high-level machine code but is a standard that JVM engineers have had more than a decade to tune so it works very well.

.NET was really just another Java for Windows. Nothing is fundamentally awesome about it over Java except that the engineers got to learn from Java’s mistakes.

Java’s performance was no C++ but it was way better than perl’s and again, we didn’t need all that much. What we needed was faster development and we got it.

Yet in the last few years since, say, 2007 we’ve been moving away from Java and .NET for web development and back to interpreted dynamic languages like Ruby. These are slow as molasses (though now our CPUs are much faster) but easy to program for a broader, younger, and maybe less experienced crowd of developers. Prototyping new websites and apps has become very easy, which is why there are so many bad ones out there.

The difference between the old days of Perl and today is that we’ve made the real web server in C++. So performance in Ruby is helped by a lot of work done in C++. Since every app needs to do that work, we can write it once and lay Ruby on top to make connections, talk HTTP, etc.

Under Ruby, we put C++. On top of Ruby we put the Rails web framework. It’s not very common to actually code anything in Ruby. You pretty much only see people coding Ruby while using the Rails framework which governs the whole thing.

You can replace Ruby here with Python, Django or Groovy and it is still correct.

Notice the transition? We started with Perl, went to Java, then came back to Perl! The reason we didn’t literally do that (actually go back to writing in Perl) is because the kids who wrote Rails were too cool for Perl, which they saw as old school. But Ruby has nothing on Perl. What’s brilliant is the Rails web framework, which came about because of what people learned writing web apps in Java. There are lots of web frameworks in Java, but that was part of the problem — knowing which of the many Java web frameworks were any good.

Ruby is easier than Java. It runs something like seven times slower but who cares? We’re still waiting for the database. And if you are a new developer you can learn Rails and be one of the cool kids.

Java has all the fantastic data structures you learn about in school while Ruby has only hash tables and arrays. But if you don’t give a rat’s ass about performance you can shoehorn anything into hash tables and arrays. That’s why prototyping is so fast in Ruby.

Yeah, but there’s a problem looming for Ruby and Rails (Python, Groovy, etc.) and it is that web frameworks based on interpreted, dynamic languages only exist at all because disks are just so damned slow. What happens to these frameworks when disks get faster or disappear entirely?

A modern disk seek is around five milliseconds. That means we can get only about 200 disk seeks per second. Every non-cached database access will do several seeks (BTree data structure, Mr. Smartypants) and every web page usually requires several database accesses to construct the page. In other words, its not uncommon to take half a second in just doing disk seeks for your local database! And of course it gets worse, much worse, if seeks across the network are involved.

But if you replace spinning disks and moving read/write heads with Solid State Disks (SSDs) and no heads at all, local seek times drop to zero. That’s why Ruby and its surrogate languages will eventually disappear.

When SSDs gain enough capacity there will be a shift from the Ruby world back to the Java world. Not for prototyping, because, well, it’s prototyping. But simply because the statement “Ruby is incredibly slow but I don’t care because my database is slower” will no longer be true. At that point Ruby (Python, Groovy, you name it) becomes the bottleneck.

The big story here (since from the comments below it apparently wasn’t obvious) is the JVM. Ruby is already migrating to that JRuby as will all similar tools. So far, it just hasn’t mattered that much — but it will.
Share on FacebookShare on Google+Tweet about this on TwitterShare on LinkedInEmail this to someone

Subscribe to get the latest updates

  • So, there’s python and you’re happy with it. Then disks suddenly become fast — you get even more happy (being with python). At which point you would like to move to Java?

    I’d understand if your post would say that disks will become fast => people would stop switching to erlang/nodejs (or async frameworks), but Java? Come on.

  • creativetags

    I love Ruby and Rails because of the philosophy driving it. I’m not looking for a tool that speaks machine really well, I want a tool that understands how humans think. Don’t make me think and speak machine. Efficient execution should be abstracted away from me.

  • For the average web application the time it takes to do in-memory computations is still nothing compared to network latency.
    So I don’t think many developers will switch languages just for performance considerations.
    For most applications the bottleneck is not speed but rather factors like developer productivity or maintainability of the system.
    If there are performance critical sections in an application it is far easier to just replace this small part with some Java or C code than to switch the entire web dev stack…

  • I think the point is that, as other latencies become lower and application logic becomes the performance limiter, people will go to languages that generate faster code. We already see that in high-frequency trading, but, when your program is slower than network latencies, you are way past Java territory and deep inside C’s, almost reaching VHDL’s.

  • Nate

    if java wasn’t designed like it was built in 1995, I might agree with you. C# has nothing on java? Are you insane? Certainly the third party code is lacking, but that’s because there’s so much in the standard .Net library.

    How about real generics, not just casting over untyped lists? How about covariance and contravariance? How about lambdas and trivial parallelism and a thousand other things? The main drawback of C# is that it only runs (well) on windows…. and that’s a pretty big problem.

    And your basic premise is wrong… speed of the code is not usually the limiting factor, it’s speed of writing the code. And that’s where java fails the most, only second to C++, which is not surprising, since it’s nearly as old.

  • there are good examples at twitter and tumblr about the advantages of moving to the jvm. And it doesn’t relate to disk speeds.

    Please take a look

  • not bothering

    author sounds like a freshman fanboi..

  • Jameson

    I think you missed the giant elephant in the room: Go

    Go makes Java’s threading look as complicated as C’s p-threads, and removes 99% of the abstraction. Sure, it doesn’t have the business-y features like polymorphism and generics, but Ruby, Python and Node.js have shown that we really don’t need them in a web server. Oh, and it’s also garbage collected.

    Java is dying, so please let it die. Every nitch that Java used to fill now has a more specialized tool: applets (HTML5 canvas/WebGL), cross-platform (python), servers (Ruby, Python, Go, Node.js), pretty fast w/garbage collection (C++11 with smart pointers, D).

    The only place Java lives on is in legacy software, acadamia and developers too lazy to learn a modern language after graduation. Java does no one thing particularly well, which is why it’s doomed to fail. Developers don’t need a swiss-army knife full of mediocre tools, they need a toolbox of specialized tools.

  • Ellem

    @Jameson: Seems you’re forgetting about the universe of frameworks and tools that were developed for Java. Those are the real reasons Java still is (and I think will be yet for a long time) a popular language.