Scala 2.12 Roadmap (opens in new tab)

Having recently worked with a project employing Java 8, I whole-heartedly agree. The FP in Java 8 is so crippled as to be useless. Every time you use a lambda, you need to worry about checked exceptions and wrapping and unwrapping them. Also there is no Unit type, so you have to add `return null` everywhere.

Moreover, the Java collection library is now a hodge-podge of ancient cruft haphazardly mixed with a half-hearted FP interface. Java seriously needs to drop pre 1.5 compatibility, and revamp the whole API.

I'm just starting with Scala and I find the IntelliJ Scala plugin immensely non-intuitive (and I'm a big JetBrains fan normally).

Why do I have three different, apparently non-equivalent ways to create a new project (Java->Scala, SBT, Scala Module)?

The tooling and documentation seems to assume familiarity with the Java ecosystem. I'm not a Java developer (nor do I want to be), I'm a Python guy. Am I really expected to learn Java first just so I can learn Scala?

Making scalac aggressively incremental was a problem solved long ago. I'm presenting a paper about the continuation of that work at this year's onward.

Hi, thanks for taking the time to reply. My personal opinion of SBT is one that represent almost every developer I've discussed it with. Jumping to the bottom line - an experience like: rubygems, npm, lein (clojure), and that kind of build and package family is much preferred - one example is Buildr.

It's hard to pinpoint a developer 'instinct', but I think a build/dependency tool like rubygems or npm is one of the first things a developer bumps into, and becomes a central part of the experience _very early_, even before the experience of the language. With that in mind, SBT present a cryptic (some times even non-scala) like feel to it.

As a former Ruby developer: Please for the love of all that is holy do not make SBT more "Ruby-ish". Rubygems, Bundler, RVM and friends don't do anything SBT doesn't already do. And SBT does it with less set up and ceremony, fewer tools, more reliability, and less DSL "magic".

Rake is a cancer. SBT Tasks are far from straightforward, but they're certainly no more complex once you start throwing in dependencies. Tasks could use some work. But dependencies, project definitions, build settings, cross compilation, all light years ahead of anything in Ruby-land.

Tooling yes that is needed and welcome, but for many software engineers, IDEs are the least exciting part of a language ecosystem. Plenty programmers, and that too very capable programmers manage just fine with an editor. Speaking strictly for myself I couldnt care less for an IDE, it is irrelevant for me, especially in the context of a language that is syntactically lot more terse than Java. I would rather have the Scala team focus on more pressing problems, code optimizers, compile times, run times, other backends (LLVM?, GCC?), more airtight abstractions around the JVM. These are damned hard problems and Scala has been making steady progress, so this is the part that I find exciting and promising. Then again many are incapable of programming without an IDE and throwing in an IDE often does not drastically improve the quality of their code either.

Scala 2.11 went through a major refactoring of the compiler, it saw significant improvements in both total compilation time and incremental compilation and further improvements are planned in follow-up versions: http://www.scala-lang.org/news/2.11.0

I'm going to opine that I think IDE support can (and probably eventually will) be a lot better. I don't think Scala support in IntelliJ or Eclipse is where Java support was in Eclipse 10 years ago. When I first used Eclipse with Java, it was like the IDE new the entire language it was masterful at providing me all the docs and refactorings I might want. Granted, Java then had a much bigger audience than Scala now, and Scala's a much bigger language for and IDE to fully understand. But I'm finding IntelliJ improves visibly on pretty much a biweekly basis.

SBT to me is damn near disastrous, though. It's like they created this obtuse DSL for describing transformations to the immutable project settings, when they could have just used mutable features Scala already has, and obviated the need to learn a gnarly layer on top, with its weird rules and quasi-Scala syntax. The other thing that annoys the hell out of me is how difficult it is understand what keys exists in what scopes, what order tasks run in, and all the arbitrary translations between identifiers in the SBT shell versus the files themselves.

I read the entire 40+ page Getting Started guide, and I still find it incredibly frustrating when I need to do nontrivial modifications to my build process. I really hope SBT is up for a complete overhaul. I don't think it is though, because I think it provides people who invest the time to learn all the magic incantations that warm fuzzy feeling of superiority, because only they can peer through the layers of inscrutable DSL-syntax and see the elegance far beneath.

...Now that I've got that out of my system, I agree that Scala is on the rise, and we'll see these aspects improve as more people start to realize just how powerful the language is building large systems -- the horizontal and vertical scaling benefits Odersky always talks about.

I wouldn't describe writing a build script for Gradle as "using" Groovy. Most Gradle build files out there seem to be fairly short, usually 20 to 100 lines long, and consist of nothing more than the standard DSL calls. The template was probably copied from some other project, and the blanks filled in. I've yet to see a Gradle build script that actually drops out of the DSL to use Groovy to do any programming. The build script "authors" would have no idea how to use any of the more advanced Gradle API calls or Groovy language features beyond collection literals and closures. Gradle even still ships with the ancient Groovy version 1.8.

> Scala [...] only [used] by startups That is not what we are seeing...

> Scala and others only by startups.

I wouldn't describe various investment banks, twitter and amazon as "startups".

With 2.11 I have noticed the same speed up so thank you for all the current optimizations that have been happening.

I agree that for code changes, incremental compilation is usually reasonably painless. Compile times really kill me when I have to do a lot of clean builds, like when modifying my build scripts.

One of the things I was hoping for in improved scala tooling was better IDE agnostic solutions for developers.

For instance, I much prefer to use vim than an IDE, but due to the near requirement to have syntax checking in the editor to avoid long compile cycles I always end up giving up and using an IDE. That a common response to slow tooling complaints is that an IDE hides these issues is an indictment of the scala tool chain.

> A clean build for my project takes more than 30 seconds.

Well a C++ clean build would probably take a few hours. I know the projects I worked on did.

The changes as seen from the outside will be much more conservative than that. We're not ready to comment on specifics yet, but the main focus is to remove warts (deprecating them in 2.12/2.13 first where possible), make the type system and (thus) type inference more regular, and make safari^W scalac snappier.

The compiler internals and language concepts are being simplified substantially (we've learned a lot of interesting lessons in compiler engineering in the last decade, some of which require bigger changes).

They were pretty clear on the Android Google IO fireside talk that Java is Android's official language.

However they refrained to make any comment about Java 8 support when asked about it.

They went cheapskates by not wanting to pay Sun, it is about time they settle their issues with Oracle.