If you've been paying attention to the Scala corner of the web over the last week, you'll no doubt have heard something about Yammer - an enterprise-focussed social network - switching from Scala back to Java.
If you've been on holidays and missed it all, basically what happened was that Coda Hale, the Infrastructure Architect at Yammer, wrote a private email to the Typesafe team giving loads of mostly critical feedback regarding Scala, but the email was subsequently leaked and became the talk of the town, among both Scala supporters, like David Pollak, and critics, such as Stephen Colebourne.
A Painfully Honest Critique
Firstly, let me summarise the main points in Coda's email:
* Yammer have decided to change their "basic infrastructure stack" from Scala to Java.
* The main reason is that Scala has "friction and complexity" that isn't offset by enough productivity gain.
* Some seemingly simple constructs in Scala, e.g. List, actually have very complex interfaces and behaviour that necessitate explaining a lot of concepts to beginners. The belief by some that this complexity can be ignored except by library authors has proven to be false in practice.
* The most vocal members of the Scala online community are generally very academic in their practice and discussion of Scala.
* Existing libraries seem to be being re-written just because people want to practice their use of advanced functional programming concepts, but these re-writes are then being recommended as the library of choice.
* The Yammer team eventually decided the most sensible way to deal with the Scala community was to ignore it.
* Learning Scala properly is important, but doing so is neither quick nor easy.
* Java is not going away, so the choice to use Scala is actually a choice to use Scala and Java, along with the interaction challenges that brings.
* The Yammer team had "endless issues" with SBT, and found themselves writing plugins to replicate Maven functionality.
* Switching to Maven solved most of their problems, but they found it has been marginalised by the Scala community, with poor support and constant encouragement to switch to SBT.
* The backwards-incompatibility of Scala major releases requires library authors to cross-compile, which has resulted in library re-invention when authors are no longer committed to the project.
* The backwards-incompatibility also causes headaches for developers, which has resulted in many production Scala deployments not being upgraded to 2.9.
* Yammer found idiomatic Scala code performed very poorly. By eliminating for-comprehensions, avoiding Scala's collection library, avoiding closures and marking everything with private[this], they were able to achieve speed ups of 100x in some components.
So that was that. For what it's worth, Coda's email is also quite complimentary of Scala. I think he gives the impression that he likes it and would really like to keep using it, but the realities of making it work in a day-to-day production-deploying team have weighed them down so much that the benefits have been eclipsed.
A Frustratingly Measured Official Response
Not long after Coda's email became public, Typesafe published on their blog what is quite obviously a public response to the email, and it's that blog I'd like to take a closer look at today.
Here are the main points from the Typesafe blog:
* Typesafe are investing in Scala IDE support by contributing to the Scala IDE for Eclipse
* They are addressing the learning curve by developing training courses, but also provided references to some of the free resources on the web.
* 'scalac' is slow because it has more work to do than 'javac', but they are investigating using parallel and incremental techniques to improve speed, with a focus on improving sbt.
* If you don't want to (or can't) upgrade your Scala version, you can purchase commercial support from Typesafe to get access to long-term maintenance releases of previous versions.
* In order to reduce people's major-release upgrade issues, they are planning to fold a bunch of existing libraries into the Scala release .
* They take performance seriously, but are wary of engaging in premature optimisation.
* Typesafe are not just focused on the Scala language and core libraries but also on frameworks to help build applications more easily.
* They describe the Scala community using a couple of niceties as well as the words "opinionated" and "quirky".
* They say there's many places where Scala could be improved and they're hard at work doing so.
* They mention Yammer amongst a group of other companies with successful production deployments of Scala.
What Aren't They Telling Us?
What I think is most interesting about this response is the things it doesn't mention and the places where it's specific about what they're doing to solve issues.
Firstly, there's no mention of Maven. There is some commitment to improving compile times, but they seem to suggest that this will be for sbt users only. It has to be considered odd that Maven has been given so little attention by the chief proponents of Scala. One of the main advantages often cited for adopting Scala is its easy integration with Java, "so you can continue using all your favourite libraries". But the commitment to prolonging the life of people's Java API knowledge doesn't extend to the Java build chain. Should it? Why is Maven important? It's important because it works, and it's almost ubiquitous. It has had years and years of work poured into it and has been tested and improved by feedback from hundreds of thousands of users and plugin developers. It has a global ecosystem that is well understood. It has become a lingua franca; many people would know how to build their project with Maven but couldn't tell you how to build it with javac and jar. If you want to distribute your project to the world through Maven Central via Sonatype's Nexus repository, they've got fantastically detailed instructions for how to do so... with Maven. The Java-fluent world - which Typesafe want to convert into the Scala world - don't need another build tool. We need relatively minor improvements to Maven and its plugins to ensure we can keeping working without having to learn something completely new.
Secondly, Typesafe give no commitment to eliminating the backwards compatibility problems in future major releases. In fact, one of the parts of their workaround - the offering of paid support for people who want to continue using older releases - actually makes it in their interest to not solve the problem. The other half of their workaround - bringing certain libraries into the Scala release - will mean that, as a developer, your backwards compatibility issues will only be solved if your taste in libraries is similar to those of the Typesafe team. If you like a library that hasn't been deemed worthy of inclusion, you'll be left with all the same cross-compiling and "version-x-for-scala-y" dependency issues that you have now.
Thirdly, they seem to fob off Yammer's performance problems as an issue specific to their environment, suggesting that fixing such things for everybody would be "premature optimisation". I've heard this argument before: that it only makes sense for companies like Yammer and Twitter to spend time optimising tiny bits of code because it can save them millions across all their computers. But the same argument applies to small businesses just as well. If my business is growing rapidly, but I have limited cash flow, having a 100x performance increase is going to make a significant contribution to my bottom line if I can serve all of my customers on one machine instead of 100 machines. "Premature optimisation" is a phrase that should be reserved for application developers, not framework developers. Just optimise the hell out of it, please.
Finally: the community. While Typesafe dropped a small comment about the community in its response, its really not an issue that they can solve, though I do think it will greatly effect the measure of their success in the long term. Really, the comments in Coda's email should be a wake up call to the Scala community at large: a sizable Scala software development team, full of very smart people who've written some very scalable and successful software, found the Scala community to be so fractured and unhelpful that they eventually decided to ignore it and, I would assume, not be a part of it. That's not just a loss for the community, but also a warning, because for every developer that finds the community unhelpful and so decides to program Scala in his own microcosm, there will be numerous others who decide to not bother with Scala at all for the same reason. This alone could be a weighty enough issue to relegate Scala to a hobby language in the long term rather than seeing wide-spread adoption in the enterprise community.
Hope and Trepidation
When I originally read through Coda's email I was nodding my head in agreement and hoping that Typesafe would be listening carefully and would take it as an opportunity to shift their focus, maybe just temporarily, but long enough to knock over these major objections. Unfortunately, when I read through Typesafe's response, I didn't see any real hint that they plan to fix the problems that I find most annoying. In some cases I even saw excuses about why they won't be doing anything. I don't think "We're focusing on making sbt better" is a response to "Why isn't there decent Maven support?". I know they've been meeting with influential Scala teams in the days since this response, I just hope they listen to what they've got to say.
So now I'm left feeling a little unsure about Scala. Will it continue to improve for me and people like me? People who like to use IDEA + Maven, not Eclipse + sbt, who are educated in creating applications rather than composing mathematical proofs? Or is the current state of the art in Scala, along with its broad range of minor but resonating annoyances, what I should expect to still be grappling with in five years time? Only time will tell whether Typesafe can navigate this wave of criticism and find a promised land of general popularity, but I think it is an indication that Scala's window of opportunity has entered the waning phase, and now is the critical time at which to capitalise on the extant interest.
What do YOU think?
Do you sympathise with the Yammer team's frustrations?
Are you confident that Typesafe will listen and respond to current criticisms with relevant and prompt action?
Thursday, December 8, 2011
Subscribe to:
Post Comments (Atom)
sbt is a crazy piece of software (at least it's not scalaz *shudder*), and you spend two weeks making it work then hopefully never have to touch your configuration again. The Maven part "just works" for me, so I don't see that side.
ReplyDeleteAs a disclaimer, I'm a Scala fan boy.
ReplyDeleteI think we're all being very impatient with Scala. The force of Scala has been making the right decisions for the long term benefit of the users.
The choice to go with sbt is definitely one of these choices. Going with Maven would have been quick and easy and possibly made enterprise adoption faster. But I don't think that would have been good in the long term. In the long term, it will always be better to choose tools that help with the language constraints (long compilation time, backward incompatibilities) and more importantly take advantage of the language capabilities.
If you look at libraries, it's the same idea: if there is a Scala library for your needs, you just use it, otherwise you would use the Java one by default. I think the build tool is too important to not be tailored to the Scala world, so there has to be an sbt. Now that's where we might have to be patient, very few of the Scala libraries and tools reached version 1.0 and I don't think it's because of the maintainer's humility, I think these 0.X versions just reflect the reality of their stability and documentation.
I'm a Scala fan boy, but I would still wait for a few years before pushing Scala in an established Java shop for core projects. I don't blame the language or the <1 year old company behind it for that, I blame impatience.
I originally read your post about creating a webapp using Scala & Spring. Honestly, i thought that was a bad idea, because in my opinion using a framework of one language with another is not advisable. You may end up not utilizing the language's features and the frameworks features.
ReplyDeleteI am not commenting on the previous post. I tried creating a production web application using Scala. Before going the Scala + Spring route, i looked at Scala frameworks. Most of them looked like someone's hobby except Lift which looked like many people's hobby. There was no proper documentation and my project was not a hobby.
I ended up using Scala + Spring. Over the course of time, i am not getting anything out of using Scala except saving a few curly braces and semi colons. I have no problems with getter/setter in Java btw.
Over a month or so the project developed, i realized i am writing Java in Scala without using any of Scala's features and adding code to make it play well with Java frameworks.
I decided to change the code back to Java. One of the reasons is Scala's complexity. If i write a line of code in Java, i know exactly how it works. Not the same with Scala. There are so many advanced concepts like partial functions and pattern matching even for simple actions like prepending to a List. At this point, i completely agree with Stephen Coleburne. When i read his post, i felt like someone felt the same way as i did.
In a way, Scala scared me. Its that feeling to put something into production without fully understanding how it works that made me to switch back to Java.
IMHO, Scala may never reach mainstream adoption. It may be adopted by purists and some niche companies. The possibility of Scala reaching enterprises is very slim.
On the bright side, learning Scala taught me about functional programming. So i am thinking and writing programs differently.
@Graham Lea: I'm completely with you on the maven part. I'm really *really* grateful for the work David Bernard (author of scala-m2e plugin for eclipse) did a long time ago, and without which I won't be using Scala today. But I have to say that it works quite well, and so, I'm not really sure of what you would want on that topic ? Perhaps you could bring some more precise things that you want to see improve on the maven/Scala front ?
ReplyDeleteFor me, for one thing, I would like to see the scala-m2e plugin be part of typesafe stack at the level as Scala-IDE.
An other would be to systematically give instruction for both Maven and SBT, but I believe that it is more or less already done.
@matthieus: don't mix two different things: 1/ Maven/SBT as an infrastructure build tool, used by a company, and 2/ the one build tool promoted and used by Typesafe to manage their infrastrure and build the Scala-IDE dependency solver.
For 2/, well, most people just don't care. You can use Scala IDE with maven and never know that SBT is used internally, in Scala IDE.
For 1/, it is *totally* illusionary to have SBT gain some traction on the global enterprise world, even less than Scala. Just because apart from hobby project or start-up fully committed into Scala, Scala will come in an existing environment. And if there is something that you change even less frequently than a language or its platform, it's the build tool. Don't forget that that part does not only implies changing developer habits (who you may convince that it is for a better), but also all the sysadmins, integrators and other "jar consumers", who just don't care of these things. They want widely, documented tools, manageable without a developer around - what SBT is not, and won't be in the coming decade (remember: we are talking about people who are *just* starting to accept maven, and still see it as an undocumented developer piece of crap made by Java-minded people who don't know that there is a world out of there javaland with real package management tools like .rpm and .deb, not there silly jar things).
@Blue Jackal: I do understand the difficulties to use the two worlds together - for us, the choice was to do everything in Scala, Java programming was becoming to hurting. But when we used both Java and Scala, I found that Scala bring us a lot of great things: just using the collection library and higher-order function were a real gain (just think to how painful it is in Java to have a nice filter on a collection (or DAO query method) - ok, Guava made it a little better, but it's still years from what Scala allows).
Thnaks,