Search...

Menu Tags Categories Home RSS Feed E-Mail 2011 (120) 2010 (98) Uncategorized (72) 2009 (22) Apple (45) Google (37) Microsoft (27) cringely (21) Steve Jobs (16) IBM (13) iphone (12) Yahoo (10) Cringely Startup Tour (10) Obama Administration (9) Android (9) 2011 predictions (9) Internet (8) Kauffman Foundation (8) data security (7) financial crisis (7) Sony (7) AOL (7) Intel (6) facebook (6) Oracle (6) AT&T (6) Netflix (5) 2010 predictions (5) HP (5) Steve Ballmer (5) Leo Apotheker (5) Hewlett Packard (5) T-Mobile (5) Obama (4) Wall Street (4) recession (4) Adobe (4)

Submit Query

FCC (4) Bill Gates (4) I, Cringely Search The second coming of Java Oct 12th, 2011 @ 10:02 am › Robert X. Cringely ↓ Skip to comments

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 hashtables and arrays. But if you don’t give a rat’s ass about performance you can shoehorn anything into hashtables 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 datastructure, 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. Categories: 2011 Tags: .NET, C++, Django, Groovy, Java, perl, Python, Rails, Ruby, SSD, web development

198 Responses

1.

Bryce 1 mo, 3 wks ago

Wow no comments? Guess there aren’t many programmers/developers out reading today.

2.

John Handelaar 1 mo, 3 wks ago You’re assuming that, with interpreted languages that can write ‘Hello’ to a web page in one line of code, and opcode caches in place, we care enough about another 10ms to ditch a language that lets us spit something out in a web browser in one line, and instead use one that needs 30 lines of boilerplate and a compiler to achieve the same end. I think that’s a rather bad assumption, sorry.

3.

Henrique Lobo (Kico) 1 mo, 3 wks ago Hi, this time I didn’t get it. If slow database access is a bottleneck for these interpreted languages, shouldn’t the SSD solve this problem and, with this, get more traction for these languages like Ruby?

4.

Marcos 1 mo, 3 wks ago “But Ruby has nothing on Perl.” Not a programmer, are you Robert? What is outstanding to me lately is the massive speed up that interpreted languages have had, fueled by none other than the nasty but ubiquitous JavaScript. Compare the performance of Apple’s Nitro or Google’s V8 vs the speed of anyone’s JavaScript in the mid-90′s. It’s unbelievable. And Facebook is coding in PHP and then generating C++ from it, for crying out loud! Given all the research and effort going into speeding up interpreted languages, I don’t think it’s fair to say that they are as inefficient as they used to be. And often, developer efficiency trumps runtime

efficiency. I wouldn’t count interpreted languages out just yet… I see more people using Python, Ruby, Tcl, PHP, JavaScript for large software development efforts than we ever way with Perl some years ago.

5.

alsanan 1 mo, 3 wks ago Horribly wrong. I see that this is not your strong area. Well, for a start you don’t even talk about PHP (far more used than python, perl or ruby). No mention about Javascript, present in any browser. Even if you are specifically focused on server side, you make your point about the speed of disk access. Well, some years ago a new layer based on mem was placed in order to reduce the time of the responses. Have you ever heared the word memcached? Just score one fail with this article. I hope the rest (where I don’t have the knowledge of this) are not such wrong.

6.

muelnet 1 mo, 3 wks ago bob, agree with most everything except one thing. Java isn’t coming back, the JVM is. Just look at Twitter. Scala, clojure, etc., are the next wave of the JVM, not java.

7.

Big T 1 mo, 3 wks ago I see Java surviving in the enterprise for a long time, but I don’t see it’s resurgence for web development, especially since the interpreted “cool” languages are evolving faster than Java. Now, if Oracle releases a new version of Java with “cool” features (and removes the crappy generics) that’s not backwards compatible, then it might go somewhere. At my current job, new development is being done in Ruby and Erlang, and I have been moving non-core code of my project to Groovy.

