Andy Czerwonka

early morning rants on software development and whatever else I find interesting

Why Play?

I’ll do a small series of posts describing, in a little detail, the Dolphin architecture and the reasons for making the choices I’ve made. Today I’ll focus on the Play Framework. There were many drivers, but I’ll focus on what was most important to me.

  1. Scala
  2. Scalability & Programming Model
  3. Akka
  4. Typesafe

Scala

The choice of Scala is a personal one. Many argue it’s fantastic, many argue it’s too complex. I will argue it makes me a better programmer. I won’t get into a language debate here, but I will say that it’s a language that is only gaining in popularity and is arguably the best choice for JVM development today and for the foreseeable future.

Scalability & Programming Model

Play is backed by Netty, the asynchronous event-driven NIO framework. I don’t want/need all the Java Servlet legacy. NIO gives me much better throughput and lower latency. Play also gives me a stateless programming model that allows me to scale out if necessary. In terms of developer productivity, Play’s roots came from a group of developers that wanted Rails-like development productivity without the Ruby baggage shortcomings. They wanted a Ruby-esque cruft-free language, but they weren’t willing to give up type safety and a decent runtime to get it. Who wouldn’t want that?

Akka

Dolphin integrates with many esi.manage nodes. I need a scatter/gather type data-flow capability and Akka gives it to me, very naturally and efficiently with the actor programming model. That combined with NIO gives me a very scalable solution, with even one server node.

Typesafe

Typesafe spent much of 2012 hiring the some of the best Scala developers out there. Some would argue they’re hoarding! ;-) Martin Odersky, their Chairman and Chief Architect, is the main author of Scala and has endorsed both Akka and Play as part of their technology stack. Typesafe is well funded and I don’t see them going anywhere soon.

Comments