Unfortunately, we found developer productivity in the Java/Scala world to be a huge problem. We also found that most Java/Scala web stacks, based on servlets, were far behind other web frameworks (RoR, Django, etc) in terms of keeping up with the requirements of modern web development. Play helps on both fronts: it dramatically improves developer productivity and handles all the requirements of a modern web stack (MVC, web sockets, powerful routing, easy JSON handling, DRY form handling, etc).

Is it better than RoR, Django, Node? In some ways yes (e.g. Play's reactive programming model is dramatically better than JavaScript's callback mess), in some ways no (e.g. it's hard to compete with dynamic/interpreted languages for pure reload time). Is it better than everything else in the Java/Scala world? We think so.

With optional static typing you can pretty much pick and choose the best mode for each part of your application, which for me seems like nirvana. Even with static typing enabled, I find the syntax more concise and productive in Groovy than I do with Scala (I'm more experienced with Groovy so there's a lot of bias in that though).

The static compilation added in Groovy 2 is much faster than dynamically-compiled code but is still buggy e.g. http://stackoverflow.com/questions/14774709/groovy-2-1-0-wei.... It was written by one developer, and first shipped in Grails only 2 months ago, which doesn't even seem to use the static compilation features (correct me if I'm wrong). Let the Groovy/Grails developers eat their own dogfood first before recommending Groovy's static compilation to others.

the whole servlets/jsp/jsf thing is dead imo, is that where you guys were losing time?

Play makes this dramatically faster/easier. TDD is better with Play as well: the plugin support, strong test tools, and sbt's ~test command are amazingly productive.

Regardless, thanks for your post, I'll give Play a go!

Our Play backends, if they use JDBC to talk to a database, are fully blocking, since pretty much all JDBC drivers are blocking. One of the nice things about Play is it's easy to configure the thread pool to handle this configuration as well.

Not really. I don't see what features Play Framework has that are revolutionary or things that no other framework running on the JVM/Java wasn't able to do before.

"Rapid iteration" is the kind of "feature" that every framework claims to allow. No one advertises they allow "slow iteration".

Rapid iteration is probably obvious for PHP, Rails or Django, but on the JVM (or .net), it's pretty rare to see a framework that really supports it well.

With Akka you get most of the concurrency benefits you would get from a language like Erlang, but with the benefits of having access to the entire JVM ecosystem.

I am sorry, what ?

Scala isn't functional; Scala is proper (pure) OO in a way that Java never was. Scala doesn't support top-level functions (only singleton objects), which doesn't exactly prevent it from being functional, but certainly suggests that the primary paradigm is still object-orientation.

It just so happens that pure OO, when properly done, happens to embody a lot of features similar to functional programming - Smalltalk is the easiest example of this (eg. the similarities between Smalltalk message passing and Haskell's implicit currying are very clear).

The reason for this is that it's trivial to create a good object system in a purely functional language, so the FP-OO relationship isn't an either-or so much as a 'special case' (ie, OO can be seen as a 'special case' of FP). The converse isn't so true; it's hard and clumsy to build a truly functional paradigm within an OO paradigm.

What GP probably meant is that Scala isn't a good choice for those who are coming from an FP background, since they'll likely notice that Scala seems very OO by comparison (because it is). Even on the JVM, there are other languages (ie, Clojure) which embody functional paradigms more transparently. On the other hand, Scala is a decent choice for OO programmers who want to get a taste of functional programming (or who want to incorporate those paradigms into their code), because Scala allows several aspects of the FP paradigm to come through as well.

If you ask someone coming from ML or Haskell, Scala is more "FP" than Clojure.

If you ask someone coming from Lisp, Clojure is more "FP" than Scala.

Ultimately, it doesn't matter what you call it. Pick your tools based on what they do, not on what other people call them.

This is neither here nor there. Scala has "package objects" and functions put into a package object are scoped directly at the top level of the package. They are not nested within any other object. The only downside to this that I can see, is that at the moment, a package can only have a single package object, which means all the top-level functions for the package have to reside within a single file.

That's quite a claim you're making here. I, on the other hand, pretend that object-orientedness and functionalness are orthogonal concepts.