8.

Neil O 1 mo, 3 wks ago There’s one more piece to consider. I read this article as comparing the performance of the JVM versus any newer language interpreter, and there are many examples of those newer languages being ported to the JVM or the .Net CLR. e.g. Jython and/or IronPython and JRuby, Scala, Clojure, Bigloo, etc. If faster storage dictates faster web application frameworks, then no reason why these alternate languages can’t play in the same space.

9.

Frankie DiBaker 1 mo, 3 wks ago Bob, JRuby anyone? I think you are missing the point on Rails. While the framework is great for prototyping it also provides convention over configuration which a lot of java web frameworks prior to rails completely missed on (Struts anyone?). It’s been a couple of years since I looked back into Java web frameworks but my understanding is that not much of this has changed as a lot of Java engineers that I know have shifted over to Rails. Ruby is just a language. The type system, syntax, testing frameworks are what make it powerful and efficient. All of this can be run inside a JVM via JRuby so that removes a lot of the arguments you make in your column. There is even a JSR for support for dynamic languages running within the JVM. http://en.wikipedia.org/wiki/JSR_292 I don’t see Ruby/Rails falling out. Just a natural competitor to the Java camp.

10.

CHLTX 1 mo, 3 wks ago

Fundamental Law of Optimization: If you speed up whatever is you are doing by making something run faster, you get fairly small improvement in overall performance. If what you want is really large improvement in overall performance, you need to figure out what it is that you are doing that is not needed, and quit doing that. That factor will overwhelm choice of language, often by several orders of magnitude.

11.

Big T 1 mo, 3 wks ago Agreed.

12.

Stephanos Piperoglou 1 mo, 3 wks ago I’m not sure I buy your argument and I’m a Java coder by trade, so perhaps predisposed to do so. Java is way too constrained by its rigid type system and the lack of closures rather than anything to do with frameworks. It was a great idea in the 90s, when it saved us from writing memory management code, but now we need something that saves us from writing 20 lines of boilerplate for a one-line callback. We also need something that treats database (preferably NoSQL) and network access code as first-class citizens in the language. When was the last time anybody wrote actual file system access code? Yes, Java treats threading code as a first-class citizen but compared to the elegance of node.js and its callback system it feels clunky and cumbersome. In fact I think node.js is exactly where you should be looking to see the future of development platforms.

13.

Robert X. Cringely 1 mo, 3 wks ago This is a generic response to the preceding 12 comments. You may all be correct and I could be totally full of crap. I did, after all, identify myself as a dope. But I do see a transition coming. Maybe I have it wrong in which case I’m sure you folks will set me straight and we’ll all learn something for it. But from a Big Picture

standpoint I still believe I am headed in the right direction.

14.

Ozten 1 mo, 3 wks ago Java and .net have patent and/or cost issues, I don’t see a ‘second coming’ since this has gotten worse in the last year. Oh hai Oracle. Memcache, redis, and other in-memory caching systems make the SSD argument a moot point for many use cases. Why didn’t memcache cause a surge in Java like language use? You analysis doesn’t cover the C10K problem, which is the current driving change to web programming (evented architectures). Google’s Dart is a Java like language, but I think the drivers are legal and organizational over performance characteristics.

15.

Phong Le 1 mo, 3 wks ago Isn’t the network and the browser the bottleneck in web development. I rarely hear anyone say the disk IO is the bottleneck in web performance. Steve Sounders made a career out of improving web sites by optimizing web page rendering. http://stevesouders.com/

16.

Stu 1 mo, 2 wks ago Agreed. Plus Groovy is Java.

17.

Anonymous 1 mo, 2 wks ago Hi Robert, whatever language your website is programmed in, there is a mis-commented “End ad tag” string in it. (Look at the right of

the top ad banner on your page.)

18.

