Scala adoption continues to climb rapidly

Various measures have been proposed for tracking the popularity of languages. Measuring the adoption of a programming language is an inexact science, but key indicators (job adverts, stack overflow tags, open source contributors) all point to rapid Scala adoption. Data gathered from, and




Scala books being published at quite a rate

Since it emerged that Twitter was using Scala the number of books on the subject has risen dramatically. Today there are no fewer than 14 books either published or about to be published on the topic of Scala. I’ve previously blogged about Scala books, but since then I’ve found that the list I provided was incomplete and that new Scala books are being published at quite a rate, so I missed some.

The following list of 14 Scala books [update:added another book] should be exhaustive, but if you know of any Scala books that I left out feel free to add a note in the comments or discuss which is your favourite.

  1. Scala for the Impatient perhaps the best book for learning Scala
  2. Programming in Scala Detailed coverage by Martin Odersky himself
  3. Play for Scala (covers version 2)
  4. Scala in Depth
  5. Programming Scala Scalability = Functional Programming + Objects (Animal Guide)
  6. Programming Scala Tackle Multi-Core Complexity on the Java Virtual Machine
  7. Actors in Scala
  8. Scala in Action
  9. Lift in Action: The Simply Functional Web Framework for Scala
  10. The Definitive Guide to Lift: A Scala-based Web Framework
  11. Introduction to the Art of Programming Using Scala (Textbook)
  12. Functional Programming in Scala
  13. Steps in Scala: An Introduction to Object-Functional Programming
  14. Beginning Scala

I didn’t count this one, but note that there’s also a book on Play (2) for Java

Real world feedback from a Java dev using Scala

It’s no secret that a large proportion of Scala programmers originate from the Java developer community. I’ve been writing Java code since the late 90’s and have recently starting doing some dev work in Scala. Since I fall squarely within the target audience for Scala I’ve decided to share my experiences and impressions using Scala from a Java programmer’s perspective. Overall I’m very impressed by Scala and plan to use it more, but do have plenty of constructive criticism which I provide at the end of this blog post.

The first thing that struck me when reading up on Scala was just how many times I thought “that’s a really good way of doing things, it’s much cleaner than the way Java does it”. I’d been reading up on the language for a few months and experimenting with code, but I’ve now used Scala for actual dev work and I’ve learned a lot. The standard approach for learning to code in Scala is to start using it as “java without semicolons“. This was how I started a few months ago and I’ve gradually learned more and written more idiomatic Scala. The result of writing code the Scala way is code which is much cleaner (and more compact). At first it seems like you’re simply saving yourself a bit of typing over Java and not asking the IDE to generate code all the time. That doesn’t seem like much, but as I learned and coded more Scala I began to realise just how much easier it was to express ideas. Everything in Scala just seems to fit together better. Strings, Arrays, Lists, StringBuilders etc. all “feel” the same with common syntax and methods for common tasks such as accessing values, and adding items. Methods like groupBy, filter and map make common tasks such as processing a list of items surprisingly simple.

Overall I was very happy my decision to use Scala. The code was clear, it ran as fast as Java code and simply put the best word to describe Scala is elegant. For the first time in about many years I find myself wanting to switch my primary dev language. In terms of tooling and documentation I strongly recommend the IntelliJ Scala plugin (intelliJ has an open source community edition of their IDE these days and the plugin is free $0). In terms of books to learn Scala I found Scala for the Impatient (published a month or two ago) to be by far the best introduction to the language.

I was working on a Java codebase after the Scala work, and it struck me how dissatisfied working with Scala had made me with Java the language. It was like taking a giant leap backwards after being spoiled by the elegance of Scala.

As stated in the introduction I’m very pleased with Scala, but do have some constructive criticism to provide. It’s quite a long list, so before anyone tries to twist this as a “anti-Scala” post let me make it clear that if I were to come up with a similar list of issues for the other languages I use that list would be significantly longer. Here goes:

[Update: check Simon’s response in the comments. Very informative!]

  1. The syntax for providing package level access to a method (a very common need when writing unit tests) is rather nasty: private[mypackagename] def doStuff = {…} Even the Java equivalent of void doStuff() looks better.
  2. Some Scala standard library classes are slower than their Java counterparts e.g. HashMap and StringBuilder. Scala’s mutable Map doesn’t seem to provide a constructor that lets me specify initial capacity (so I’m forced to pay the cost of rehashing). This is easily worked around by using Java collections together with the implicit conversion classes provided by Scala (which work transparently and fantastically well)
  3. Scala API documentation seems very terse and unfriendly. It’s not uncommon for a method to come with virtually no understandable information on what it actually does or a nice example. I very frequently found myself on StackOverflow to figure out how to use classes. [update: to fast-track better API docs perhaps providing a wiki-fied version would enable more community contributions]. Due to alphabetical sorting of method names overloaded operators are always at the top of the method listings. This makes the docs for a class very intimidating for beginners. Just move the operator docs to the end of the listing so that we’re not faced with the same storm of punctuation at the top the table each time.
  4. Compiling takes a lot longer than Java. For a small project I would estimate (roughly) around a 5x difference. I’m willing to put up with a slower compiler for a better language, but would appreciate it if it were much faster.
  5. There are some inconsistencies regarding which collections support the readOnly method to provide the Scala equivalent of java.util.Collections.unmodifiableList(). Do I really need to call toMap to make my mutable.Map an immutable one? I should probably check the source to see if the toMap call is expensive or not.
  6. The various collections interfaces were a source of confusion. In Java the common class to use is Collection. In Scala I’m not so sure there’s Iterable, Traversable, GenTraversable, TraversableLike, GenTraversableLike, TraversableOnce, GenTraversableOnce, Iterator etc. There seems to be an endless list of options. If I invested a day reading up on the differences I could probably figure it out. For now Traversable or Iterable seem to be reasonable choices for a java.util.Collection equivalent. [update: it seems the non-intuitively named GenTraversable is the preferred choice]
  7. Looking at my profiling data implicit conversions do appear to generate a small amount of overhead (apparently this is to be fixed in 2.10)
  8. for loops seem to introduce more overhead when iterating compared to while loops or Java for loops. There was some talk of optimizing this in 2.10