Scaling Scala vs Java(jazzy.id.au)
jazzy.id.au
Scaling Scala vs Java
http://jazzy.id.au/default/2012/11/02/scaling_scala_vs_java.html
8 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 "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.
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.
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
[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.
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.
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?
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.
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.
This blog post is not great. It's also not about scaling at all.
For one thing, a promises based async implementation is not incredibly helpful when you have a strictly one-after-another ordering of data dependencies.
In the interest of comparison, however, I decided to translate the example code to the equivalent synchronous and asynchronous Clojure code.
https://www.refheap.com/20640
Things to note:
Instead of being forced to use a compiler-assisted construct, promises on Clojure get dereferenced. Dereferencing is the same operation used to get the value of agents, atoms, and refs as well.
Deref'ing (@) a promise over and over is totally okay.
Using promises doesn't make the Scala solution meaningfully or usefully asynchronous unless the handler is yielding its thread while blocking on I/O.
For one thing, a promises based async implementation is not incredibly helpful when you have a strictly one-after-another ordering of data dependencies.
In the interest of comparison, however, I decided to translate the example code to the equivalent synchronous and asynchronous Clojure code.
https://www.refheap.com/20640
Things to note:
Instead of being forced to use a compiler-assisted construct, promises on Clojure get dereferenced. Dereferencing is the same operation used to get the value of agents, atoms, and refs as well.
Deref'ing (@) a promise over and over is totally okay.
Using promises doesn't make the Scala solution meaningfully or usefully asynchronous unless the handler is yielding its thread while blocking on I/O.
I don't understand much of what you've written. Perhaps you can elaborate? Specifically:
> It's also not about scaling at all.
It's about handling many simultaneous connections. How is this not a specific type of scaling, and one that is relevant to many web sites?
> a promises based async implementation is not incredibly helpful when you have a strictly one-after-another ordering of data dependencies.
What does this mean beyond the fact that data dependencies limit parallelism?
> Instead of being forced to use a compiler-assisted construct
For comprehensions in Scala are syntax for the flatMap and map functions. You're not forced to use them, and for comprehensions work with any monad.
> Deref'ing (@) a promise over and over is totally okay.
Mapping a promise (the Scala equivalent) over and over is totally ok.
> Using promises doesn't make the Scala solution meaningfully or usefully asynchronous unless the handler is yielding its thread while blocking on I/O.
What does the IO model of the JVM have to do with Scala futures? Blocking IO operations are blocking, whatever language you use. There are three ways around this:
1. Use nonblocking IO
2. Use bytecode manipulation to transform blocking to nonblocking IO
3. Use a separate thread pool for blocking IO operations.
1 and 3 are the typical solutions in Scala.
> It's also not about scaling at all.
It's about handling many simultaneous connections. How is this not a specific type of scaling, and one that is relevant to many web sites?
> a promises based async implementation is not incredibly helpful when you have a strictly one-after-another ordering of data dependencies.
What does this mean beyond the fact that data dependencies limit parallelism?
> Instead of being forced to use a compiler-assisted construct
For comprehensions in Scala are syntax for the flatMap and map functions. You're not forced to use them, and for comprehensions work with any monad.
> Deref'ing (@) a promise over and over is totally okay.
Mapping a promise (the Scala equivalent) over and over is totally ok.
> Using promises doesn't make the Scala solution meaningfully or usefully asynchronous unless the handler is yielding its thread while blocking on I/O.
What does the IO model of the JVM have to do with Scala futures? Blocking IO operations are blocking, whatever language you use. There are three ways around this:
1. Use nonblocking IO
2. Use bytecode manipulation to transform blocking to nonblocking IO
3. Use a separate thread pool for blocking IO operations.
1 and 3 are the typical solutions in Scala.
> a promises based async implementation is not incredibly helpful when you have a strictly one-after-another ordering of data dependencies
I don't understand what you mean. Of course it's helpful.
In Clojure you don't see this because in Clojure people don't work with Monads.
> Using promises doesn't make the Scala solution meaningfully or usefully asynchronous unless the handler is yielding its thread while blocking on I/O.
The idea of Futures is not to use blocking I/O, but rather to either:
1) use non-blocking I/O, or
2) delegate the blocking I/O call to some sort of actor, then continue the execution once that's done
Both are possible and quite easy.
I don't understand what you mean. Of course it's helpful.
memcached.get[String]("someKey") flatMap {
case Some(value) => Future.successful(value)
case None =>
database.query(...).flatMap { value =>
memcached.set("someKey", value, 10.minutes)
}
}
In Clojure you don't see this because in Clojure people don't work with Monads.
> Using promises doesn't make the Scala solution meaningfully or usefully asynchronous unless the handler is yielding its thread while blocking on I/O.
The idea of Futures is not to use blocking I/O, but rather to either:
1) use non-blocking I/O, or
2) delegate the blocking I/O call to some sort of actor, then continue the execution once that's done
Both are possible and quite easy.
Monads are used in Clojure, just not for this particular use-case because it's unnecessary the majority of the time.
A good example of monad (and macros) use would be: http://github.com/clojure/core.async
A good example of monad (and macros) use would be: http://github.com/clojure/core.async
Well, it's a good thing we've got Java lightweight threads[1]. They let you write synchronous, blocking, simple code, which it transforms to asynchronous calls. It gives you this "Scala scalability" to Java (or any JVM language) without wrapping your head around functional constructs. Scalaists can think of it as an async macro that works for all JVM languages, and can span a whole call-stack rather than just a single expression.
[1]: https://github.com/puniverse/quasar
[1]: https://github.com/puniverse/quasar
I played a bit with Quasar a week ago. I really liked how simple it is to wrap existing async calls (with callbacks) using FiberAsync and use them in synchronous code.
It's still a bit to early for me to migrate from Akka. But thanks for the great work you are doing!
It's still a bit to early for me to migrate from Akka. But thanks for the great work you are doing!
Every now and then comes such an article and nudges me towards Scala again. It can really be an elegant and succinct language that can be all-encompassing.
But although I have a production running Scala project, I cringe every time I have to work with Scala just because of the tooling. It's sad to see that SBT is cryptic and IDEs are slow and misleading.
When I work on the JVM I prefer Clojure. I think lein makes an exemplary development, build, and dependency management tool. I wish Scala had that.
But although I have a production running Scala project, I cringe every time I have to work with Scala just because of the tooling. It's sad to see that SBT is cryptic and IDEs are slow and misleading.
When I work on the JVM I prefer Clojure. I think lein makes an exemplary development, build, and dependency management tool. I wish Scala had that.
Intellij IDEA isn't so bad as an IDE (it's faster and less buggy than the Eclipse Scala plugin last time I checked), but SBT is utterly horrible. It's so awful I'd literally strongly prefer to use Ant (ie clunky scripting in XML) instead.
Yup I second that. Intellij IDEA is currently very good with Scala, especially if one avoids SBT. I use it with Maven and everything works smoothly in a project with several sub-projects and various external dependencies (most to Java libraries).
I suspect the awfulness of SBT is causing a lot of harm to Scala adoption.
I suspect the awfulness of SBT is causing a lot of harm to Scala adoption.
JetBrains has a nightly build out for their sbt plugin. It is not perfect yet but it has worked very well for me.
http://blog.jetbrains.com/scala/2013/07/17/sbt-plugin-nightl...
http://blog.jetbrains.com/scala/2013/07/17/sbt-plugin-nightl...
This always makes me laugh! "Look guys we invented this new functional language - it's awesome" - well cool, now go back and make a decent IDE and tools for it.
Try gradle. It's written in groovy, but surprisingly nice to use with Scala & Java.
I actually spent a part of the weekend re-evaluating Scala build tools for the who-knows-how-many times now.
Gradle did come up and I was astonished to discover Groovy is now over its performance problems and may very well be a worthy platform to develop web services on!. Only if Groovy had a clear road map and profound backing it would have been the true "Scala killer".
I think it's worth giving Groovy a second chance by its own, and I've set up some time to do that.
And lastly - after looking at gradle as a build tool for Scala - it looks OK, however I don't think I will ever withstand all of the hate and incompatibility from the Scala community because I've deviated from SBT (which is another problem by itself).
Gradle did come up and I was astonished to discover Groovy is now over its performance problems and may very well be a worthy platform to develop web services on!. Only if Groovy had a clear road map and profound backing it would have been the true "Scala killer".
I think it's worth giving Groovy a second chance by its own, and I've set up some time to do that.
And lastly - after looking at gradle as a build tool for Scala - it looks OK, however I don't think I will ever withstand all of the hate and incompatibility from the Scala community because I've deviated from SBT (which is another problem by itself).
> I was astonished to discover Groovy is now over its performance problems
It isn't. Gradle still ships with the slower Groovy 1.x, and Grails, altho it ships with Groovy 2.x, doesn't actually use any of the faster static-typing, presumably because it's still too buggy.
It would be nice if Gradle used Scala or Kotlin as its build language instead, but with a name like "GradleWare", I suspect someone from VMWare is pulling the strings to keep Gradle tied to Grails (and Groovy).
It isn't. Gradle still ships with the slower Groovy 1.x, and Grails, altho it ships with Groovy 2.x, doesn't actually use any of the faster static-typing, presumably because it's still too buggy.
It would be nice if Gradle used Scala or Kotlin as its build language instead, but with a name like "GradleWare", I suspect someone from VMWare is pulling the strings to keep Gradle tied to Grails (and Groovy).
Groovy is backed by Pivotal (http://www.gopivotal.com/)
I do develop a lot with Groovy these days, love it!
I do develop a lot with Groovy these days, love it!
The title is a bit misleading. The blog post is about async calls in Java vs Scala using promises. Good read though.
I dislike how the Java Promises and the Scala code unnecessarily hide the reality of the computation from the developer, take a Go version as counterpoint:
func stockForProdsTO(uid int, timeout time.Duration) (*Stock, error) {
stockCh := make(chan *Stock, 1)
go func() {
orders := ordersForUser(userById(uid).email)
stockCh <- stockForProds(prodsForOrders(orders))
}()
select {
case result := <-stockCh:
return result, nil
case <-time.After(timeout):
return nil, errors.New("Could not get stock for product before timeout.")
}
}I'm a bit surprised because all my big Java servers have used Netty and are fully asynchronous. I didn't realise there's any big load of synchronous Java servers out there.
The servers in this example were configured to be asynchronous. The clients were not. You may still be using asynchronous clients in your code but James's argument is that Java developers don't tend to do this because it requires a lot of boilerplate. Scala developers do this because it's very low syntatic overhead and frameworks+libraries embrace it.
Developers who don't do something that would give them incredible performance and resilience because "it requires a lot of boilerplate" are bad developers.
Not necessarily, more code means more maintenance which translates to more cost. Adding new features requires more research, more work, more time, more cost. Fixing anything requiring a patch after going production with a new feature would likely be more expensive. Testing tools have to be verified to work with the additional code. This all increases costs which might be OK for some organizations and not so much for others.
That's a different argument though than just "it's more code so I won't do it". If we are discussing performance then the assumption is you have a performance problem you need to fix.
To be clear, my servers are clients of each other and all is asynchronous.
In fairness to James, I think the comparison he's making is in regard to the idiosyncrasies of developers, and that Java developers tend more often than not to use synchronous blocking calls. It is entirely possible to perform async IO in Java of course, but James's point is that being async is a more natural state when using 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.