Stu 1 mo, 2 wks ago Exactly, in fact with the likes of Groovy, Jython, JRuby etc I’d say it’s already well on the way back.

19.

Kent 1 mo, 2 wks ago Bob, Are you oblivious to the fact that Groovy compiles down to Java byte code (just as if it had been written in Java) and runs in a JVM? It’s a best-of-both-worlds scenario with the ease and flexibility of dynamic languages (like Ruby or Perl) and the (relatively) better performance of Java. Bottom line is Groovy shouldn’t be lumped in with Ruby and Perl in your assessment of which languages are pending decline.

20.

Kent 1 mo, 2 wks ago Basically, Groovy IS Java.

21.

Gareth Williams 1 mo, 2 wks ago Most database/dynamic language websites today are made to scale by using ram-based caches (e.g. varnish up-front and/or memcached in the middle) to remove most of the database reads. SSD performance may make these redundant and simplify things, and speed up write-centric applications, but I’m not convinced it will make the dynamic language speed enough of an issue to revert to more verbose and slightly faster Java. Newer JVM hosted languages are interesting though, and could bring the best of both

worlds.

22.

Hudin 1 mo, 2 wks ago No mention of PHP? Like any language it has its weak points, but it’s all over the place from Facebook to Wikipedia to… this website with WordPress.

23.

Alex 1 mo, 2 wks ago I agree with that. Unless oracle brings some big improvements in java 8, I don’t see it having a second coming. However, the jvm ecosystem is very healthy and I could see a language like scala gaining more popularity. There is some definite niceties about static typing (e.g. not having to step through a debugger just to figure out where the hell some method got duck punched, etc). Clojure is also really cool and is gaining some good traction.

24.

Doug D 1 mo, 2 wks ago There’s a development in this area that I’m paying close attention to, and it’s coming out of Apple. But first, let’s talk about Facebook. You may recall that Facebook is written in PHP. My old startup company did a bunch of work with PHP in the mid 1990s, and in some sense it’s like a web-optimized flavor of Perl that usually gets embedded directly in C-based web servers. This makes stuff faster, but doesn’t make it really *fast*. So, what Facebook does is, they have PHP *compilers*. They can, in essence, do all their prototyping in PHP and then type “make” and have standalone C++-level performance thingies that they use in production. So, Ruby is object oriented, but it’s not the same *kind* of object oriented as C++ or Java. Its “object model” is much closer to the old Smalltalk language than those other languages, which kinda makes

it the odd man out these days. Another language with an object model that’s close to smalltalk is Objective-C, the language I used to program NeXT machines, and that today is used to program MacOS and the iPhone. The Ruby and Objective-C object models are almost the same. So… why not take Ruby, rip out the Ruby runtime, and slap the Objective-C runtime in there? You get a system where Ruby and Objective-C objects can toss messages back and forth with ease, where Ruby objects can subclass Objective-C objects and vice versa, and it works without being gross like JNI or (shudder) the way you extend PHP or Perl via C code (which I had to do back at my old startup company). Once you’ve done *that*, why not throw a Ruby *compiler* into the mix? In essence, you can prototype in Ruby, type “make”, and get something that’s got the performance of a compiled Objective-C app. So, why not? Why not indeed. Apple did. It’s not done yet, but it’s out there. http://www.macruby.com/ This is exciting to me for two reasons. Once it’s refined: 1) We may be able to get big fancy Ruby apps to have very nearly C++ performance, and 2) Since it’s only using Apple technologies, and is using the same object runtime as IOkit and stuff, we may well be able to program the iPhone in Ruby instead of Objective-C if we wish. Which, oh, by the way, may make a ton of Ruby “gems” available. Now, these days, my day job is as a (server-side) Java developer, and I do Ruby and Objective-C and iOS development and stuff as a hobbyist (and sort-of have been since NeXTstep 0.8, decades ago — got to play with prerelease Cubes at Carnegie Mellon, which is where Mach was developed, so, well, if you know your OS history, you know why that makes sense). Which means, if you’re right about Java coming back, I kinda win, but if this “compiled Ruby on the Objective-C runtime” thing really takes off, I *also* kinda win. Fun times!

