9 ms·

Scala 2.11.0 Release Notes

140 points by philippelh 12y ago

oelang 12y ago
Is this the first mayor scala release that doesn't introduce a huge language or library change? Transitioning to 2.11 should be smooth, aside from some library deprecations not much has changed.
- frowaway001 12y ago
  There have not been any huge library/language changes since 2.8.
  - adriaanm 12y ago
    To be fair, 2.10 introduced quite a few new features (my favorite being string interpolation). To name some more: implicit classes, value classes, language imports, reflection & macros,... 2.11 set the tone for the remainder of the 2.x cycle: smaller, faster, stabler. 2.12 will focus on Java 8 support and making it (even) easier to learn and use Scala. We're also working on making the compiler a better platform for others to innovate on -- originally via compiler plugins, now using reflection & macros. A lot of cool stuff is happening outside core Scala, such as scala.js, and we hope to spur on that trend. (I'm the Scala Tech Lead at Typesafe.)
    - soq_4 12y ago
      I really hope that you guys aren't planning to pull a Python 3 with the 3.x series. We're using Scala quite heavily in our production systems and the naysayers will have a great "I told you so" moment of we end up sitting on a ton of critical Scala code which no longer compiles in a future version.
      - tormeh 12y ago
        I kind of hope the Scala guys do that, actually. There is too many ways to do certain things. "list.map(_+2)" is legal while "list.map((_+2)+3)" is not. Instead, you need to use an anonymous function like this: "list.map(x => (x+2)+3)". Why is the _-style even legal if it's so inflexible? Why not force functions all the time? Why have two ways to do the same simple thing?
        lmm 12y ago
        The _ style is legal because it's really useful. Most of the time you're mapping with small functions, and the extra few characters really add up - more than enough to be worth the extra learning.
        tormeh 12y ago
        It would also be nice if "<-" were replaced with "in". It would just be more helpful and easier to remember. Special signs should be avoided at every opportunity
      - adriaanm 12y ago
        We've been thinking about this a lot, even though Scala 3 is a couple of years out. Our current thinking is to bring the 2.x series as close to 3.0 as possible, with the remaining breaking changes being compelling enough to switch. Please share your ideas/concerns over at scala-internals! Part of the solution will be tooling, and the team at EPFL has started prototyping a migration tool that generates patches to turn a well-typed Scala 2 program into the equivalent one on Scala 3. I believe our type system and the fact that we're a compiled language will make a big difference compared to Python.
        platz 12y ago
        Is Scala 3 going to bring in the knowledge from dotty to simplify some of the n x n typing combinations?
        virtualwhys 12y ago
        Wow, this is the first time I've heard that Scala 3 is actually in the works (vs. Dotty as research that may incrementally find its way into Scala 2). Naturally, tradeoffs will be made, are you guys at a point yet where you can reveal what we're going to _lose_ in terms of functionality and flexability? I know the core Scalaz developers had a bit of an uproar on Twitter when Dotty was first revealed (due to the simplified/less powerful type system in Dotty that may make some scalaz magic very difficult to pull off). Otherwise, improved tooling, build times, Scala 2 sans les warts, etc. will be a boon for the language. So, Scala 3.0-M1 in 2016? Give us the inside word ;-)
        caoilte 12y ago
        See also good discussion in ScalaWags #13 http://www.scalawags.tv/ http://www.scalawags.tv/
    - sixbrx 12y ago
      Glad to hear faster is a priority. Hopefully faster for loops will make it in.
ludicast 12y ago
For me the most exciting part is that they are bringing in support for Java 8. Though lambdas don't impress anyone already using a functional language on the JVM, the introduction of Nashorn and the merger of JodaTime are pretty awesome. Java 8 is the most exciting release since Java 2 in my opinion.
- ebiester 12y ago
  I would say Java 5 instead. Even as poorly as Generics were implemented, it was a lot better than having nothing.
