First of all James Roper is one of the main engineers working on the Play Framework. You're quick to jump to conclusions.
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.
The fact that the author is one of the main developers on the Play Framework means that he should be even more gracious towards the framework/design he is comparing Play against, otherwise he and his project comes off as comparing their project against weak strawmen.
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...
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.
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.
Comments
First of all James Roper is one of the main engineers working on the Play Framework. You're quick to jump to conclusions.
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
The fact that the author is one of the main developers on the Play Framework means that he should be even more gracious towards the framework/design he is comparing Play against, otherwise he and his project comes off as comparing their project against weak strawmen.
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.
The Quasar[1] library brings a more powerful async than C#'s to all JVM languages.
[1]: https://github.com/puniverse/quasar