25.

HockeyBias.com 1 mo, 2 wks ago There will be a continued ‘first coming’ of .NET/C# in the enterprise where it is very common (at least here in the midwest).

26.

jason @ mobile website design 1 mo, 2 wks ago My thoughts exactly as I read the article. Java as Java will not return – a mutated version maybe. Mind you, with mobiles taking over the world, Java may still have a part to play due to it simplified acceptability on a mobile interface (or assumed!)

27.

Darwin 1 mo, 2 wks ago Java is fine for large apps but not for mobile devices. Its uses too many resources and is too insecure plus performance is iffy on various platforms.

28.

Orion 1 mo, 2 wks ago With CPU’s getting cheaper and faster and PaaS offerings allowing you to scale horizontally with ease, developer productivity will trump language efficiency in all but the largest scale projects.

29.

Kyle 1 mo, 2 wks ago Couple points. First, you can’t lump groovy in with the other examples because it compiles down into JVM bytecode same as Java. For the most part Groovy is just an alternative syntax of Java. Likewise Scala also compiles down into JVM bytecode. Secondly just

because Ruby has horrible horrible performance doesn’t mean that Java is the next logical choice. Java, via the JVM, has some really nice performance without sacrificing a lot of the nice features that make it easier to work with than something like C. Java however is showing its age and is missing a lot of modern features (or has problematic implementations of certain features shoehorned in). Alternative up and coming languages such as Erlang, Scala, Clojure, Haskell, and to a lesser extent Python and Groovy, have similar, or sometimes better performance than Java, have a great many compelling features Java doesn’t have, and in some cases can even leverage existing Java code. Now, with the exception of Python and Groovy all of the mentioned languages have fairly small developer bases and commercial support, but they’re actively growing, and any of them are possible candidates as “the next big thing”. Python is nice, and has definitely found a good niche, but I’m not convinced it’s compelling enough to displace Java. Likewise Groovy adds some nice improvements over Java, and could probably replace it in a lot of instances, but because it’s so close to Java it suffers from many of the same drawbacks Java does. Of the JVM languages, Scala or Clojure seem like the most likely candidates to replace Java, but Clojure is hampered by the perception of Lisp in the developer community, and Scala is fairly intimidating to new developers. Likewise both Erlang and Haskell suffer from a daunting learning curve mostly due to the incredibly powerful functional abstractions they provide that nevertheless require a completely different conceptual approach to problem solving than most programmers are used to employing. If enough programmers can overcome their Lisp prejudice, or man up and spend the time to learn the “zen of functional”, any of these languages could easily displace Java for web development.

30.

damour 1 mo, 2 wks ago the future of programming is functional programming, all the “new” & “cool” languages are just adding functional programming concepts to their core, espcially the ones you cited + php. It’s the best way we know how to solve scale issues. OO & imperative was & is great for classic GUI’s, but when 99% of code is service & UI’s more and more being just HTML or some other declarative construct all the work is best covered by functional programming. ECMAScript (javascript) is a great functional language, and node.js is a prime example of how functional programming can lead to simple elegant solutions.

RE: Java, they have pretty much completely missed the boat on bringing functional programming into the core laguage. luckily jpython, jruby, & the like have brought functional programming to the JVM, but make no mistake, .NET is leading the way with it’s F# language, and all the great functional aspects being added to C# (closures, lambdas) as far as the pattern of multiple languages/paradigms working in one virtual machine. RE: your point about waiting for the DB (or other resources). The solution to this is asynchronous programming, which in turn is solved by functional programming. That’s why it’s the future or programming. SSD’s don’t solve the waiting for resource problem. If you’re a developer and not excited about C#’s upcoming new async model, then you haven’t looked into it enough yet. Waits no longer become an issue. The only barrier left is the disconnected/synchronous request-response nature of HTTP, but websockets and the like are trying to break down those barriers too.

