
Scala 2.12 roadmap - based2
http://scala-lang.org/news/2.12-roadmap/
======
reality_czech
To be honest, I feel like the next few versions of Java will assimilate all of
Scala's good features. Java 8 already added lambdas, the optional type, and so
on.

In a production system, Scala is quite frustrating to work with because of the
frequent backwards compatibility breaks, and the slow-motion build times. Not
to mention the new stuff which almost but not quite duplicates the built-in
Java stuff, etc. etc. It would be better just to have a better Java, not a
hack on top.

~~~
eklavya
I have been using Scala commercially for 3 years now. Never have I come across
someone who didn't like it. Java veterans almost cry with joy after using
Scala. I don't know if I live in a Scala bubble but I don't believe that's
likely. And "Java will almost be Scala" nonsense never gets old it seems. It's
as stupid as "Go is almost Haskell" (but they both have lambdas!!).

~~~
reality_czech
It's not "nonsense" or "stupid" to think that Java will adopt more Scala
features over time.

You have to put Java in its historical context to understand how it came to
be. It was a mid 1990s over-reaction against the super-complicated, super-
fragile software that people were churning out with C++. It was designed as a
kind of babytalk that would avoid the complexity of speaking C++. Of course we
all know it was an over-reaction, leaving behind perfectly reasonable ideas
like multiple return values, lambdas, and unsigned numbers in a kind of French
Revolution against C++ silliness.

Scala is also an over-reaction in the other direction. It's like a cross
between Perl and one of the more pragmatic ML dialects. It's easy to churn out
a lot of Scala code, but hard to read someone else's or debug a Scala program.
(Case in point: seeing <anonymous> for every stack frame in backtaces.)
Eventually we will want to meet in the middle somewhere with regard to
complexity, and Java is best positioned to do that.

~~~
lmm
Eventually we're all dead. I don't think Scala will be the best language to
use in 10 or 20 years' time. I do think it's the best language to use today
(and I won't be leaving it until I see an alternative with higher-kinded
types, dependent types, strict evaluation, and project/dependency management
as good as maven).

------
jkot
It should have [2014]. There are already three milestones out and updated
schedule: [http://www.scala-lang.org/news/2016-schedule/](http://www.scala-
lang.org/news/2016-schedule/)

~~~
incepted
Definitely.

Having said that, it makes it easier to see that the schedule has already
slipped by months, even though it was announced two years ago.

------
desdiv
The latest roadmap[0] has the last 2.11.x release coming out Q3 this year.
That's far too early IMHO since the entire Android eco system is still stuck
on Java 7. Android is slowly moving to Java 8 but there's no definite timeline
on when that will be done.

[0] [http://scala-lang.org/news/2016-schedule/](http://scala-
lang.org/news/2016-schedule/)

------
CheKhovHeming2
There are plenty of Scala 2.12 roadmaps to choose from:

\- the original one (June 2014), linked from this article \- its Dec 2015
update [1] Of note is its prominent (Call for) Participation. Looks like the
Typesafe team is feeling overstretched now. \- for those of us following the
bug database, we're stuck with the outdated schedule [2] \- the GitHub
counterpart to the above is [3] which seems more accurate: it updates the
updated schedule eg by postponing by one month the release date for RC1 of
2.12.

So I've given up reading tea leaves from roadmaps and just wait for 2.12.0
when it becomes ready.

As to why that report in the (public) bug database is outdated, let's remember
the mindset formulated in
[https://twitter.com/adriaanm/status/571073842434547712](https://twitter.com/adriaanm/status/571073842434547712)
(declaring JIRA bankruptcy) which wasn't put in practice. Quoting: @adriaanm
our plan for Scala is to declare JIRA bankruptcy and run for the githubs.
Maybe take the top half of the open issues with us.

[1] [http://www.scala-lang.org/news/2016-schedule/](http://www.scala-
lang.org/news/2016-schedule/)

[2] [https://issues.scala-
lang.org/projects/SI?selectedItem=com.a...](https://issues.scala-
lang.org/projects/SI?selectedItem=com.atlassian.jira.jira-projects-
plugin:release-page)

[3]
[https://github.com/scala/scala/milestones](https://github.com/scala/scala/milestones)

------
BrandonBradley
I, for one, welcome our Scala overlords.

------
pjmlp
> Scala 2.12 will require Java 8.

Goodbye Android.

~~~
airplane
Won't Android move to Java 8+ once they officially adopt OpenJDK?

~~~
pjmlp
No idea.

They have included parts of OpenJDK 7, that is about it.

------
vpkaihla
Does Scala fix the null problem?

~~~
lmm
Yes, as best as can reasonably be managed while interoperating seamlessly with
Java. null still exists but the community strongly discourages using it (and
there's a compiler plugin that will make it a warning or an error). Standard
library methods don't expect or return null (e.g. Map#get returns Option), and
the ecosystem follows the same convention. Option is very widely used and
supported in for/yield syntax; better still it's a normal type in the language
that can be abstracted over by the usual mechanisms (e.g. scalaz defines a
Monad typeclass for it, so generic methods like traverse will work for
Option). When wrapping a Java library you have to use your own judgement to
know whether a method can return null (it's either that or force you to check
every java method call, which some languages do but makes interop awkward);
best practice is to wrap any calls to a possibly-null method in Option(...)
immediately so that the null never "escapes" into Scala-land.

Of late the scala-native ecosystem has grown to the point where you can
largely avoid using Java libraries at all. I can't remember the last time I
saw a null or a NullPointerException at my Scala job.

