Scala 2.12 roadmap

http://scala-lang.org/news/2.12-roadmap/

by based2 • 10 years ago

81 92 10 years ago

jkot• 10 years ago

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

incepted10• 10 years ago

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.

BrandonBradley• 10 years ago

I, for one, welcome our Scala overlords.

reality_czech4• 10 years ago

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.

eklavya3• 10 years ago

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

incepted10• 10 years ago

Scala was nice when it was the only alternative to Java but Kotlin has been slowly gaining some pretty solid momentum as a candidate for Java's replacement.

meddlepal• 10 years ago

Java guy here. Not a fan of Scala and I've written a bunch. Love me some Kotlin though lately. Scala just feels like a language shit show. Everything from editor tooling, to the compiler, to the overly complex millions of different ways to do one thing aspect about the language pisses me off.

reality_czech4• 10 years ago

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.

mercurial• 10 years ago

Java 8 already added lambdas, the optional type, and so on.

I think the best Java can hope for is "syntax as good as C#". I highly doubt Java will ever go for, say, pattern matching. Unfortunately, after the big efforts in Java 8, I don't see anything syntax-related planned for Java 9, so I guess Java developers are still in for a decade or two of autogenerated garbage.

pjmlp11• 10 years ago

I don't see anything syntax-related planned for Java 9

Just module declarations.

Many of the cool stuffs seem to be planned for Java 10. :\

pjmlp11• 10 years ago

But they will never add proper type inference, non alphanumeric method names, call by name, pattern matching,...

Too complicated for blue collar devs according to design team.

So if you want a F# or C# like language in the JVM, it won't be Java.

lmm15• 10 years ago

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.

Java doesn't have case classes, pattern matches, covariance, or higher-kinded types. Its optional type is seriously flawed in a way that will make migration harder (it can't contain null), and the library ecosystem hasn't yet moved away from using nulls, and while its lambdas are better than before they don't hold a candle to Scala's _ style for conciseness.