film42 12y ago
Probably the best change in my opinion was resolving the arity limit for case classes: https://issues.scala-lang.org/browse/SI-7296 https://issues.scala-lang.org/browse/SI-7296 I've bumped up against that limit pretty bad while trying to deserialize json. Shapeless did a lot to solve the problem, but I'm sure glad that limit has been removed.
- deleted 12y ago
  [deleted]
- neverminder 12y ago
  I wish the same was done for tuples, but it wasn't and it's unclear whether that's even in plans.
  - joostdevries 12y ago
    Shouldn't that go hand in hand? The generated unapply method will involve a tuple of same arity I believe.
    - neverminder 12y ago
      As the matter of fact I'm not sure now. I was looking for a confirmation that tuple limit is removed in Scala 2.11, but couldn't find it whereas statements that case class 22 parameter limit is removed are all over the place.
      - gourlaysama 12y ago
        AbstractFunction, Function, Product and Tuple are all still limited to 22. Increasing the limit would create too much bytecode, and in the current design, lifting the limit is just impossible (without runtime code generation or custom classloader, etc.).
        film42 12y ago
        So why did they choose to allow case classes to have arbitrary arity? Not that I'm complaining, I just don't understand the underworking of scala that well.
virtualwhys 12y ago
Compared to 2.10 the 2.11 release is nothing special: some optimizations, bunch of bug fixes and deprecations (that hopefully lead to slash and burn of little used language features in 2.12). Curious to test out build times in 2.11, sounds like some minor gains have been made there, and more to come in the 2.11 release cycle as the new scalac optimiser is integrated (http://magarciaepfl.github.io/scala/ http://magarciaepfl.github.io/scala/)
- ebiester 12y ago
  That's really exciting to me. (So is slash and burn, though.) Give me another two years of compiler improvements, bug fixes, and IDE/tooling improvements!
  - virtualwhys 12y ago
    I'm actually in a really good place IDE-wise, have a stripped down Eclipse (Platform + RCP build) with 2 Scala plugins, Scala IDE and Scala Worksheets. SBT does the heavy lifting (have automatic build turned off in Eclipse) while Eclipse provides the dev environment. Really snappy, zero spurious errors, it's like night and day compared to 3 years ago, woo hoo ;-)
- deleted 12y ago
  [deleted]
- ssmoot 12y ago
  async/await and removal of the case-class/tuple 22 field limit are the big ones I think. (edit: the limit is still in effect for Tuple apparently. Only removed for case-classes.) In database (or Actor ask) heavy code dealing with a lot of Futures async/await has the potential to fairly significantly influence code style. for-comprehensions often don't cut it when you're dealing with a Future[Option[User]] and need to pull in their assigned roles from a Future[Seq[Role]]. val userOption = db.get(userId) flatMap { case None => Future.successful(None) case Some(user) => Future.sequence { user.roleIds map(db.get(_)) } map { roles => Some(user.copy(roles = roles.flatten)) } } vs: val userOption = async { for { user <- await(db.get(userId)) roles = await(Future.sequence(user.roleIds map(db.get(_)))) } yield user.copy(roles = roles.flatten) } Or something like that anyways.
