I attended the Scala Lift Off a few weekends ago and I'm really glad I went. This was my first unconference and my first major Scala event (outside BASE talks) but even as a relative outsider attending alone I felt really welcome and had a great time.
Keynote
Martin Odersky started off the day with
the keynote address, entitled "Scala - The Next 5 Years." The big picture is that he wants
"to make Scala the primary choice for concurrent and parallel programming on the JVM in 5 years," which is no doubt a worthy goal (though not one that's likely going to go uncontested). While he touched briefly on a number of the concurrency
paradigms he plans on exploring and potentially introducing to further this goal, he pointed
out that some of the most important fundamentals of concurrent programming are already
supported. One of the keys in his mind is mutable state, which "becomes a liability when
you want to be concurrent." Scala's strategy of easing traditional Java programmers into
immutability by advocating the use of val and providing support for pure
functional programming is particularly useful here. Even though a Java programmer's first pass
at high performance concurrent programming in Scala might introduce inefficiencies via
mutable state, fixing these problems can be a matter refactoring rather than wholesale
rewrites. This fundamental strength combined with Odersky's plans to further explore actors,
transactions, join patterns, and stream processing is very exciting.
A second highlight of the keynote was a discussion of static typing. Bucking the industry trend toward dynamically typed languages like Python, Ruby and Groovy over the past few years, Scala is statically typed - though I'd note that Scala's static typing feels like a Ferrari to Java's Gremlin. In Odersky's words, "static typing is a key ingredient for reliable concurrent programs, yet programs are annoyingly hard to get right." Even with the advances in the type system, compiler errors can be cryptic, and I can say with personal experience that decisions like co vs contra variance are practically a matter of guess and check to the non-expert. The solution proposed here was better tools: type browsers, type debuggers, and better communication from the compiler. Type systems can be a huge win, and save time in the long run by producing code that works as expected once it compiles. The delicate balancing of designing systems of typed objects that work really well and don't get in the way is perhaps not as well understood or supported as it should be, and it was great to hear Professor Odersky advocating practical solutions that have the potential to really help engineers produce robust software.
The talk also helped further the impression that Scala is beginning to really come into its own as a serious industrial strength language. The list of adopters - including Twitter, eBay, Siemens, and Xerox - was impressive for a young language, and the general tone was confident, upbeat and focused.
Sessions
After the necessary unconference planning session, we broke off into smaller sessions around the room for the rest of the day. I ended up on a fairly practical track, though I would have liked to get to a few more "cutting edge applications of functional techniques" style sessions, as they looked pretty interesting.
Development Environments
Scala development, if this session at LiftOff is any indication, is currently pretty heavily skewed toward IDEs like Eclipse and IntelliJ and almost always uses Maven. I suspect the Maven skew is largely due to the fact that Lift's documentation speaks Maven. The one very notable exception to this was Twitter. During Alex Payne's talk later in the day he explained the "Simple Build Tool" developed in-house to encourage similar project structure and development practices. Essentially a wrapper around Ant and Ivy, it appears to be a lightweight alternative to the often unwieldy Maven.
Collections
There was quite a bit of buzz around the next release of Scala - 2.8 - which is due in
the fall, and for good reason. One of the most exciting pieces of work that will make it
into this release is the cleanup and reorganization of the collection libraries.
While Scala's current collection library is pretty extensive, covering both immutable
and mutable collections, strict and lazy collections, along with a (sometimes) usable
Java conversion library, the whole package feels a little gooky and inconsistent. It turns
out this is largely a result of an organic development process, and the Scala team has given
this key part of the standard library some serious love with an eye toward consistent, coherent design and usability.
Scala @twitter
Twitter made big waves this year in the Scala community by talking quite a bit about its transition away from Ruby backend services in favor of Scala based solutions like Kestrel. As a result, Alex Payne's session on how Scala is being used within Twitter attracted a big audience, even during lunch. He ran through a presentation I hadn't seen, but which is pretty widely available (I think it was this one) and talked a little about the various pieces of open and closed source infrastructure they've built out. Sadly, lunch took priority over my laptop at that point, and I didn't take the best notes.
Scala Tips
The last session I attended was Jorge Ortiz's "Scala Tips," which provided a good summary of some of the best practices being discovered by the community. The talk itself was basically some in-depth discussion of this blog, but various luminaries were on hand to provide commentary and more discussion. One of the more interesting parts of this discussion was an item noting the dichotomy between API and client programming in Scala. While this type of programming is generally stylistically different in any language, I've noticed - and Jorge reinforced - that Scala really enhances these differences. API design tends to be a lot more about thinking carefully about types and the relationships between them, and involves lots of type declaration - even when not technically necessary - and iteration with the compiler to make sure everything makes sense. Client programming, on the other hand, feels almost like a dynamic language. Type declarations are few and far between, structural types provide duck typing-like flexibility, and the REPL allows for convenient exploratory programming.