Hacker News new | past | comments | ask | show | jobs | submit login
Scala 2.12.0 is now available (scala-lang.org)
223 points by rilut on Nov 3, 2016 | hide | past | web | favorite | 75 comments



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.


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


Well I was against Oracle suing them with their copyright and patents and I still am, but Google did fragment the Java ecosystem and should be blamed for it. They just pulled an embrace, extend, then fuck it up.

I can understand why they wanted to bootstrap their stuff on top of Java, but now they are clearly not committed to keeping up. And with all of their resources, I just won't believe they can't do it.


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


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.


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" :)


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


Question: I'm about to start a hobby project on Android. I use Scala in my day job and strongly prefer it to Java. How would you rate its usability (coding, testing, debugging, performance) for Android development? Ideally I don't want to be fighting the tools, I just want to hack stuff in Scala and have it work on Android. If all else fails, I'll revert to Java 1.6, but I'd rather not.


I needed to write a very simple Android app a few months ago and decided to use Scala. This was my first and only experience with Android development, so that may have had something to do with it, but I wouldn't recommend using Scala for any serious project. It took me a ridiculous amount of time to get a functional dev environment, and I probably spent the first week fighting with the tools. I finally got IntelliJ IDEA set up to where I was mostly happy with it, but I never managed to reach that final 10% of functionality—for instance, I never got the IDE to auto-compile on save, which meant I had to keep an SBT session open and couldn't reliably use the IDE GUI for running the app. (Sometimes the two would compile at the same time and I'd get all sorts of weird errors that could only be fixed with a clean.)

Having said all of that, once I got everything working, I felt that using Scala was worth the pain. Programmatic layouts using scaloid gave me a vastly better experience than coding them in XML, and implicits worked really well for passing around the Context object. The tooling just wasn't, by any means, reliable, so I wouldn't recommend it for any apps your career depends on. :)

I haven't tried it, but I've heard that Kotlin is a nice compromise if you're looking for a language nicer than Java with more reliable tooling than Scala.


Thanks for the feedback!

It's unclear to me whether your pains were specific to Scala on Android or with Scala tooling in general. I'm already familiar with server-side Scala development using IDEA and I'm relatively comfortable with it, so that's not a problem. Is IDEA awful for Android development?


To be totally honest, I'm not sure either, as I had only minimal experience with Scala prior to that, so I don't know how much my anecdote is worth. :) I found IDEA fine for Android development, but I also didn't even try Android Studio, so I don't have anything to compare it to. That said, the little server-side Scala work I've done seemed to be a little more seamless than Scala with Android. It's been a while, so I don't remember the details, but I'm pretty sure little things like compile-on-save worked just fine in IDEA for normal Scala development, but didn't work at all (for me at least) with Android. You're also likely going to run into problems replacing Gradle with SBT (assuming that's the path you take), since Gradle is the official build tool and has all the mindshare; if you run into an Android-specific problem with SBT, you're most likely on your own, given that so few Android devs use Scala. IIRC, I had a few issues getting multidex to work because the Scala-on-Android guide I was following was out of date.

I would say that if you're already familiar with Scala and aren't afraid of getting into the weeds a little bit, you should be fine in the short-term. My personal fear is simply that, especially with Scala 2.12 dropping support for Java 6, Scala development on Android doesn't have a clear future, so as Google changes their build stack, you may find it increasingly harder over time to keep all the tools working.


I don't think the Scala-on-Android devs have any plans of giving up, they just took a wait-and-see approach until Google ships their new Jack/Jill stack: http://get-scala.org/2.12#scala-on-android

There is no sense of hurry as 2.11 won't go away and will have a long life.


Weird to blame current Scala versions for not supporting end of life versions.

You can still use Java 6 and Scala 2.11.

It's just that Java 6 will not receive any bug fixes or security updates, and Scala 2.11 will not either. But both will continue to work.

Seems very sane to me.


> Weird to blame current Scala versions for not supporting end of life versions.

I didn't.

> will not receive any bug fixes or security updates, and Scala 2.11 will not either

Oh, I'm pretty sure that Scala 2.11 will receive fixes, security updates and even backports of features for a very long time. For example SI-2712 is getting back-ported to Scala 2.11.9 and there's even talk of back-porting it to Scala 2.10.


The last announced plan was to conclude 2.11.x with 2.11.9 (currently at 2.11.8).

Maybe we'll see longer support for people who don't migrate (heck, SBT still uses 2.10.x), but justifying it by Java version is weird.

If you're okay with using old Java versions, it's not much of a stretch to say you'll be okay with old Scala versions.


> If you're okay with using old Java versions, it's not much of a stretch to say you'll be okay with old Scala versions.

No, because Scala doesn't offer forward binary or source compatibility. Maintainers of widely-used Java libraries can write and build for Java 6 and be confident their libraries will be usable by everyone (on Android and off). Maintainers of widely-used Scala libraries have no such option (for now they can write their code using the subset that works in Scala 2.11 and 2.12 and cross-build, but there's no guarantee that such a subset will be maintained in 2.13 and beyond).


> there's no guarantee that such a subset will be maintained

There's no guarantee about Java either. This class compiles with Java 7, but not with Java 8:

    class SampleClass {
        static class Baz<T> {
            public static java.util.List<Baz<Object>> sampleMethod(Baz<Object> param) {
                return null;
            }
        }
 
        private static void bar(Baz arg) {
            Baz element = Baz.sampleMethod(arg).get(0);
        }
    }
Like Java or any other good software, Scala will try to maintain backwards compatibility (particularly source compatibility).


> There's no guarantee about Java either. This class compiles with Java 7, but not with Java 8:

Ok, but you can compile it with the newer compiler by passing -source 1.7, right? And you can call into it from 1.8 code?


