Scala at Yammer (2011)
eng.yammer.com
eng.yammer.com
I don't know how many of these problems have been solved in the last couple of years.
SBT has improved quite a bit since the 0.7/0.10 days. Still a bit of a mess. That said, we have an SBT project with multiple subprojects, multi-JVM testing and lots of other stuff and we don't feel that our Build.scala has gotten out of hand. That said, many others feel differently.
IMO, the collections libraries have also improved. The problem of the collections library details bubbling through the API has been largely fixed though others may disagree. Can't attest to performance as I haven't profiled the Scala collections.
Most of the Scala we write is within the context of Akka where idiomatic patterns are well established. Plus, the community is quite strong with most (all?) of the Akka devs active on the mailing list.
There are still some poorly designed libraries popular within the Scala world. The Dispatch library is a good example of this. OTOH, there are great alternatives. Play's HTTP client library is very straightforward, for example, an HTTP GET: WS.url(myURL).get(). None Dispatch's periodic table gobbledygook.
We're quite happy with Scala. An example: originally, our backend was going to be in Java but I convinced one of our founders to give Scala a shot. In one sitting, his first time writing Scala, he wrote the first pass of our analytics service and it was correct the first time it compiled.
. . . engineers need to have an accurate mental model
of how these libraries work or they shift into
cargo-culting snippets of code as magic talismans of
functionality.There's a whole galaxy of apps out there that to consumers seem redundant, but cater to enterprises. Dropbox, Facebook, Twitter, etc., etc., etc. all have competitors that are targeting the enterprise market they have either ignored, abandoned or burned.
I don't know the space well at all, these are just observations from a distance.