The Future of Scala
In the recently published "Scala: Next Steps" article describing the future of the Scala language, the Scala team details the features of the next three major Scala releases and main goals: to make the language and its libraries simpler to understand, more robust, and better performing.
Scala 2.12 is the next major release and was recently covered in the InfoQ article Scala 2.12 Will Only Support Java 8. The next two releases are code named Aida and Don Giovanni. The main goal for the 2.12 release is Java 8 interoperability, while Aida will simplify collections and Don Giovanni will improve the language and speed up the compiler. The Don Giovanni release aims to collaborate with Project Valhalla, since both projects have similar ambitions.
Project Valhalla is an experimental OpenJDK project to develop major new features for Java that require both changes to the language syntax and VM-level support. Two Valhalla features that Scala hopes to leverage are its new approach to generic typing and value types.
Backward compatibility is not guaranteed, but a source code migration tool will be built to support cross-building between versions. Common Scala code should port easily, but experimental features such as macros may not.
Julian Gamble, author of Clojure Recipes, added some context to the article on Hacker News. He mentioned that the lead developer of the Scala compiler, Paul Philips, did a presentation last year titled "We're doing it all wrong". You can view a video of his talk, or checkout his presentation on SlideShare. Gamble thinks the "Next Steps" article is Martin Odersky's response and commends his practical action.
According to the Scala 2.12 Roadmap, that version is not scheduled for release until January 2016. Several people on Hacker News expressed concern about backward compatibility. Martin Odersky, lead designer of Scala, responded:
We'll try to make the boundary between old and new versions as flexible as possible and both lint tools and language imports will be an important part of that.
Note also that the rewritings we consider are in their majority rather trivial. E.g. insert a ": Unit = " every time you used procedure syntax, or wrap every XML literal in xml"""...""".
The one thing that scares me a bit is experimental features. These will not port cleanly, and my advice right now would be: If you want your code to survive transitions without major rewrites, don't use experimental features. They might be tempting, but they can well be a trap down the line.
Shane Hastie on Distributed Agile Teams, Product Ownership and the Agile Manifesto Translation Program
Shane Hastie Apr 17, 2015