
Scala 2.12.0 is now available - rilut
http://www.scala-lang.org/news/2.12.0
======
bad_user
This is the version of Scala that breaks compatibility with Java 6 in the
generated bytecode, by making use of Java 8's features, like invokedynamic,
default interface methods and integration with SAM types.

This is great because the generated bytecode is smaller and more resistant to
binary compatibility issues. Scala has had problems with binary compatibility
because its features don't map that well on top of the JVM and traits have
been very problematic, so thankfully now we have a more efficient encoding.
Having SAM support is also good for both Java devs wanting to use Scala
libraries and for Scala devs wanting to use Java libraries.

But this also means that Scala 2.11 should be a long-term support version,
because even though Java 6 and 7 have reached end of life, the world is not
ready to fully commit to Java 8, as sadly there are projects like Android that
are holding us back.

Scala 2.12 is a big achievement, with many changes under the hood. I'm happy
to finally see it released. Kudos to those involved.

~~~
pjmlp
> the world is not ready to fully commit to Java 8, as sadly there are
> projects like Android that are holding us back.

This is only going to get worse after Java 9 and 10 get released.

I imagine by the time we get Java 10, Google might be considering to
eventually cherry pick Java 9 features.

They just forked the whole eco-system, and lots of people blindly post links
to their Java 8 references, without looking into Android source code, where
they are just cherry picking Java 8 features, JVM bytecodes and libraries.

~~~
nine_k
This is why both Scala and Kotlin make a lot of sense for Android development.

~~~
pjmlp
True, but I think Kotlin has an edge here.

JetBrains, as Kotlin steward, takes an effort to have Kotlin work painlessly
within Android Studio.

The Scala support for Android apparently only works properly within InteliJ,
which means a few versions behind what Android Studio actually supports. It
also requires much more configuration steps.

~~~
the_af
Regardless of Kotlin (which I don't feel inclined to learn at this point),
would you say Scala is usable for Android development? I'm about to start a
personal project and would love to use Scala if possible. Note: by "usable" I
mean really usable, not "it works, but with lots of caveats and extreme pain"
:)

~~~
simono
In my experience it is.

The sbt-android plugin is really amazing. It makes compiling with ProGuard
enabled as fast as Gradle without ProGuard, due to the plugins integration of
incremental compilation with ProGuard.

Plus, there are quite a few built-in features and "add-on" plugins which
enhance the experience further (sbt-android-protify, sbt-android-gradle).