31.

Gustav K 1 mo, 2 wks ago I LOVE your way of reasoning! Funny that for once you applied the same method to a technology perspective, not just business.. And being an oldschool C and Java develpoer, I have no regrets over your conclusions. As far as I know, several really large companies are skipping the Solid State disk level, and go directly to In Memory databases. I work with SAP products, and SAP is about to release such a solution, focused on their Business Intelligence system, so the transition is close by.

32.

Chris Smith 1 mo, 2 wks ago There will be a second coming in Java, but your assertions are just simply wrong, especially from a technical point of view. I mean SSD’s? C’mon. Compilation is a non-issue i.e. looking at Eclipse, it compiles stuff on the fly.

The reason people switched from Java is based on needs. Some people shifting out web sites don’t need the dev overhead Java – that is it. They are shifting noddy little applications out. Now most of the other side of the Java guys (the enterprise lot) who bothered to switch, switched to .Net/CLR platform which is turning out to be expensive to scale. I’ve seen a lot of new projects being shifted out in Java because it’s more cost-efficient, even from MS partners recently. And for reference, Ruby is not easier than Java: it’s just different!

33.

jeffh 1 mo, 2 wks ago Boulderdash to java. On the web, json > xml and dynamic is better than statically typed. You have something with optimizations but it is multicore that is important. The winner will be something akin to python & pypy http://pypy.org/ Code yal8r, J

34.

Sean Jensen-Grey 1 mo, 2 wks ago What Bob is getting at is this, “We can afford to use slow language _implementations_ because we have so many other current bottlenecks, once those bottlenecks are removed, these slow runtimes will stick out like a sore thumb.” And that the biggest bottleneck right now is the database using spinnings disks where SSDs will provide at least two orders of magnitude of IOPs (think disk seeks). I agree, the JVM is already gaining more *popular traction*, it never lost traction, it just wasn’t cool. But cool doesn’t really matter, websites that perform and stay up matter. The dynamic language crowd would say that, “flexible websites that are quick to write and deploy matters.” And both are right. The argument that he makes for SSDs showing the inefficiencies of slow runtimes also holds for runtimes. JRuby (on the JVM) is damn fast, PyPy (just in time compiler for Python) is also damn fast. You

can have dynamic and fast. Programmers are always trying to find the right balance between productivity and speed, and yes the SSD changes the equation.

35.

Alanl 1 mo, 2 wks ago “Groovy is Java” — well, yes, in the sense that most Java programs are valid Groovy programs. But Bob’s point is speed, and currently Groovy does _not_ match Java (nowhere close) in speed due to all the dynamic dispatching and meta class handling required at runtime. Groovy++ (an attempt to introduce static types and type inferencing into Groovy) shows some hope of closing the performance gap, but, sadly, in some ways Groovy++ is _not_ Groovy (some valid Groovy programs have different semantics as Groovy++ programs ) I’m surprised no one has mentioned Grails (grails.org — “Groovy on Rails”), which, to many (including me), is Rails done ‘right’. No Ruby in sight. As many have mentioned here it is not Java that will make a comeback (it is long in the tooth and about as much fun as C++ to code in) but the JVM. Since Java, Groovy, Scala (the one to watch) all compile down to interoperable class files, your web service can use Tomcat (Java) to host Grails (Java and Groovy) to vend GSPs (Groovy as scripting language to generate web pages) while getting the heavy lifting done behind the scenes in Scala (did I say to watch out for Scala ?) which offers an elegant mixture of object oriented and functional programming, with static typing (but using type inferencing so you don’t need the syntatical verbiage of Java to get your type checking done at compile time rather than debugging it (ha!) at run time). Oh, and in some cases Scala is _faster_ than Java (given the sophistication of the Scala compiler it can sometimes emit more efficient byte codes). Just my (longwinded) 2c. Alanl