Maybe Java will adopt these things in say 5 years - but why would you want to wait 5 years for them? (And conversely: you like the Java 8 features? If you were using Scala you could've had them 5 years earlier).

In a production system, Scala is quite frustrating to work with because of the frequent backwards compatibility breaks

The backward compatibility breaks aren't very frequent now - that's a lot of what this roadmap is about.

and the slow-motion build times.

Building can be slow - but only to the extent that you're actually using the fancy features. If you write java-like code (e.g. explicit types on everything) you get java-like build times.

Not to mention the new stuff which almost but not quite duplicates the built-in Java stuff

You're going to have to mention it - what are you talking about?

It would be better just to have a better Java, not a hack on top.

It's not a hack on top. It's a full-fledged language (the existence of scala.js is proof of that). The JVM was always intended to support multiple languages.

incepted10• 10 years ago

Maybe Java will adopt these things in say 5 years - but why would you want to wait 5 years for them?

Exactly.

I'm an Android developer and while I have followed the latest OpenJDK developments on Android with interest, I don't really care much because I and my organization have already switched over to Kotlin. And since mixing Java and Kotlin files is so easy, everybody can do the transition at their own pace (we're still in the transition phase so our engineers are allowed to keep using Java if they so prefer but most of them have already switched 100% to Kotlin and they are not looking back).

It's a bit annoying to review code that mixes Java and Kotlin but it's temporary and I predict than in just a few months, the whole organization will be 100% using Kotlin. I suspect that by the time Android fully supports Java 8, we won't really care about it any more.

runT1ME2• 10 years ago

I don't think any of scala's good features are even on a Java road map anywhere.

It's actually a breath of fresh air to work on scala production systems. We don't use a mono repo and compile times are negligible. We are also one of the largest scala shops in the country and despite the various styles used in different projects, it's all been very maintainable and easy to read.

My main complaint is tooling and the fact that you do need good training to onboard the folks who don't have scala experience.

pkolaczk6• 10 years ago

you do need good training to onboard the folks who don't have scala experience

I can see where you're coming from, however I noticed that people experienced in Java and some other different programming language, like Python, Ruby or C++, don't need much baby-sitting to learn Scala. I've been showing some of my Scala code to other peers who don't do Scala daily for review and I never heard a complaint "I can't understand what this code is doing". More often I hear it feels quite Pythonic, only with braces and type annotations...

pkolaczk6• 10 years ago

To be honest, designing a good programming language is not just collecting random good features from other languages and gluing them together. Particularly, adding new features to an old and mature language like Java or C++ is very hard if not impossible to do right. We have a few examples of this in happened already in Java world: half-broken generics or support for lambdas with no proper map/filter etc. on basic collections (forcing to do a lot of conversions to/from streams). Sure, it is better than no generics or no lambdas at all, but it is Java that really looks like a hack now, not Scala.

There is also stuff that probably can't be taken out from Java without major backwards compatibility issues. E.g. Scala has no distinction for primitive/box types, which makes it much simpler and more elegant for basic imperative/OOP programming than Java.

As for frustration working with Scala - I didn't notice, despite working on a few projects for a few years now. I've known only one programmer in my whole career who complained about introducing Scala into one project because "Scala was too complex" and guess what... he was one of the poorest Java programmers on that team at that time. Java did not save him either. Reading his Java code was probably much more frustrating than waiting 5 minutes for a full Scala build would be. Poor programmers do exist and you should not blame the tool just because someone can't properly learn how to operate it.

lomnakkus9• 10 years ago

As for frustration working with Scala - I didn't notice, despite working on a few projects for a few years now.

TBH, if you're using Scala as a slightly better Java/C#, then you're probably going to get a lot of mileage out of it. As someone who really would prefer Haskell, the problem I find is that Scala has all these tantalizing features that you really want to use but which turn out to be broken in subtle ways. Anyone who's used scalaz will know what I mean.

The absurdity of "for { ... } yield" notation is one of the first things that springs to mind. (Given that "return" is NOT special or magical in any way in a Monad and can, in fact, meaningfully be repeated in the same function.).

The other major thing is that you can arbitrarily (and subtly!) do side effects while in "monadic" notation. That nullifies most of the advantages of having a do/for-yield notation in the first place.

There's also the stack overflow issues that are rampant if you actually try to use monads seriously in Scala, etc. etc. (This boils down to the JVM not having tail-call elimination.)

Scala is basically a cocktease when it comes to FP features. It promises loads, but doesn't really deliver. These days, I'd actually probably prefer C#/Kotlin/Ceylon over Scala[1] because at least they don't lead you astray in this way. (Obviously, I'd prefer to rewrite everything in Haskell, but we have an actual existing/working system written in Scala to support, so...)

TL;DR: These days we're using Scala as a "better Java" and if that's what you want, then you probably won't be disappointed. If you're looking for FP-as-it-should-be then you will be disappointed.

[1] Assuming we're only talking about language, not the wider ecosystem.

lomnakkus9• 10 years ago

In a production system, Scala is quite frustrating to work with because of the frequent backwards compatibility breaks

... and this gets exponentially worse if you depend on a lot of scala libraries. That's one reason that I absolutely abhor depending on anything Scala in my own Scala projects. Now, I'm not fanatical about it, but if there's an equivalent Java library with a reasonable interface then I'll definitely prefer that.

I can understand that maintaining binary compatibility is incredibly difficult for the Scala devs, but they really should have provided an easier way to just BUILD YOUR DEPENDENCIES FROM SOURCE[1] if it cannot find suitably binary-compatible dependencies. This would also ease the adoption of scala.js with its own forks/ecosystem for e.g. scalaz hugely. In practice everything I'm depending on is going to be open source and could just be fetched + built on demand rather than me having to wait for upstream to build + publish a new version. Usually people are considerate enough to not break source-compatibility willy-nilly, but predicting what will break binary compatibility is Dark Magick... which means that few people actually do that in practice.

[1] This is one of the very few things the Haskell/Cabal ecosystem got right from the start. It allows the compiler to evolve incredibly fast by just outright ignoring binary compatibility.

lmm15• 10 years ago

Mima is probably the most advanced binary compatibility checker anywhere. Not everyone's using it, but projects that do can provide very good guarantees.

Given that many dependencies are Java and there's no agreement on build tooling, it'd be hard to build all dependencies from source (I actually had a client look seriously into doing this). I mean given a maven project, the pom is included in the release and contains all the information (e.g. SCM tag) necessary to rebuild it. But not everyone's using maven.

ninjakeyboard3• 10 years ago

With professional Java8 and Scala experience, and as a published author of a book that uses both languages side by side, I strongly disagree.

Look at how Java8 implements lambdas via a Single Abstract Method (SAM) - it's syntactic sugar. Or look at the streams api and collections library - Java8 IS the hack on top of Java. Scala is built from the ground up to be a better language.

Java8 is not at all comparable with Scala. There is a giant gap in the quality of the core libraries and the quality of the language and implementations of functional features. Part of the problem is the history of the language. Bless java for the jvm but saying that scala is extrenous and that java should be improved to have those features ignores the evidence that it can't be done well ontop of what is already there.

randomThoughts9• 10 years ago

I'm not disagreeing with you, but regarding your examples, am I the only one that prefers the way lambdas and streams are implemented in Java?

First of all, the way lambdas are implemented at the JVM level was a big improvement on what others were doing. And Scala is actually moving in that direction, if I'm not mistaken.

And regarding streams, I prefer one clean interface to having all the collection interfaces polluted with 1000 methods. Not to mention that in scala you have those traps, like when you are applying a map over a set and you end up with less elements than expected.

pjmlp11• 10 years ago

Scala 2.12 will require Java 8.

Goodbye Android.

airplane3• 10 years ago

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

pjmlp11• 10 years ago

No idea.

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

acjohnson55• 10 years ago

Just use Scala 2.11 then. The only difference between the two versions is how they compile to bytecode, with 2.12 taking advantage of new JVM developments brought by Java 8.

desdiv• 10 years ago

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/

vpkaihla• 10 years ago

Does Scala fix the null problem?

lmm15• 10 years ago

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.

lomnakkus9• 10 years ago

Kind of. It's a sort of "bad karma" approach: There's no compiler support per se, but it's generally frowned upon to use "null" in native Scala code. Usually Scala APIs will use Option[T] to signify that something is optional and just assume that you don't pass a Some(null) -- I can't recall off-hand whether the latter will actually throw an NPE.

(Personally, I don't think that it's nearly sufficient, but as Paul Phillips would say "INTEROPERABILITY with Java!". Us Scala users suffer greatly for that nebulous goal.)

CheKhovHeming2• 10 years ago

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 (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/

[2] https://issues.scala-lang.org/projects/SI?selectedItem=com.a...

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

Scala 2.12 roadmap

Related Stories