Metaphysical Developer

Scala: The Successor to the Throne

Posted in Languages by Daniel Ribeiro on July 29, 2009

It has been a while since Java was the sole language running over a JVM. Scala is another such language which gained a lot attention recently for being used to scale Twitter‘s backend. Scala differs from most other languages that run on the JVM, such as Groovy, JRuby and Jython, as it is statically typed. This means that, similar to Java and C#, the types must be known at compile time. Scala is usually introduced as being both OO and functional. While this statement is true (and daunting, as many people are uncomfortable with the f*** word), it fails to grasp the important aspects of Scala.

Among the most direct benefits of using Scala feature:

  • Compatible with Java. Kinda obvious (as so are all the other 200+ languages over the JVM), but it is such an important feature that should not be overlooked. This means that Scala can use all Java libraries and frameworks. Which shows respect for people’s and companies investment on the technology.
  • Joint Compilation. This means that, like Groovy, Scala classes are compiled to Java classes, and therefore can be used on Java projects (even by java classes on the same project they are defined). Even if your team decides to make the complete move towards Scala, this can be useful integrating with dynamic languages via JSR 223.
  • Type Inference. If the compiler can guess the type (and it usually can), you don’t have to tell it. This allows Scala code to be as concise as dynamic languages, while still being type safe.
  • Implicit conversion allows you to achieve in a type safe way what extension methods do for C# and open classes (mostly) do for ruby. That is: add methods to types you might not have not defined yourself (such as strings, lists, integers). This is one of the features that make Scala DSL friendly.
  • Object immutability is encouraged and easy to accomplish. Scala even comes with immutable collections built-in.
  • Getters and Setters are automatically generated for you. If you don’t want them (if you only want setters for example), you have to explicitly make them private. Which is not a problem, as the common case is to want them.
  • Scala has first-order functions and implements an enumeration protocol (with the iterable trait), which helps keeping code clearer, more concise, and brings several other benefits.
  • The Actor programming model eases up the development of highly concurrent applications.
  • Exceptions don’t have to be explictly caught or thrown. It can be argued that having checked exceptions does more harm than good.

These features alone would be enough to make Scala a very interesting language, and worth being heralded as the current heir apparent to the Java throne by one of JRuby’s creator, Charles Nutter (a view somewhat shared by Neal Gafter). Or even worth of being endorsed both by Groovy’s creator, James Strachan, and by the inventor of Java, James Gosling.  Nonetheless Scala is deep, and there are several exciting advanced features that allow developers to be more productive. But learning such features before getting a good grasp the basics can be quite frustrating, more so without a good supporting literature (such as IBM‘s, Aritma‘s, Jonas Bonér‘s, Daniel Spiewak‘s, Sven Efftinge‘s, the official one, and several others). However it quite is feasible, not only encouraged, to delve into deeper concepts as you need them.

Even though Scala has academic roots (as it shows on its papers page, and some advanced concepts these tackle), Scala has been successfully used on enterprise projects, besides Twitter, such as Siemens, Électricité de France Trading and WattzOn.

Besides all the good points, Scala does have some rough edges. Even though many people are working on overcoming them, they are likely to be relevant on the short term:

  • Incipient IDE support. As Lift‘s author expressed, IDEs for Scala, while undergoing a lot of development, are not what they are for Java. There is poor refactoring support, code completion and unit test integration. Not to mention the fact that most framework support tools will not play nicely with Scala. This can also put off some newcomers, as an IDE can help people learn the language. On the other hand, Martin Folwer relativizes this IDE situation, as a language that allows you to be more productive can more than make up for the lack of sophisticated tools.
  • Joint Compilation is not supported by most IDEs as well. Again, likely to change as Scala grows in popularity.
  • Immutability on a class is not really immutability, since referring objects may not be immutable themselves. And there is no way at the moment to ensure the whole object graph is immutable.
  • Making JSR 223 work perfectly with Scala can be challenging. On the other hand, making it work good enough is quite attainable.
  • Scala doesn’t support metaprogramming. This can be worked around by combining it with dynamic languages, such as Ruby (following a polyglot programming approach), but if you are going to do heavy use of metaprogramming, than using a whole different language may be a better solution (Fan is another static type language that runs over the JVM, similar to Scala, that has metaprogramming support).
  • Frameworks that expect Java source, such as the client-side GWT, will not play nicely with Scala (note that people have made Scala work with GWT on the server-side though). However there is an ongoing project that will translate Scala into Java source.
  • The syntax and some concepts are bit different from Java, such as: inverted type declaration order, underscore being used instead of wildcards, asterisks and default values, many kinds of nothing, no static methods (you need to use singleton objects instead) and other minor things. The documentation walks through this quite nicely though, but keep in mind that it is not an automatic transition from writing Java to writing Scala code.

As Joe Armstrong said, the need for languages that allow developers to easily make use of CPUs with multiple cores will only increase as such CPUs become cheaper and gain more and more cores. Scala is quite suited for such task, while Java’s development is stuck dealing with issues that come from being widely deployed, uncertanties of how open it will be in the future and political issues with some of its main contributors. Given the situation, Scala seems to fit quite nicely the role of the successor to Java’s throne.

Advertisements

11 Responses

