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