36.

Daniel Sobral 1 mo, 2 wks ago

You are looking at the wrong bottleneck. It is not application speed that is a bottleneck — it is programming speed. While application speed is a major consideration when you have effectively won, reason why facebook compiles its PHP to C, that is a problem few people have. No, the problem for most people creating web apps is to have something faster than the competition and to adapt faster than the competition. Slow beats non-existent every day. And THAT is the real reason why web frameworks are mostly done in dynamic languages — Ruby on Rails, Python on Django, Groovy on Grails, etc. It optimizes the time it takes to build and modify these web applications, not the time it takes them to run. Which is why Twitter is still front-ended by Ruby on Rails, even though it uses other languages on performance-critical elements. As for application speed, JRuby, that is, Ruby on JVM, is pretty solid nowadays. It gains you most of Java’s performance without losing anything in expressiveness and flexibility. I do agree with others that JVM is making a comeback, on the backs of other languages running on it: Scala, Clojure and JRuby just to name a few. On the other hand, the asynchronous character of modern web applications is very well served by Javascript, so I expect Node.js to be quite successful as well.

37.

Dean 1 mo, 2 wks ago Did Java go away? I don’t think any of the languages mentioned above will go away, maybe some shifts along the way. And may a paradigm shift will come along with a new language that will surprise and please. Since we are really over due for one I think.

38.

Jack Green 1 mo, 2 wks ago Java never left and never stopped growing. All the languages developed over the past decade have been fads. In the mean time, Java became the elephant in the elephant-sized room.

39.

Chris 1 mo, 2 wks ago I see a rather large problem with your argument. That Java does something different than Ruby or Python. All three compile to bytecode that runs in a VM. The only difference is that Ruby and Python call theirs an interpreter. This is mostly because the compilation happens on the fly. I can’t speak for Ruby, but Python actually outperforms Java for most tasks. The exception being complex math, but for that there’s Numpy. Also, the concern these days is with horizontal scalability. Very few people are concerned with the performance of one request. If they are, the biggest gains are achieved client side. I find it odd that you didn’t attempt to measure/justify the performance improvements gained by SSDs. Assuming that SSDs make databases fast enough that they are no longer the bottleneck(a difficult assumption on my part.) The next bottleneck would be the network, not the runtime. This is assuming an io bound workload, which is most websites.

40.

Chuckie 1 mo, 2 wks ago Wow Bob, Great troll piece. Historically the interpreted language to compiled language to interpreted language cycle has always been largely based in hardware performance, i.e., if the hardware is fast enough then interpreted is likely okay. Otherwise, compilation is necessary. Where you argument falls down for me: 1) JRuby, et al., are written on top of the JVM negating the performance argument 2) Java continues to increase in complexity 3) Scala may well be a “better” Java While Java has become entrenched in the enterprise as the new COBOL, it’s fallen out of favor as a development language for many reasons, not the least of which is Sun/Oracle dropping the ball constantly. Like COBOL, Java will likely have a long lifespan. Like

COBOL, it will continue to decline in popularity in the face of the language of the day with all of the shiny new features that Java takes forever to implement. If you’re banking on a resurgence of Java as a popular language, you might want to also look for the Tooth Fairy, Santa Claus, and an honest investment banker.

41.

Greg 1 mo, 2 wks ago PyPy says “Sup?”.

42.

James 1 mo, 2 wks ago Forget spinning disks? Not for a while. While a single SSD (or two) in a Single Server is sweet, it doesn’t scale as well as SAN Attached Storage (or iSCSI or NFS or whatever) for that Database Cluster where I have racks of processing power. I still rely on my SAN. But you make a good point about the spinning disk. SSD’s are still too expensive for SAN’s to be price competitive but they are getting there. And with auto-tiering, they are getting even better, but I still don’t trust tiering with my most important data. Now, if you are a single developer and you need the speed and you don’t have to worry about scaling out, then forget SSD and go Fusion IO. Now that is FAST!