A bunch of people built an "official" website around Scala-on-Android
recently, scala-android.org. If you have any questions drop by in the Gitter
channel: [https://gitter.im/scala-android/sbt-
android](https://gitter.im/scala-android/sbt-android)

------
Philipp__
What grabbed my attention the most in terms of Scala is Dotty. New compiler
for Scala, who's main goal is simplification and reorganization of language.
You know it will be for real when even Martin is working on it! This language
has bright future.

Edit: grammar, sry.

~~~
denis1
Well Martin also worked on scalac, with all its warts & problems, so you can't
say that it will be better just because he's also working on it. :)

IMO much more important is the fact that Dotty is being developed after
several years and iterations of scalac. Ideally this would mean that the
problems to be solved, and the different ways to solve them are known. Dotty
can do this without having a large legacy inherited code base. To me this is
more important.

~~~
joostdevries
Have you heard any of his presentations on the new compiler architecture?

I'm incredibly impressed with the stewardship of Scala: they did a thorough
assessment of the strengths and weaknesses of language and compiler and are
working on a complete refoundation of the language semantics and a rewrite of
the compiler while also steadily progressing along a multi year roadmap for
the current compiler.

------
noelwelsh
The right-biased Either, and the partial unification support that it builds
on, are a much needed and much appreciated improvement. Really looking forward
to trying out this release.

~~~
eranation
Is there a good source to read about what is partial unification for the
uninitiated? Googling it lead me to this: [https://issues.scala-
lang.org/plugins/servlet/mobile#issue/S...](https://issues.scala-
lang.org/plugins/servlet/mobile#issue/SI-2712) which points to a formal proof
of my functional programming concepts illiteracy
([http://www.cs.cmu.edu/~fp/papers/lfp88.pdf](http://www.cs.cmu.edu/~fp/papers/lfp88.pdf)).
Couldn't understand a word and I use scala for work... Any chance there is an
easy explanation?

Edit: found something:
[https://gist.github.com/djspiewak/7a81a395c461fd3a09a6941d4c...](https://gist.github.com/djspiewak/7a81a395c461fd3a09a6941d4cd040f2)

~~~
denis1
This is a good explanation about what partial unification means in terms of
Scala. And also a pretty good explanation of what the supposed fix actually
does.

[https://gist.github.com/djspiewak/7a81a395c461fd3a09a6941d4c...](https://gist.github.com/djspiewak/7a81a395c461fd3a09a6941d4cd040f2)

------
ThePawnBreak
Does anyone have any tips for learning Scala? I want to learn the language, it
looks very interesting, and I have some familiarity with Scheme, Haskell and
Ocaml, but I just don't know how to start. What should I read? What should I
build?

~~~
mafribe
I have suggested Odersky's introductory MOOC [1] to many of my students and
they all thought it was great. It's heavily inspired by SICP, so it should be
easy, given your background.

[1]
[https://www.coursera.org/learn/progfun1](https://www.coursera.org/learn/progfun1)

~~~
wpietri
Yes, I second the recommendation for the course. And I can happily recommend
it for people who don't even plan to use Scala, but who just want to get a
feel for functional vs OO approaches. Odersky sees them as complimentary, and
in some sense Scala is his way of proving the point.

------
mirekrusin
Great stuff but can you please scale up font contrast a bit?

Just removing this `body { color: #586E75 }` altogether makes your page
readable.

~~~
gmartres
The maintainers might not see your comment, I encourage you to make a PR:
[https://github.com/scala/scala-lang](https://github.com/scala/scala-lang)

------
lacampbell
I desperately want to like Scala. An expressive, concise pure OO Lang with
static typing designed for a REPL is something I often wish existed. But every
time I've used it I've come away disappointed with the execution. A
bewildering standard library, a type system that crashes, glacial compilation,
and the sbt repl leaks memory every time you type a command.

I'll try it again, as I believe it's an excellent idea. Having objects so fine
grained allows it to emulate functional programming really well. But I suspect
I'll be disappointed again.

~~~
whateveracct
When was the last time you tried Scala? I just left a Scala/scalaz job after
around 2 years and everyone I worked with was extremely happy with the
language. We gradually moved to a more Haskell-like approach to programming,
which I feel Scala is more capable of than any other mature general-purpose
language (except Haskell ofc)

I'll address your issues one-by-one.

> A bewildering standard library

What about it troubled you? The main things I use in the stdlib are
collections (CanBuildFrom aside, they're pretty solid), Future (although I
prefer scalaz.concurrent.Task), and Option. In 2.12, Either is finally usable
too!

> a type system that crashes

I've only run into a single type checker crash (NPE) in my 2 years. Aside from
that, the type system has become my best friend. I write implicit-heavy code
that leans on scalaz and shapeless too.

> glacial compilation

A full compile of our ~250 file (idr loc) service took like 2 minutes. But I
pretty much never did full compiles. Sbt incremental compilation of a handful
of files would take a coupe seconds. This makes the feedback loop of running
tests/the repl pretty quick, and unlike with other fast-feedback-loop
languages (like Ruby), I get really strong checks from the compiler in each
loop.

> the sbt repl leaks memory every time you type a command.

Are you referring to the Scala repl (sbt console) or the sbt build tool
prompt? It's true that the repl leaks memory but that's by design: every repl
evaluation is stored in a variable (res0, res1, etc). I've run into memory
trouble once or twice when loading large production data into the repl, which
would store it in one of these variables. I worked around it by loading it but
then in a block extracting what I needed. This smaller data would in turn be
stored in resX.

~~~
lacampbell
My memory is fuzzy on all of the above, so this all just represents the
impression it left on me.

> When was the last time you tried Scala?

Around 2 years ago, as well. It showed so much promise but I ran into so many
problems using it day to day.

> What about it troubled you? The main things I use in the stdlib are
> collections (CanBuildFrom aside, they're pretty solid), Future (although I
> prefer scalaz.concurrent.Task), and Option. In 2.12, Either is finally
> usable too!

Unreadable type signatures, mainly. And the collection hierarchy was rather
bewildering.

> I've only run into a single type checker crash (NPE) in my 2 years.

I wasn't complaining about NPEs. IIRC Scalas type system is actually turing
complete. I ran into it trying to do fairly mundane things - it crashed when I
was writing a simple interepter I think.

> A full compile of our ~250 file (idr loc) service took like 2 minutes. But I
> pretty much never did full compiles. Sbt incremental compilation of a
> handful of files would take a coupe seconds. This makes the feedback loop of
> running tests/the repl pretty quick, and unlike with other fast-feedback-
> loop languages (like Ruby), I get really strong checks from the compiler in
> each loop.

True. SBT helps a lot by being incremental. It's absolutely glacial compared
to Java where you don't even notice it, but a slow incremental compile system
is still better than all but the fastest batch compilers. So I agree with you
there. Except...

> It's true that the repl leaks memory but that's by design: every repl
> evaluation is stored in a variable (res0, res1, etc). I've run into memory
> trouble once or twice when loading large production data into the repl,
> which would store it in one of these variables.

I realise that the memory usage of a running repl is bound to grow as you
enter in commands. But I've never seen something grow as rapidly as the sbt
console. I'd have to restart it every 3-4 times I'd reload the small file I
was working on, because I simply can't spare a GB of memory in order to run an
interpreter. I never had any issues with say ruby, even when ruby was much
slower, and my personal machine was abysmal (less than 1gb of ram).

Maybe it's not so much a memory leak as just very sloppy use of memory.

------
timothyklim
More details [http://get-scala.org/2.12](http://get-scala.org/2.12)

~~~
jinst8gmi
Where can I find more info on the performance work done on collections?

------
brianwawok
Does anyone have sample sizes on Jar file size reduction, or clean compile
time from the new backend? I haven't been deep in Scala for a few months, and
it sounds interesting that Java8 allowed some improvements on the back end...

~~~
redtuesday
regarding jar size, from [http://get-scala.org/2.12](http://get-
scala.org/2.12) (mentioned in this thread already):

    
    
     	                2.9 	2.10 	2.11 	2.12
      Scala library 	9.0 	7.1 	5.7 	5.5
      Scala compiler 	11.5 	14.5 	15.5 	10.1
      ScalaTest (3.0.0) 	        10.5 	10.4 	7.0
    

data is in Megabyte. Compilation would be interesting, since I have read
multiple times that it is slower due to a jvm bug. Only a few days ago for
example:
[https://www.reddit.com/r/programming/comments/5ab948/scala_2...](https://www.reddit.com/r/programming/comments/5ab948/scala_212_release_notes/d9f5vsu/)

~~~
merb
> since I have read multiple times that it is slower due to a jvm bug

extremly depending on your use case (p.s. it's not only compile time slower,
but -Xminin-forwarders made it way better, but of course bigger jar files),
the jar size, too.

------
amelius
Offtopic. Does anybody know of a practical imperative language in which
promises are implicit? Often, when writing software, it happens that deeply
nested functions suddenly have to return a promise instead of a direct value,
and this forces the programmer to rewrite all the callers of that function
into dealing with promises, which of course sucks. So it would be better if
the programming language would do that rewriting instead (under the hood), so
to speak.

~~~
runT1ME
This is what monadic syntax is for. You can do the following for any Future in
scala:

    
    
        for {
           resa <- asyncCall(1)
           resb <- asyncCall(2)
           resc <- asyncCall(3)
        } yield new Obj(resa, resb, resc)
    

which just gets rewritten to

    
    
        asyncCall(1).flatMap(resa => asyncCall(2).flaMap(resb =>
               asyncCall(3).map(resc => new Obj(resa, resb, resc))))
    

This doesn't just work for futures, it works for any monad. This is super
amazingly useful. Also, query syntax for LINQ in C#/F# can support this too.

~~~
adriaanm
With scala async, you can also express this in direct style:
[https://github.com/scala/async](https://github.com/scala/async).

