The "Promise pattern" is extremely awful for Java. Yes, Play does allow Java developers to do Async I/O by means of Futures/Promises. That doesn't make it any less awful and a quick search on Play's mailing list should highlight it. The reason for it is because working with Future/Promise instances involves a lot of calls to map() and flatMap(). In comparison to java.util.concurrent.Future (which sucks), these Futures are non-blocking and can be processed and transformed without doing a .get() ... We aren't talking about one or two calls, but rather about chains of calls. Scala is a language designed for this, it even has monad comprehensions and an upcoming library that should bring C#'s async [1]
Iteratees are also one of the coolest notions for dealing with streams of data that ever came out of the FP world. And if in Java you can sort of limp around when it comes to simple Future/Promise objects, well Iteratees are in a different league [2] [3]
The Play developers did an extremely awesome job by exposing a clean Java API. But some things are sorely missing, as there's no way to expose them in Java cleanly, which is why the internals of Play's server are written in Scala.
Also, it does make sense to compare frameworks in language comparisons. For example you can't compare C# versus Java for web development, without comparing the frameworks themselves. If Play also allows you to use Java, that's only testament to the awesomeness of Scala, of the JVM and of Play's developers.
[1] https://github.com/scala/async
[2] http://mandubian.com/2012/08/27/understanding-play2-iteratee...
[3] http://www.playframework.com/documentation/2.2.x/Iteratees
Sure, Play has some nice concepts - but the fact that it's built in Scala (and that there is a Java API) means that all of the things that it makes possible are also possible in plain old Java! So this isn't a performance comparison by any means, but rather a "look at what you can do in similar amounts of code" comparison, which is a pretty shallow comparison.
Check out the author's previous post where he concludes that Scala is faster than Java (whatever that means, the whole concept seems to ignore the fact that Scala compiles to JVM bytecode) was 18% faster (on a single execution? average execution? author doesn't say): https://jazzy.id.au/default/2012/10/16/benchmarking_scala_ag...
If you follow that argument, what you can do in Java that you can't do by writing bytecode by hand? Or, what you can do with a JVM lang that you can't do in assembler? His argument is that even you can do the same in Java, is so unnatural that (almost) nobody does it.
You haven't made your Java webapps robust and tolerant of failure because you don't like the extra 3 lines of code you have to write? That makes me question you as a developer and the value you place on things, not the language/ecosystem.
Quite the contrary. I (the author) have done a lot of asynchronous Java development using promises and other asynchronous constructs. The boilerplate is a cost that I'm willing to accept.
However, in my experience, working with other Java developers as well as consulting and providing support to quite a number of enterprise companies full of Java developers, I find time and time again that it is not a cost that other Java developers are willing to accept. You provide them with fluent async libraries, you educate them again and again why they shouldn't block on calls to remote clients, you provide sample code, and they ignore your advice because the code is too hard to read. I'm not saying that all Java developers are like this, I'm just saying that from my observations working across many enterprise companies, most are like this.
And do you think those developers are likely to adopt Scala?
Java is one of the most popular languages and so statistically you're going to find a lot more poor talent out there. If they can't handle 2 lines of boilerplate I shudder at the horrors those same folks would unleash with Scala.
He is not comparing Scala vs Java. He's comparing Play Framework (async i/o) vs. a Servlet that doesn't use async i/o.
He admits later that he purposefully handicapped the Java version. His reason is, he claims that Java's Promise pattern is so hard to program that "Java developers don't do that." Which.. wow. His evidence: he's written a lot of Java apps and he's personally never used it.
And so he just switches off async i/o for Java.
We all know Java has more boilerplate. The Promise pattern is 2 lines of boilerplate code per call, much like an event handler. To go from that to claiming "Java developers don't do" Promise is a huge, unsupported leap.
Also you'd get the impression from his writing that Play Framework is only available for Scala.. but there's a Java API too.