Hacker News Reader

Comment by abalone | Hacker News Reader

This comparison is extremely flawed.

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.

View on HN

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...

> 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.

The Quasar[1] library brings a more powerful async than C#'s to all JVM languages.

[1]: https://github.com/puniverse/quasar

I agree. If your argument is that doing X in language Y is bad because you have to write a few extra lines of code, and therefore no one (meaning the author) does X, that's an argument that reflects most poorly on the author himself.

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.

> and therefore no one (meaning the author) does X

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.

>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?

That's like publishing an article proclaiming C++ is slower than JavaScript because it's hard to program correctly.

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.

Why would a mostly similar language on the same runtime even help you scale that much? Surely it's about frameworks and technologies!

The author is very clear that you can scale Java and Scala in the same ways. But doing this in Scala is much more idiomatic and concise.

In the past few months, I have found the relative simplicity of vert.x trump play where ever an asynchronous framework needs to be used. And for everything else, there is the Servlet API.

Reply on news.ycombinator.com