43.

Julian 1 mo, 2 wks ago that is why I would personally pick http://helma.org and/or http://ringojs.org over Ruby on Rails and NodeJS. Having JVM as the bottom layer is the best thing I ever picked for a platform.

44.

Lorenzo 1 mo, 2 wks ago I’m afraid you have failed to consider that any, and I really mean any, language that is interpreted and slow today can be compiled with an optimizing compiler and be made really, really fast. There is even a compiler to take java to machine code rather than to jvm bytecode.

45.

Scott 1 mo, 2 wks ago Bob, you’re right, the 2nd coming of Java is at hand. The problem in the comments is, everyone who bought into the Ruby/Python/PHP frameworks bit still believes they’re right. However, they’re just not running a high enough volume site to realize how wrong they are. Sorry script fans, but compiled languages top scripting frameworks for serious projects and honestly, this is the reason the 2nd coming of Java is more of a resonance than anything else. Java still powers the big commerce sites, and the JVM does the heavy lifting even for “Web 2.0″ sites like Twitter (see Scala http://www.scala-lang.org/). Even if functional languages are “all the rage” as I see in some comments, they’ll still run on the JVM (again see Scala). The problem is programmers get bored and need the “nextbig-thing.” For a while the Java language stagnated and the interesting developments have been in 3rd party frameworks like Spring. Developers lost interest. However, as an IT manager, I can tell you that the majority of the developers I’ve interviewed over the past few years almost always have more or more bullet points like: “Ported .net application X to Java,” or, “Ported Rails application Y to Java.” When I ask these developers why, the answer is almost always, “Application X ended up being useful to the company, so to deploy it company-wide, we had to port it to Java.” The takeaway is that Java never really went anywhere. Developers just got bored of it. However, at the end of the day, the enterprise applications are always ported to a language that runs on Sun’s JVM.

46.

CdrJameson

1 mo, 2 wks ago Javascript is the new C++; Its dirty, but it works. Java still needs compiling (ie. taking your punched cards to the mainframe) so isn’t going to gain popularity amongst non-programmers. Ruby is the new Cobol.

47.

Sean Stapleton 1 mo, 2 wks ago I think you’ve missed a critical aspect of this, Bob, and it undermines the whole of your reasoning. Several other commentors have hinted at it, but I’ve not seen it stated explicitly: ** You are assuming that speed is what matters in selection of a language/platform. ** We can lease a *quite* beefy server for $1500 / month. Add another 33% for network infrastructure (load balancer, etc) and call it $2000. I’m sure others will point out that this is overpaying. What if we found that language+framework “X” in comparison to c++ / java ; allowed us to extract an additional Y% productivity benefit from our development staff of Z developers. For what what values of X and Z does it become monumentally stupid to code our new web application in java vice “X”?

48.

roboprog 1 mo, 2 wks ago Why is Scala intimidating? I admit, the opening chapter or two in the book I bought seemed to go out of its way to make Scala look odd, but it’s not that different from other non-Java languages (functions, closures, tuples like Python, Ruby, or even Perl). Plus, you can experiment with little scripts on top of existing Java code in your “app portfolio”. Yummy!

49.

roboprog

1 mo, 2 wks ago >> Ruby is not easier than Java Really? I like the brevity of Ruby, from what little I’ve done of it, compared to Java. “Struts” (or other XML domain specific languages) anyone? “Now drop and give me 20 XML push-ups!”

50.

Euro2cent 1 mo, 2 wks ago > the kids who wrote Rails were too cool for Perl, which they saw as old school. But Ruby has nothing on Perl. Priceless. But, getting back to your point, which was that with SSD, fast “disk” access would make language speed matter: are you bonkers? Have loaded any “regular” web page lately? It’s a clusterfuck of slowly loading ads from ten different sources, plus Flash animations soon to be replaced by CPU-sucking in HTML5 approved fashion. And embedded videos. How the hell is the speed of the language that loads the 10% of real content going to matter?

51.

roboprog 1 mo, 2 wks ago Slow implementations? I’d sure like to see more variation on memory management. Simply having generational GC more often that full sweep GC isn’t good enough. I’d like to have a reference counting option on some popular languages. Even though it breaks the semantics “a bit” (understatement, I know), it preserves locality of reference enough to avoid marching most of 4 GB of data through a 4 MB level N cache on a regular basis.

52.

roboprog

1 mo, 2 wks ago Exactly: Java (the language) *is* the COBOL of the 21st century.

53.

monopole 1 mo, 2 wks ago Exactly what I was thinking. Jython, Iron Python or Psycho allow for JIT compiling. Given Oracle’s incredible bloodymindedness re Java in Android, Psycho or Unladen Swallow starts looking much better.

54.

JCBaby 1 mo, 2 wks ago I’m not sure you have a clue about Ruby at all. Ruby has way more than just Hashtables and Arrays. It is an object oriented language and you can implement what ever data structures in it that you wish. People also didn’t take up Ruby instead of Perl simply because Perl was old school and they wanted to be new and hip. Ruby offers a lot when you want to create domain specific like languages. The ability in a Rails model to state something like a has_many or belongs_to or any of the other dsl type constructs it has wouldn’t be possible in Perl. What is also readily apparent is that you dont really know what it takes to scale a website. It relies on quite a bit more then how fast a given language is. Using a faster language will get you minimal gains compared caching and load balancing, both of which java based applications need to scale as well. This includes the use of servers like apache and nginx as the first tier of the application to serve static content. There is no use in having ruby or java server up a static file when it can be done much faster by apache. Java is still heavily used in the “Enterprise” (read over blown expensive overly complicated for no reason other then to pay contractors) space. Most people I know are moving away from the JEE based approach because most of the time it is way more than is needed. Java is still really big in the SOAP space as well, and that too is a fading area as corporations find that simple REST based applications using JSON and Javascript get the same thing done a

lot quicker and for a lot less money. Future web development will continue toward the the interpreted languages such as Ruby for sometime to come. CPU speed is getting faster, CPU and memory is getting cheaper and platforms like Amazon’s EC2 that allow for massive horizontal scaling make for ease and speed of development trumping language speed. I dont think you can be any further from the mark.

55.

Francis 1 mo, 2 wks ago Actually you can get have your cake and eat it too JRuby – code in Ruby, run in Java bytecode. There are even debugging tools that chain back to the Ruby source. I know of at least one company in the area, writing kiosk software for hospitals, which are comfortable with Java, who simply say their code is Java – but actually it’s Ruby on JRuby. And JRuby runs much faster than Ruby. Apparently this is mostly an artifact – according to some bright guys who have looked into it – due to a poor garbage collector implementation in Ruby and a great one in Java.

56.

Francis 1 mo, 2 wks ago A wise man once said to me “programming is about representation”. And he’s right. Representation and execution are independent things, mostly.

57.

Adam 1 mo, 2 wks ago You mean like: Response.Write(“Hello”) in C# (I’m certain it’s not more difficult in Java). To say that it’s going to take 30x more lines to do something in java or .NET is just blatantly dishonest. Not to mention, he’s talking JVM, so if you want

your ruby 1 liners there is JRuby.

58.

Dave 1 mo, 2 wks ago Has anyone heard of Android? – it runs a some popular smart phones? This Looks like Java…It Walks like Java: http://developer.android.com/reference/android /net/ConnectivityManager.html And Eclipse tools are the sweetest things ever! The problem with .Net is that it lacked checked exceptions: http://cafe.elharo.com/programming/bruce-eckel-is-wrong/ 0