Yes, binary compatibility is maintained in this case.


Yep, 2.11.9 is the last planned release, but we would release another one for security fixes or anything as severe. If we get customer requests for backports, we (usually) also release those publicly.

Thanks for your support!


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

And GAE standard environment. :(


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.


> This language has bright future.

Yeah, it definitely looks good (to me). Dotty looks really promising to a layman like me especially since it's based on the machine-checked DOT calculus, so should have a better foundation than scalac. Then there are big projects like Spark, Akka, Play etc. But what I like the most about Scala at the moment is the continued effort regarding Scala.js, which seems to be one of the best compile-2-javascript projects. I like ur/web, and what comes the closest to it seems to be scala/scala.js.

I wonder if the collection redesign which is planned for scala 2.13 helps reduce the file size when compiling to js. Hello world is around ~40 kb (minified and gzipped) but goes to 100-150 kb for more involved things.


>continued effort regarding Scala.js

It's a shame the documentation is so poor for scalajs.


Could you elaborate on specific points that would require improvements? Most feedback I receive says it's good. If those of you who think it's poor only tell us "it's poor", there is nothing we can do to improve it.


I'm about to start using it again, but one point: the installation page[1] doesn't actually tell you how to install it...

[1] http://www.scala-js.org/doc/


Hum, that's because you don't actually need to install Scala.js per se. sbt will download and use it for your project automatically.

I agree that the way it is presented on that page is confusing, though. I'll add some explanation about that when I get back from conferences.

Thanks for the feedback!


For what it's worth, I've found the documentation to be quite good, and easy to follow. Thanks for all of your hard work.

Having said that, I agree it would be good to hear more from people who dislike the current documentation. Scala.js is a great project, and so it seems worthwhile to make any documentation changes that would make it accessible to as wide an audience as possible.


I haven't looked at scala.js, but as a new-ish scala user I thought the kick-off post in that mailing list drama from last month summarized my thoughts pretty well.


I won't argue about the documentation of Scala in general. But a post in the thread you are referring to was specifically mentioning Scala.js as not having the same issues.


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.


I think one of the best things about Dotty is that they now have a proven theory that the language works on top of (DOT calculus http://scala-lang.org/blog/2016/02/03/essence-of-scala.html). This has allowed them to remove some unsound things (and work around others in a sound way)


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.


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.


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... which points to a formal proof of my functional programming concepts illiteracy (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...


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


There's a pretty decent explanation in the release-notes: http://get-scala.org/2.12#partial-unification-of-type-constr...


Was about to post that link when I saw your edit.


I just learned these were on the table last night. It's like Christmas!


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?



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


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.


The https://www.scala-exercises.org/ is a good source (though it is just exercises so might not be the best first material)

Great thing about it is that you can do it in a browser without setting up anything (requires a github account)


If you just want to learn the language, read scala for the impatient, first half is free on Lightbend's website. If you want to learn fp, read functional programming in scala (Manning).


https://gist.github.com/djspiewak/cb72c41ac335a3a9b28b3307be... is a nice intro to the tooling/build setup.


If you already have some familiarity with functional programming but aren't extremely fluent in it, I recommend _Functional Programming in Scala_. It's one of the best functional programming books I've read.


one more resource that I found useful

https://www.youtube.com/user/DrMarkCLewis


This the answer you're looking for, trust me ;)

Once you get a grasp of the language and its extremely powerful features, pick up one of the standard books as a reference.



I'm reminded of "The State of Scala website and documentation" [0].

[0] https://groups.google.com/forum/#!topic/scala-internals/r2Gn...


If you're familiar with Haskell, you can probably dive into the "Typelevel Scala" approach. Once you learn how to do ADTs and typeclasses in Scala, you'll be able to make use of scalaz or cats effectively and feel relatively at home.


In addition to everything that's been recommended in this thread, Functional Programming in Scala is very nice. I read it after taking the Coursera course and working a bit on a Play project. Familiarity with Haskell and Ocaml will certainly help.


I've always been a Bruce Eckel fan. This book he wrote Atomic Scala [1] is easy to read and digest.

[1] http://www.atomicscala.com/


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

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


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


Yes, please. The font color is way too light.


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.


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.


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.



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


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


regarding jar size, from 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...


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


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.


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.


With scala async, you can also express this in direct style: https://github.com/scala/async.


There's Async Await. Which makes asynchronous code look like regular blocking code. But the calling code needs to know about it.

I recognise your concern: asynchronicity is infectious if it's manifested as monads. Which sucks. Client code needs to know whether the code it is calling is blocking or asynchronous.

Maybe effect systems can trace through code whether it is 'infected' with blockingness. Without any change showing in the intermediary source code. The blockingness/non-blockingness only manifesting itself at the top of the call graph.


You are literally describing monads.


Haskell. It's do-notation also makes it a very good imperative language.


Go. It's what I love most about it. If something needs to wait for a response, e.g., a database call, your goroutine just pauses without blocking any other goroutine, even if you're running only a single process. You never have to return a promise.

Contrast that with JavaScript where you're forced to use promises/async await. If you don't, you block the whole event loop.

See also "What Color is Your Function": http://journal.stuffwithstuff.com/2015/02/01/what-color-is-y...


I don't understand the claim that not using async / await and promises with js will block the event loop. Can you elaborate on what you mean?


I mean that, in an event loop, synchronous code is blocking code. If you could synchronously run a database query in Node, nothing else would be allowed to execute while you waited. That's why you have to use asynchronous callbacks/promises/generators/await whatever.

In Go I can make an apparently synchronous database query without blocking anything except the calling code.


looks like async/await (C#) is close to what you're looking for.




Registration is open for Startup School 2019. Classes start July 22nd.

Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact

Search: