Q: How did your company start using Scala?
Twitter has been using Scala since at least 2009. While it was still comparatively early, it was seen as a viable alternative to Ruby, the chief programming language at the time. Twitter’s Scala usage came into full bloom during 2010, as we began to break up our Ruby monolith into a larger set of services. The origin story of Scala at Twitter has been recounted previously .
Q: What Scala tools are you using the most? What are the benefits, difficulties?
Most of our software infrastructure is homegrown. We use our build system, Pants , our own systems software stack [3, 4, 5], our own Thrift compiler , large-scale data analytics tools [7, 8], and .. well you get the point. This isn’t to say that we don’t make significant use of all the excellent work happening in the Scala community (to which we hope we’ve contributed by open sourcing large swaths of our own infrastructure). Most significantly, we use ScalaTest and ScalaCheck for most of our testing. Many engineers at Twitter also use the various IDEs available for Scala.
Q: What devops and testing practices are you employing?
By this, I assume you mean: how do we mix operations and development? I’d say that most engineers are involved in production. There’s no wall over which we throw code. While it varies a bit by team, we have engineers who are dedicated to focus more on operational aspects of the software we run. We call them Software Reliability Engineers, or SREs. The SRE role is a mixture of a traditional developer role and operations role. Their job is primarily to make our software more operable. That said, operations is everyone’s responsibility, and ‘traditional’ engineers carry pagers (or at least iPhones) just like our SREs do.
Q: Do you have several Scala "tribes", -- "FP-extreme", "Java-like", etc. -- and how do you reconcile them? What management approaches work best with Scala teams?
Certainly we try not to. In a large organization with a lot of code, it’s important to retain a certain degree of uniformity. Code should feel familiar, use the same idioms. We put a lot of focus and effort into enhancing code readability. Not just readability in general, but readability for the average Twitter engineer. This often precludes using more cutting-edge and esoteric techniques, but we believe we’re better off eschewing possible benefits for greater understandability from a larger group of engineers.
Also, it’s important to not forget that we’re building systems. If our use of a language gets in the way of that, then there’s something wrong.
Q: What conference talks/events are you looking forward to the most?
SOSP. I love the vibe and energy from that crowd.
Q: What do you want to see covered more at the conference and SF Scala meet ups?
I would like to see more discussion about how to introduce Scala, and FP more generally, into large organizations. What works, what doesn’t? I would also love to see more quantifiable experience reports. How do we know what we’re advocating is actually working? How do we know it’s good?
Q: How do you go about Scala adoption? What is the future of Scala in your organization?
Our Scala adoption is already very large, and only growing. Scala is a very valuable tool in our relentless pursuit of systems building. Not only do we use it widely, but I feel like we do a good job of using its various strengths. Projects like Finagle and Scaling are both widely useful, and they each exploit different strengths of Scala as a language. If anything, our experience has been that Scala has been a very versatile tool, and I’m sure we’ll continue to exploit that.
We use Scala in anger, as they say.