

Scala 2.11.0 Release Notes - philippelh
http://scala-lang.org/news/2014/04/21/release-notes-2.11.0.html

======
some_pythonista
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)

~~~
eranation
This is a great course, love it and recommend any developer taking it.

Having that said, if all you want is to "switch from imperative language X to
Scala", (e.g. from Java) and you want to learn first how to do the "non
functional" stuff in Scala, then keep in mind that this course is teaching
functional programming first, Scala later. You can do (if you want) very
imperative and object oriented style of coding in Scala but this course is not
focusing on that part of the language (not because it's bad, but simply
because the course is about functional programming)

With that said, go and enroll, it's one of the best coursera courses I took.
Great videos, and very interesting programming assignments (many are
adaptations from SICP I later learned) and great forum discussions.

~~~
the_af
Of course you're right, but I actually thought the _strength_ of the course
was that it teaches you FP first, Scala later. Scala I'm still undecided
about, but I loved FP.

------
virtualwhys
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/))

~~~
ssmoot
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.

~~~
runT1ME
> 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]].

If you aren't familiar with Monad Transformers, yes, it can be tricky. However
it's trivial using an Option monad transformer (OptionT[Future,A]]) to have
the same semantics.

    
    
       for { 
          user        <-  OptionT(db.get(userId)
          mappedRoles =    user.roleIds.map(db.get(_))
          roles       <-  mappedRoles.sequence.liftM //goes to OptionT[Future,A]]
         } yield user.copy(roles = roles.flatten)
    

Look at [http://github.com/scalaz](http://github.com/scalaz) for already built
Monad Transformers (Either/State/Option/Writer) that will work with the
standard lib Future along with tons of other goodies. I actually actively
dislike the async stuff as it gives you another way of doing the same thing,
at a less powerful abstraction.

~~~
ssmoot
I've used ScalaZ a bit (don't remember exactly why, but something to do with
Future transformations), but I found it to crush the compiler. Especially
combined with IntelliJ.

I like the async/await stuff. Especially after attending the ScalaDays
presentation on it. The idea that it produces a state machine in the
background feels like it's very easy to reason about.

I actually (personally) find for-comprehensions the least useful feature of
Scala probably. They rarely produce the most readable code IME with just a
couple transformations in play, and it's not often I find myself dealing with
compatible types in the more complex cases.

So I guess I consider async/await the readable/prettier alternative to direct
mapping that for-comprehensions mostly fail to deliver on. for-comprehensions
are probably Scala's second biggest wart IMO (not harmful, more just mostly
useless). YMMV. Sort of like `__DATA__` or `=BEGIN/=END` in Ruby.

~~~
runT1ME
For comprehension is probably Scala's most powerful feature aside from higher
kinded types.

You may not see the advantage of for comprehension for sequencing a few
operations over Future. However, when you have a large number of calls you
have to sequence along with filter (which for comprehension can do) it's
indispensable.

Check this out: [https://www.youtube.com/watch?v=MHw-
dDxC8Z4](https://www.youtube.com/watch?v=MHw-dDxC8Z4)

~~~
ssmoot
Watching the video now. Thanks for the tip.

I'm curious why you'd call for-comprehensions powerful though. AFAIK they're
just sugar over map/flatten/filter.

IME it's almost always more succinct _and_ more readable to just call the
methods you want directly.

Plus, you can say: map over an Option and transform both cases. You could also
map then getOrElse, but readability suffers if your map is multi-line IMO. In
the for-comprehension version you can't transform the None case.

I use for-comprehensions with Extractors in testing, because whatever. It's a
test. So:

    
    
      for {
        Some(user) <- db.get[User](userId)
      } yield otherStuff
    

Is fine in that case.

Pattern Matching and Lifting are probably Scala's best features off the top of
my head. Type Classes a close third.

But for-comprehensions are just sugar. They don't enable you to do anything
you couldn't without them, and they actually make some flows impossible to
write. I find that you can usually tame a nested mess with partial functions
and a collect(). Or a fold() to handle your dual-transform.

That's just me though. Only been at the Scala job for a little over a year.

edit: @noelwelsh

I would nest yeah. But I'd see it more as a refactoring opportunity. Should
authorization be in a for-comprehension? I'd instead add an AuthorizedAction
in Play. That authenticated and provided a User from cache. So your example
would look more like:

    
    
      def show = AuthorizedAction.async { (user, permission) =>
        actions.user(Read(permission, user))
      }
    

I think I'd have to agree with another poster that doing all that inside of a
for-comprehension would look like a code-smell to me.

More than that, is map/flatten the right tool for the job for all this? Even
if I wanted to do it inline, I'd probably prefer:

    
    
      val perm = loginActions.mandatoryAuth(req)
      val queryString = req.mandatoryParam[String](uuidParam).toClientProblem
      
      (perm zip queryString) map {
        case (Some(perm), CachedUser(user)) => actions.user(Read(perm, user))
        case _ => BadRequest()
      }
    

It's definitely subjective. I wouldn't fault anyone for using the for-
comprehension (though I would encourage them to consider if it should rather
be an Action), but describing it as "powerful" just doesn't sit right with me
for some reason.

Plus while you'll see for-comprehensions in the wild on occasion, I think it's
a stretch to call them idiomatic. Unless you were going to constrain yourself
to projects with ScalaZ as a dependency I suppose.

~~~
noelwelsh
When you're doing functional programming you represent (almost) everything as
a value. Say you're working in a concurrent system, (e.g. a web app) so you're
dealing with Futures everywhere. Are you going to write 4 or 5 nested
flatMaps? It's unreadable. For comprehensions are much easier to parse. Here's
an example from real shipping code

    
    
              for {
                perm        <- loginActions.mandatoryAuth(req)
                queryString <- req.mandatoryParam[String](uuidParam).toClientProblem.fv
                user        <- stringToUser(cache.user, queryString).fv
                result      <- actions.user(Read(perm, user))
              } yield result
    

Then you get into nested monads (e.g. Either can represent a computation that
succeeds or fails, which you want to contain inside a Future) and you use
monad transformers to squish them into one single monad, to avoid nesting for
comprehensions.

------
ludicast
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
I would say Java 5 instead. Even as poorly as Generics were implemented, it
was a lot better than having nothing.

------
jf5s2
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.

------
film42
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.

~~~
neverminder
I wish the same was done for tuples, but it wasn't and it's unclear whether
that's even in plans.

~~~
joostdevries
Shouldn't that go hand in hand? The generated unapply method will involve a
tuple of same arity I believe.

~~~
neverminder
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
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
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.

~~~
frowaway001
They just don't emit all the boilerplate which would require unlimited-arity
Tuples/Functions/... for larger case classes.

------
netcraft
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?

~~~
MBlume
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.

------
jluxenberg
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-
safet...](http://docs.scala-lang.org/overviews/reflection/thread-safety.html))

~~~
eugene_burmako
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.

------
welshrats
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-f...](https://speakerdeck.com/heathermiller/spores-
distributable-functions-in-scala)

------
oelang
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
There have not been any huge library/language changes since 2.8.

~~~
adriaanm
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
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.

~~~
adriaanm
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.

~~~
virtualwhys
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
See also good discussion in ScalaWags #13

[http://www.scalawags.tv/](http://www.scalawags.tv/)

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

