
Scala 2.12 Roadmap - gourlaysama
http://scala-lang.org/news/2.12-roadmap
======
jondot
Honest question: with tooling (IDE) and build tools (SBT) to my understanding
remaining as-is despite of developer feedback, and Java 8 presenting itself as
a nice comeback (in my opinion) - is Scala adoption for big companies
(Facebook, Google, Twitter) still going up as it were in the high times of it?

~~~
adriaanm
(Scala tech lead here). We're doing everything within our means to improve
tooling -- we agree it's crucial. Which changes would you like to see that
aren't happening?

One engineer on the Scala team (Grzegorz Kossakowski) spent all of last year
on a much better algorithm for incremental compilation (name hashing), sbt
0.13 was a giant leap in usability IMO, and both IDE plugins have made
enormous progress over the last years (again, IMO).

~~~
bkeroack
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?

~~~
tormeh
My advice would be to just drop the IDE and go for editor+compiler. IDEs are
always confusing.

~~~
kclay
I always wondered how that worked with scala. Giving how complex some
libraries could be with use of implicits and not explicitly defining the
return time I always thought it would be a bit troublesome to try to program
without any use of intellisense. Then again I guess the same would apply to
dynamic languages such as javascript and python so maybe my concerns are not
really concerns.

~~~
ssmoot
As a counterpoint to this popular meme: Most developers I know are VIM
converts (from TextMate).

I've never seen their choice of editor improve their coding speed. Haven't
seen it on videos online. The idea that being fluent in VIM makes you an all
around faster/better coder and the IDE is a crutch just isn't supported by
evidence IME.

I use IntelliJ. The startup is a bit slower. And the minute or so pause if I
change up dependencies can be annoying (though that's rare). On the other hand
I always have method signatures at my fingertips, depend a lot less on the web
version (of the same documentation), can jump into compiled libraries for
exploring interfaces, and instead of a fuzzy "ack-like" symbol search, I have
true jump-to-definition/open-class, etc. I have access to the FSC which
provides continuous feedback as well. Ensime is a pale shadow of IntelliJ IME.

Maybe those things aren't important to some people. I find it makes me very
productive though, and I haven't met a VIM user who can outpace me yet (though
I did see some true VS.NET/RAD-tooling masters back in the day that could put
me to shame).

All this just to say: Use what works for you. If that's IntelliJ, cool. If
it's VIM, great. But there's a lot of anti-IDE sentiment out there. It's just
another tool. Use it if it makes sense. Judge it on it's own merits. You are
not less (or more) of a coder for using IntelliJ.

As long as you stay away from Eclipse at least. I think we can all agree on
that. ;-) (Seriously Eclipse... It's 2014, and you still can't easily theme
your IDE with a couple clicks?)

~~~
tormeh
Well, I haven't tried Intellij, but in my experience the best coding
environment is: 1\. Visual Studio 2\. gEdit

Visual Studio has incredibly good fuzzy code completion and gEdit has a total
lack of features to be confused by and good font rendering. I just look at all
the menus and buttons in Eclipse and I can't stand it. All this stuff can't
possibly be necessary.

Since VS is not available for neither Scala nor Linux I'm left with gEdit.

~~~
ssmoot
IntelliJ keeps most of it's buttons hidden (in v13 at least). Might be worth a
shot. I'm not entirely sure what you mean by "fuzzy code completion", but
IntelliJ supports case-insensitive-in-order-partial-symbol matching.

For example, "jsfmt" with match "jsonFormat", and display the matches as I
type so I can arrow-down and hit ENTER if I see what I want (or just keep
typing until the list filters down to the one I want).

Implicit invocations get underlined by default as well. Which is nice since
I'm rarely at loss for understanding what the compiler is doing to make this
code work.

~~~
tormeh
With fuzzy I mean that I can search for "tunnel" and get "channel". It does
sound fuzzy, unless it's hardcoded. Code completion in Eclipse isn't fuzzy, so
"temrinal" doesn't get you "terminal". In Eclipse it's basically just a regex.

------
kclay
As others are going to say, I wish they spent some of the time optimizing the
compile times, yes you can fix it with multi-projects and the incremental
compiler but sometimes that doesn't work to well especially when you start to
throw in advance scala features like macros. But maybe they are hoping the new
backend helps, from the docs it looks like it may in some cases.

~~~
adriaanm
First off, macros are not just an advanced feature. They are experimental.
Investments in tooling will always focus on official features first (not to
say we ignore macros, but we have to prioritize).

We spend a lot of time optimizing the compiler. Several big users have
reported nice speed ups on 2.11. I won't quote numbers (too hard to benchmark
accurately), but encourage you to give it a go. The upgrade is easy.

Also, it's just generally a good idea to design your software so that it can
be compiled incrementally in smaller modules.

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

~~~
adriaanm
Thanks, happy to hear it!

------
yeasayer
The requirement of Java 8 slightly shocked me at first, but then I saw that
Scala 2.12 isn't expected before 2016, so now I guess it's right.

------
programminggeek
I would be more excited to use Scala if the compile times didn't suck so much.
Even on a tiny project, it just feels like it takes too long to do anything.

I guess I'm too used to Ruby and PHP where I save and things happen right
away. My test suite runs in less than a second. Stuff like that.

Instead, everything takes 5-10 sec and that just breaks my flow constantly. I
used Golang and while I don't love the language I love the compiler a lot.
It's really fast and nice and feels like a dynamic language.

Anyhow, Scala compiler has been slow forever and probably will be slow
forever. Oh well.

~~~
adriaanm
This is where IDEs and sbt's ~compile come in handy. I don't hit build very
often, since the IDE tells me about my mistakes interactively, and, once it's
happy, a build makes for a great micro-break :-)

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

~~~
eeperson
SBTs upcoming client server split[1] should make such tooling IDE agnostic.

[1] [https://github.com/sbt/sbt/wiki/Client-server-
split](https://github.com/sbt/sbt/wiki/Client-server-split)

------
needusername
> We can’t have one Scala binary version target two different Java versions
> without further artifactId name mangling.

Yes you can. The classifier is made for this and the POM reference even uses
this as an example.

> Even if maven did have support for specifying the required Java version,

It does. You can for example use different profiles that are activated by the
JDK version. Again the POM reference covers this.

------
alphabetam
Why not call it Scala 3, since it's a rather big change?

~~~
DCKing
Scala 3 will be a bigger undertaking, likely to have a major amount of
breaking of core language contructs and other fundamental changes.
Experimentation is already underway: it's called the Dotty compiler [1].

[1]: [https://github.com/lampepfl/dotty](https://github.com/lampepfl/dotty)

~~~
adriaanm
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).

~~~
tormeh
Looking forward to it :)

------
wtetzner
How will the requirement for Java 8 affect the ability to write Android apps
in Scala 2.12?

~~~
frowaway001
It will likely be necessary to use existing third-party tools to translate
newer bytecode back to a version which Android understand.

(Although I certainly hope that Google finally just deals with it and supports
those class files by default in his dex/art software.)

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

------
ape4
I'd like to see the Scala version numbers be based on Java versions.