some_pythonista 12y ago
Relevant: "Functional Programming Principles in Scala" starts in 4 days on coursera, which was created by the author of scala. https://www.coursera.org/course/progfun https://www.coursera.org/course/progfun
- terhechte 12y ago
  I concur, this is a really good course. I've since switched to Clojure but I still think that I gained a lot from working through this course. It is a really great introduction into functional programming paradigms, and well worth it even if you don't plan to continue using Scala.
  - some_pythonista 12y ago
    Have you seen the follow up course "Principles of Reactive Programming" too? It's also by Martin Odersky, but also with Erik Meijer and Roland Kuhn. https://www.coursera.org/course/reactive https://www.coursera.org/course/reactive
    - acjohnson55 12y ago
      I took both classes, but I really didn't care for Reactive as much. The first Coursera class really turned me on to the elegance of functional programming with Scala's unique type system, but much of that elegance is really lost dealing with some of the structures introduced in the second class, in my opinion. Reactive is split into three "subclasses". The beginning part, taught again by Odersky, was a pretty useful extension of what was taught in the first class. As with the first class, the lectures were very well thought out. Although, some of the examples abandon the beauty of side-effect free programming, which was a letdown after really being turned on to that style in the first course. The middle section on Futures and ScalaRx was pretty rough. Those lectures, done by Erik Meijer (I believe), were less clear and less well planned. I don't know if there's an impedance mismatch between Scala and the reactive style or if ScalaRx is just the wrong abstraction, but the joy of Scala was completely lost for me in these two lectures. I'm used to Javascript's Promises/Deferreds, which are essentially the same thing as Scala's Futures/Promises, but the former are far more intuitive syntactically. I did, however, find the final three lectures on Akka to be very well taught. I had no experience on actor model programming, but I came away very intrigued by the possibilities. A complaint that spans all three sections was that the assignments could be better focused on the the concepts at hand. Each can require a fair bit of constructing your own test and debugging frameworks to figure out how to pass the rather opaque and unhelpful automatic grading system. I eventually lost patience and quit doing the assignments after floundering with the tools.
netcraft 12y ago
I want to be writing scala so bad, but there doesn't seem to be any jobs in my area. Are there any scala specific job boards out there?
- craigwblake 12y ago
  I haven't seen any job boards specific to Scala, but there do seem to be more jobs popping up looking for Scala experience. You could also work at evangelizing Scala in your current (presumably) Java shop. I've found success with this approach by getting other developers interested in the language and mentoring them, especially during the steeper parts of the learning curve. If you can pique the interest of a good portion of the development team it's often not too difficult to get a new language introduced through smaller non-critical or non-production systems, which is a good foothold with which to get the benefits visible to the wider group. YMMV of course.
- mriou 12y ago
  Not sure how well-maintained it is but: http://www.scalajobz.com/ http://www.scalajobz.com/
- neverminder 12y ago
  This is a tough one. I've started working with Scala full time by convincing my boss that this is the way to go. Let's just say without going into too much detail that I've proved my point, because our original stack now looks just miserable in comparison. From what I can see (at least in UK) Scala jobs are more of the high end ones and usually has to do with finances and/or "big data", which is why there aren't many of them. Also, I think Scala if not for everyone which is why it's usually used by someone who's more or less a seasoned professional mastered more than one language.
- MBlume 12y ago
  Go to meetups. This is fully general advice if you wish you had a job programming $LANGUAGE or $FRAMEWORK or whatever. Go to meetups for the job you want, not the job you have.
- eldavido 12y ago
welshrats 12y ago
Pickling and Spores didn't make it? Or do those type of additions not get mentioned through this channel? https://speakerdeck.com/heathermiller/spores-distributable-functions-in-scala https://speakerdeck.com/heathermiller/spores-distributable-f...
jluxenberg 12y ago
Buried in the release notes is this gem: reflection via ClassTags wasn't (and still isn't) threadsafe in 2.10; this has been fixed in 2.11 (see http://docs.scala-lang.org/overviews/reflection/thread-safety.html http://docs.scala-lang.org/overviews/reflection/thread-safet...)
- eugene_burmako 12y ago
  ClassTags were always thread-safe - they are simple wrappers over j.l.Class. TypeTags however were not, and that's supposed to be fixed in 2.11.0.
- lmm 12y ago
  Great to hear that's been fixed - I saw an issue that was a manifestation of this, and in particular it made akka's experimental typed actors entirely unusable for my case.
jf5s2 12y ago
There's a very detailed presentation on Scala 2.11 features and improvements here: https://www.youtube.com/watch?v=ByDPifJMSvQ https://www.youtube.com/watch?v=ByDPifJMSvQ There's quite lot of discussion around the compiler performance improvements.
adivish 12y ago
backend optimizer, GenBCode, has extensive documentation. Exciting!(http://magarciaepfl.github.io/scala/ http://magarciaepfl.github.io/scala/)
greatsuccess 12y ago
Scala is a code smell

140 points by philippelh 12y ago

Is this the first mayor scala release that doesn't introduce a huge language or library change? Transitioning to 2.11 should be smooth, aside from some library deprecations not much has changed.

frowaway001 12y ago
There have not been any huge library/language changes since 2.8.
- adriaanm 12y ago
  To be fair, 2.10 introduced quite a few new features (my favorite being string interpolation). To name some more: implicit classes, value classes, language imports, reflection & macros,... 2.11 set the tone for the remainder of the 2.x cycle: smaller, faster, stabler. 2.12 will focus on Java 8 support and making it (even) easier to learn and use Scala. We're also working on making the compiler a better platform for others to innovate on -- originally via compiler plugins, now using reflection & macros. A lot of cool stuff is happening outside core Scala, such as scala.js, and we hope to spur on that trend. (I'm the Scala Tech Lead at Typesafe.)
  - soq_4 12y ago
    I really hope that you guys aren't planning to pull a Python 3 with the 3.x series. We're using Scala quite heavily in our production systems and the naysayers will have a great "I told you so" moment of we end up sitting on a ton of critical Scala code which no longer compiles in a future version.
    - tormeh 12y ago
      I kind of hope the Scala guys do that, actually. There is too many ways to do certain things. "list.map(_+2)" is legal while "list.map((_+2)+3)" is not. Instead, you need to use an anonymous function like this: "list.map(x => (x+2)+3)". Why is the _-style even legal if it's so inflexible? Why not force functions all the time? Why have two ways to do the same simple thing?
      - lmm 12y ago
        The _ style is legal because it's really useful. Most of the time you're mapping with small functions, and the extra few characters really add up - more than enough to be worth the extra learning.
      - tormeh 12y ago
        It would also be nice if "<-" were replaced with "in". It would just be more helpful and easier to remember. Special signs should be avoided at every opportunity
    - adriaanm 12y ago
      We've been thinking about this a lot, even though Scala 3 is a couple of years out. Our current thinking is to bring the 2.x series as close to 3.0 as possible, with the remaining breaking changes being compelling enough to switch. Please share your ideas/concerns over at scala-internals! Part of the solution will be tooling, and the team at EPFL has started prototyping a migration tool that generates patches to turn a well-typed Scala 2 program into the equivalent one on Scala 3. I believe our type system and the fact that we're a compiled language will make a big difference compared to Python.
      - platz 12y ago
        Is Scala 3 going to bring in the knowledge from dotty to simplify some of the n x n typing combinations?
      - virtualwhys 12y ago
        Wow, this is the first time I've heard that Scala 3 is actually in the works (vs. Dotty as research that may incrementally find its way into Scala 2). Naturally, tradeoffs will be made, are you guys at a point yet where you can reveal what we're going to _lose_ in terms of functionality and flexability? I know the core Scalaz developers had a bit of an uproar on Twitter when Dotty was first revealed (due to the simplified/less powerful type system in Dotty that may make some scalaz magic very difficult to pull off). Otherwise, improved tooling, build times, Scala 2 sans les warts, etc. will be a boon for the language. So, Scala 3.0-M1 in 2016? Give us the inside word ;-)
        caoilte 12y ago
        See also good discussion in ScalaWags #13 http://www.scalawags.tv/ http://www.scalawags.tv/
  - sixbrx 12y ago
    Glad to hear faster is a priority. Hopefully faster for loops will make it in.

ludicast 12y ago

For me the most exciting part is that they are bringing in support for Java 8. Though lambdas don't impress anyone already using a functional language on the JVM, the introduction of Nashorn and the merger of JodaTime are pretty awesome. Java 8 is the most exciting release since Java 2 in my opinion.

ebiester 12y ago
I would say Java 5 instead. Even as poorly as Generics were implemented, it was a lot better than having nothing.

film42 12y ago

Probably the best change in my opinion was resolving the arity limit for case classes: https://issues.scala-lang.org/browse/SI-7296 https://issues.scala-lang.org/browse/SI-7296 I've bumped up against that limit pretty bad while trying to deserialize json. Shapeless did a lot to solve the problem, but I'm sure glad that limit has been removed.

deleted 12y ago
[deleted]
neverminder 12y ago
I wish the same was done for tuples, but it wasn't and it's unclear whether that's even in plans.
- joostdevries 12y ago
  Shouldn't that go hand in hand? The generated unapply method will involve a tuple of same arity I believe.
  - neverminder 12y ago
    As the matter of fact I'm not sure now. I was looking for a confirmation that tuple limit is removed in Scala 2.11, but couldn't find it whereas statements that case class 22 parameter limit is removed are all over the place.
    - gourlaysama 12y ago
      AbstractFunction, Function, Product and Tuple are all still limited to 22. Increasing the limit would create too much bytecode, and in the current design, lifting the limit is just impossible (without runtime code generation or custom classloader, etc.).
      - film42 12y ago
        So why did they choose to allow case classes to have arbitrary arity? Not that I'm complaining, I just don't understand the underworking of scala that well.

virtualwhys 12y ago

Compared to 2.10 the 2.11 release is nothing special: some optimizations, bunch of bug fixes and deprecations (that hopefully lead to slash and burn of little used language features in 2.12). Curious to test out build times in 2.11, sounds like some minor gains have been made there, and more to come in the 2.11 release cycle as the new scalac optimiser is integrated (http://magarciaepfl.github.io/scala/ http://magarciaepfl.github.io/scala/)

ebiester 12y ago
That's really exciting to me. (So is slash and burn, though.) Give me another two years of compiler improvements, bug fixes, and IDE/tooling improvements!
- virtualwhys 12y ago
  I'm actually in a really good place IDE-wise, have a stripped down Eclipse (Platform + RCP build) with 2 Scala plugins, Scala IDE and Scala Worksheets. SBT does the heavy lifting (have automatic build turned off in Eclipse) while Eclipse provides the dev environment. Really snappy, zero spurious errors, it's like night and day compared to 3 years ago, woo hoo ;-)
deleted 12y ago
[deleted]
ssmoot 12y ago
async/await and removal of the case-class/tuple 22 field limit are the big ones I think. (edit: the limit is still in effect for Tuple apparently. Only removed for case-classes.) In database (or Actor ask) heavy code dealing with a lot of Futures async/await has the potential to fairly significantly influence code style. for-comprehensions often don't cut it when you're dealing with a Future[Option[User]] and need to pull in their assigned roles from a Future[Seq[Role]]. val userOption = db.get(userId) flatMap { case None => Future.successful(None) case Some(user) => Future.sequence { user.roleIds map(db.get(_)) } map { roles => Some(user.copy(roles = roles.flatten)) } } vs: val userOption = async { for { user <- await(db.get(userId)) roles = await(Future.sequence(user.roleIds map(db.get(_)))) } yield user.copy(roles = roles.flatten) } Or something like that anyways.

some_pythonista 12y ago

Relevant: "Functional Programming Principles in Scala" starts in 4 days on coursera, which was created by the author of scala. https://www.coursera.org/course/progfun https://www.coursera.org/course/progfun

terhechte 12y ago
I concur, this is a really good course. I've since switched to Clojure but I still think that I gained a lot from working through this course. It is a really great introduction into functional programming paradigms, and well worth it even if you don't plan to continue using Scala.
- some_pythonista 12y ago
  Have you seen the follow up course "Principles of Reactive Programming" too? It's also by Martin Odersky, but also with Erik Meijer and Roland Kuhn. https://www.coursera.org/course/reactive https://www.coursera.org/course/reactive
  - acjohnson55 12y ago
    I took both classes, but I really didn't care for Reactive as much. The first Coursera class really turned me on to the elegance of functional programming with Scala's unique type system, but much of that elegance is really lost dealing with some of the structures introduced in the second class, in my opinion. Reactive is split into three "subclasses". The beginning part, taught again by Odersky, was a pretty useful extension of what was taught in the first class. As with the first class, the lectures were very well thought out. Although, some of the examples abandon the beauty of side-effect free programming, which was a letdown after really being turned on to that style in the first course. The middle section on Futures and ScalaRx was pretty rough. Those lectures, done by Erik Meijer (I believe), were less clear and less well planned. I don't know if there's an impedance mismatch between Scala and the reactive style or if ScalaRx is just the wrong abstraction, but the joy of Scala was completely lost for me in these two lectures. I'm used to Javascript's Promises/Deferreds, which are essentially the same thing as Scala's Futures/Promises, but the former are far more intuitive syntactically. I did, however, find the final three lectures on Akka to be very well taught. I had no experience on actor model programming, but I came away very intrigued by the possibilities. A complaint that spans all three sections was that the assignments could be better focused on the the concepts at hand. Each can require a fair bit of constructing your own test and debugging frameworks to figure out how to pass the rather opaque and unhelpful automatic grading system. I eventually lost patience and quit doing the assignments after floundering with the tools.

netcraft 12y ago

I want to be writing scala so bad, but there doesn't seem to be any jobs in my area. Are there any scala specific job boards out there?

craigwblake 12y ago
I haven't seen any job boards specific to Scala, but there do seem to be more jobs popping up looking for Scala experience. You could also work at evangelizing Scala in your current (presumably) Java shop. I've found success with this approach by getting other developers interested in the language and mentoring them, especially during the steeper parts of the learning curve. If you can pique the interest of a good portion of the development team it's often not too difficult to get a new language introduced through smaller non-critical or non-production systems, which is a good foothold with which to get the benefits visible to the wider group. YMMV of course.
mriou 12y ago
Not sure how well-maintained it is but: http://www.scalajobz.com/ http://www.scalajobz.com/
neverminder 12y ago
This is a tough one. I've started working with Scala full time by convincing my boss that this is the way to go. Let's just say without going into too much detail that I've proved my point, because our original stack now looks just miserable in comparison. From what I can see (at least in UK) Scala jobs are more of the high end ones and usually has to do with finances and/or "big data", which is why there aren't many of them. Also, I think Scala if not for everyone which is why it's usually used by someone who's more or less a seasoned professional mastered more than one language.
MBlume 12y ago
Go to meetups. This is fully general advice if you wish you had a job programming $LANGUAGE or $FRAMEWORK or whatever. Go to meetups for the job you want, not the job you have.
eldavido 12y ago

welshrats 12y ago

Pickling and Spores didn't make it? Or do those type of additions not get mentioned through this channel? https://speakerdeck.com/heathermiller/spores-distributable-functions-in-scala https://speakerdeck.com/heathermiller/spores-distributable-f...

jluxenberg 12y ago

Buried in the release notes is this gem: reflection via ClassTags wasn't (and still isn't) threadsafe in 2.10; this has been fixed in 2.11 (see http://docs.scala-lang.org/overviews/reflection/thread-safety.html http://docs.scala-lang.org/overviews/reflection/thread-safet...)

eugene_burmako 12y ago
ClassTags were always thread-safe - they are simple wrappers over j.l.Class. TypeTags however were not, and that's supposed to be fixed in 2.11.0.
lmm 12y ago
Great to hear that's been fixed - I saw an issue that was a manifestation of this, and in particular it made akka's experimental typed actors entirely unusable for my case.

jf5s2 12y ago

There's a very detailed presentation on Scala 2.11 features and improvements here: https://www.youtube.com/watch?v=ByDPifJMSvQ https://www.youtube.com/watch?v=ByDPifJMSvQ There's quite lot of discussion around the compiler performance improvements.

adivish 12y ago

backend optimizer, GenBCode, has extensive documentation. Exciting!(http://magarciaepfl.github.io/scala/ http://magarciaepfl.github.io/scala/)

greatsuccess 12y ago

Scala is a code smell