Scala 2.12.0 is now available
scala-lang.org
scala-lang.org
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.
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.
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.
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 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
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.
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?
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.
There is no sense of hurry as 2.11 won't go away and will have a long life.
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.
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.
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.
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 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);
}
}
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?
Thanks for your support!
And GAE standard environment. :(
Edit: grammar, sry.
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.
It's a shame the documentation is so poor for scalajs.
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!
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.
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'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.
Edit: found something: https://gist.github.com/djspiewak/7a81a395c461fd3a09a6941d4c...
https://gist.github.com/djspiewak/7a81a395c461fd3a09a6941d4c...
Effective Scala: http://twitter.github.com/effectivescala/
Advanced Functional Programming with Scala - Notes: https://gist.github.com/jdegoes/97459c0045f373f4eaf126998d8f...
Great thing about it is that you can do it in a browser without setting up anything (requires a github account)
Once you get a grasp of the language and its extremely powerful features, pick up one of the standard books as a reference.
[0] https://groups.google.com/forum/#!topic/scala-internals/r2Gn...
Just removing this `body { color: #586E75 }` altogether makes your page readable.
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.
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.
> 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.
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
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.
for {
resa <- asyncCall(1)
resb <- asyncCall(2)
resc <- asyncCall(3)
} yield new Obj(resa, resb, resc)
asyncCall(1).flatMap(resa => asyncCall(2).flaMap(resb =>
asyncCall(3).map(resc => new Obj(resa, resb, resc))))
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.
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...
In Go I can make an apparently synchronous database query without blocking anything except the calling code.