from Hacker News

Scaling Scala vs Java

by rohshall on 11/10/13, 6:29 AM with 36 comments

• by abalone on 11/10/13, 11:02 AM

  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.

• by coolsunglasses on 11/10/13, 9:34 AM

  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.

• by pron on 11/10/13, 11:24 AM

  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

• by jondot on 11/10/13, 10:11 AM

  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.

• by js4all on 11/10/13, 9:31 AM

  The title is a bit misleading. The blog post is about async calls in Java vs Scala using promises. Good read though.

• by voidlogic on 11/10/13, 5:25 PM

  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.")
    	}
    }

• by willvarfar on 11/10/13, 10:12 AM

  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.

• by huntc on 11/10/13, 10:31 PM

  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.