Subscribe to comments with RSS.

  1. florin said, on July 29, 2009 at 8:41 pm

    Let’s add one more plus: it’s not under Sun’s / Oracle oversight.

  2. danrbr said, on July 29, 2009 at 9:35 pm

    I did mention this, although quite subtly, on the last paragraph:

    “uncertanties of how open it will be in the future”

    I was not so blunt about the issue, as having a JCP and a big company behind you can be a good thing as well. Of course, Oracle is a very particular big company, with very particular policies towards open source.

    But I digress. About the JCP, I let their members do the talking:

    http://www.infoq.com/interviews/Standardization-Process-Patrick-Curran-Geir-Magnusson

  3. Marty Pitt said, on July 30, 2009 at 4:47 am

    Great article – thanks.

  4. Greg M said, on July 30, 2009 at 5:36 am

    The lack of meta-programming in Scala is not a draw-back. It just isn’t needed when you have higher-order functions and a sophisticated type-system. They let you express the same behaviour in a more declarative (safer) style.

    • danrbr said, on July 30, 2009 at 11:09 am

      It can be a drawback, if you need it a lot. You can work it around with active or passive code generation, but you will have to roll your own. Meta-programming tools is mostly usefull to allow developers to create language facilities instead of asking the language maintainer to do it for them (such as generating a default implementation of equals and hashcode based on a subset of attributes, or making all attributes of all classes inside a package come with @BeanProperty instead of annotating every single instance, or making all public methods synchronized, and so on).

      They are also usefull when creating declarative persistence, instead of increasing coupling and forcing you to inherit some class or mix it in with some Trait. Also, not always the higher-order way is not always the simplest way. If you have to use tons of advanced features to accomplish something that would otherwise be easy to do with Meta-programming, you may have to postpone on creating a more elegant solution until you need it more.

      But sometimes, you just don’t need it. I’d guess that most of the times you don’t need it. Meta-programming is not without its drawbacks as well. But I digress, and this topic deserves a post on its own.

  5. piggybox said, on August 3, 2009 at 11:12 am

    Scala compiler allows you to add plugins which can change the syntax of Scala and add more semantics (http://www.scala-lang.org/node/140) , though it seems more complicated than other ‘macro’ approaches (such as OCAML’s Camlp4) for static type languages, and may cause compatibility issues. I guess most developers just won’t bother it.

  6. Nicholas Sterling said, on March 19, 2010 at 6:48 am

    Interesting article — thanks.

    You mentioned the syntax differences as if you felt they were arbitrary and annoying. For example, referring to Scala’s type declaration order as “inverted” implies that Java’s order is correct in some sense.

    In fact, I consider that change very important. Imagine looking at somebody else’s code and coming across variable foo. What type is foo? You start searching in the code above for the corresponding declaration. The declaration is HashMap<String,ArrayList> foo = new HashMap and it is in the middle of 20 other lines that may or may not be variable declarations — there is no obvious marker to tell you. It takes a while to find the declaration of foo, and by the time you have, the question is not “What type is foo?” but “Now why did I care about the type of foo?”

    Enter Scala. It is no accident that 1) variables come before types in declarations and 2) “var”, “val”, and “def” each have three characters. Your eyes go up, immediately find a var/val/def column, and just to the right is a column of variable names. Brilliant! No lengthy search, parsing Java code to find declarations and then scanning left and right to see if there’s a foo in there somewhere. You have found your declaration and are back on your way without having flushed your mental cache of the reason you cared. You even know whether the value changes from its initialized value. Such ergonomics make a huge difference, at least for me.

    Similarly, the complaint about the lack of static methods (and variables), that “you need to use singleton objects instead” as if that were some sort of burden, is an interesting rewrite of the facts that 1) singletons are a common and highly useful construct and are trivial to create in Scala, and 2) Scala’s singleton objects eliminate one of Java’s warts: static variables and methods are not part of any object. (No, they are not part of the class object.) This is one of the ways in which Scala is more cleanly object-oriented than Java. You can make your singleton object extend another class. You can mix in traits. You can pass your singleton object to another method and that method can access its member variables and methods. Scala’s singleton objects are a great idea; good riddance to statics!

    But I think you were really trying to say that there’s some work to do in learning a new language, and that’s certainly true of Scala. However, you might consider that it is *less* true with Scala inasmuch as far more time is required to master the *libraries* of a modern language than to learn the language itself, and with Scala you have not lost any of the Java libraries you already know about. Not only can you create Java objects in Scala and invoke methods on them, you can even *extend* them in Scala — the latter is not true of, say, Groovy or JRuby.

    Of course it is a call that each developer must make, when to invest the time to learn a new language, and which language to learn. Scala offers Ruby-like expressiveness without sacrificing type-safety or performance, a remarkable achievement. Add to that the fact that it provides a mechanism for dealing with the growing need for concurrency, and I personally think Scala is worth the effort to learn. I look forward to 2.8 and the IDE support promised for Eclipse.

    • Daniel Ribeiro said, on March 19, 2010 at 11:25 am

      But I think you were really trying to say that there’s some work to do in learning a new language

      Yes, that’s why I put them all in one item. It is not bad syntax (in fact I agree it is better), but it is different and require some learning.

      you can even *extend* them in Scala — the latter is not true of, say, Groovy or JRuby.

      Well, not true to Groovy, since you can extend groovy classes in java and vice-versa.

      • Nicholas Sterling said, on March 19, 2010 at 2:21 pm

        Ah! I was indeed misinformed on that point; thanks for the correction.

  7. […] we use Scala?” is a recurring question my peers make me. I think it is fair, since I have advocated in the past that Scala has a lot of strong points compared to Java . However, this question is usually made in […]

  8. […] got pulled away. From the Chief Architect of the Java Platform Group: It’s time for … Plan B. Scala has them though… Possibly related posts: (automatically generated)The Scala Programming […]


Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: