Scala 2.12 roadmap | Hacker News Reader

Scala 2.12 roadmap

scala-lang.org

81 pointsbased292 comments

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.

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

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.

Assuming it's really gaining momentum over Scala I won't understand why. What Kotlin has over Scala? Compile times? After coding for 1 hour I compile once to check if Intellij and I missed something. Are those 3-4 minutes too much time?

Right now, I would say the only thing it has is momentum on Android, given JetBrains relation to Studio.

Using Scala on Android requires a bit more tinkering with ProGuard than Kotlin does, and it isn't a focus of the Scala designers.

Also with Scala 2.12 going Java 8, one will be stuck with 2.11 for Android.

No Android will switch to newer OpenJDK so Scala 2.12 would be a valid target.

Spend some time reading the Android source code.

According to Jake Warton, they only cherry picked some parts of OpenJDK 7.

From the commits they also don't appear to ever fully support Java 8, only lambdas.

ever is a strong word. I know that at the moment they use some parts of OpenJDK 7, but If they need to comply the Java (tm) caused by licensing, they will be forced (sooner or later) to actually don't use a deprecated JVM. As I know OpenJDK will be depracted on 2024. so it will take some time, but it will come.

Given the rumors of ChromeOS and Android becoming one OS, by 2024 it will hardly matter.

2.12 doesn't include any (non-gated) changes though, so you can keep the same codebase and cross-build for 2.12 (for performance) and 2.11. So we're talking what, at least 3 years ("Aida", either 2.13 or 3.0) before Java 8 becomes a blocker for source-level features, at which point I imagine Android will have an answer.

I doubt Google team will change, given their attitude regarding Java 8, as demonstrated at both Google IO 2014 and 2015.

Also the way they are cherry picking features from OpenJDK 7 and some kind of lambda support.

For me, Android Java has become similar to Symbian C++ in terms of dev experience and language fork.

Well, that's the thing. If you have a small amount of code, the compile times are never a problem. Try compiling something like Apache Spark. It will be somewhere between 30-60 minutes depending on your disk speed, CPUs, etc. etc. The incremental builds are faster, but never less than 2 or 3 minutes for any change. You could potentially avoid this with the REPL, or use inotify to trigger a background compilation, but none of those really works all the time.

And yet it was written in Scala. That shows how little the compile times offset the goodies of using Scala.

At the time Spark was started, Java didn't have lambdas or closures, making the equivalent Java code for functional-programming-style ML code much more verbose. Whether the same decision would be made today is an open question (and probably depends on who you ask). A lot of other frameworks have made different decisions, such as keeping the core of the project in Java and supporting other languages as shims on top (in my opinion a more sensible decision...)

From what I observed it's close enough to Java that people can easily switch and are willing to. There's also enough brevity with the language to be at ease with it daily (not as much as Scala) where it may be enough that perhaps people might not want to invest time to go all the way to Scala.

One of the things I love about Scala is that you don't have to "go all the way" though - you can start by writing Java-like code using Java libraries, and move on to writing Kotlin-like code as and when you want to, and move on to more advanced features than that as and when you want to.

> One of the things I love about Scala is that you don't have to "go all the way" though

This is true of any language so it doesn't mean much.

Still, we went through the same thing with C++ 20 years ago. Google even used to have (still does?) a style guide saying which features to use and which ones not to use.

Instead of having to use a guide that tells me which features of a language are dangerous, I prefer a language that doesn't require such a guide in the first place.

Unfortunately it's impossible to combine that with seamless Java interoperability, because so many Java features are dangerous (null, exceptions, pervasive mutability, all of the methods on Object, finalizers, low-level thread manipulation) or at least cumbersome (use-site variance and the resulting existential types, control flow constructs built into the language syntax).

I don't think there are any dangerous things you can do in Scala that you can't do in Kotlin. Only safe alternatives that exist in Scala but not in Kotlin.

> Google even used to have (still does?) a style guide saying which features to use and which ones not to use.

Which is a good example on how not to write modern C++, given the things they don't allow to use and not loved that much in the C++ community.

To me, the benefit is what Kotlin has less than Scala.

It's an incremental improvement over Java and it fixes exactly all the complaints I have over Java and nothing more.

Also, its IDE support is just as good as Java.

But the language is not even out officially, let's see in five years how it fares. Right now, it's just a breath of fresh air over Java.

It's worth noting that typesafe are prioritizing reducing compile time but it's a 32 pass compiler (!)

We're working on gigantic production systems currently and with good modularization compile times are not a problem for us.

Here in Germany I am yet to see any job posting about it.

It is all about Java, Scala and Clojure.

Well Kotlin isn't even officially released yet (1.0 candidate came out last week) so no company is probably using it for production yet.

And even after that, it wouldn't be reasonable for any big company to adopt a language that's not at least at version 1.1 or 1.2.

I don't think one can make any pronouncement about Kotlin's success or failures for several years.

I wouldn't be so sure. A bunch of Android developers are severely hurt from being stuck with Java 7. I'd expect many production apps to be written in Kotlin pretty soon, about as fast as the switch from Objective-C to Swift went.

Scala is also an option and currently looks better on the cv.

This will of course improve for Kotlin, specially if they get some Google blessing.

EDIT: Also forgot to mention that on Swift's case, it is a first class language being pushed by the platform's owner, not a 2nd class language without any kind of consideration from the platform SDK.

It's a trivial conversion from Java to Kotlin, as opposed to Scala or Clojure, so I wouldn't expect people to be hiring explicitly for it.

And the fact that 1.0 RC was just released this month might tell you other reasons why. How many Scala jobs did you see advertised when 1.0 was released in 2004?

I wouldn't've described Scala as "gaining momentum" in 2004 either. Kotlin may eventually be successful (I don't think it should be; IMO Ceylon does everything that Kotlin does and does it better, but that's just, like, my opinion man), but the present hype is certainly premature.

I agree - Kotlin is gaining momentum in hype. Give it a couple of years and we'll see how it actually moves. Ceylon does not do Java interop as well as Kotlin does, IMO.

I'm tired of the Kotlin hype (particularly with it unreleased, and so rarely used in production). Many of its features are already part of modern Java, and its language features are very ad-hoc. I can easily see a future for Scala (it offers more radical improvements that Java will never adopt), and maybe see a future for Ceylon (it's a very clean design and the union types are a genuine innovation). I can't see one for Kotlin.

> I can't see one for Kotlin.

You can't see a future for a language that offers far more succinct code than Java, but maintains the ease of Java?

I think Java will close the succinctness gap with Kotlin. And I don't think Kotlin will be able to maintain ease as it evolves, because the design is very ad-hoc.

I don't see any syntactic features in Java 9 that will close that gap further, but I guess we'll see.

Many features are part of Java, but they are much more succinct. For example, if I've got a List of Integers and I want to add 5 to each one, then in Java I'd have to do something like:

`List<Int> myNewList = myList.stream().map(i -> i +5).collect(Collectors.toList());`

In Kotlin:

`val myNewList = myList.map(it+5)`

Can you see how that can be clearer and simpler to read? Technically it is doing the same thing, but it is much simpler to reason with. On top of that, you've got improved null safety, monkey patching and type inference.

Is "it" some kind of magic value? So much for Kotlin being simpler / more readable than Scala. At least _ looks like syntax.

That comparison looks misleading - the .stream() and .collect() are conversions, not necessary on every call by any means.

Kotlin's approach to null safety is ad-hoc and integrated into the language in a way that makes it hard to abstract over. I think it will lead to inconsistent code as the JVM ecosystem moves on to make more use of Option-like alternatives.

Monkey patching is pure evil in any large codebase.

I think Java will likely add more and more type inference in future releases.

Don't get me wrong, syntax and sugar are important. But a language that only offers those is probably not worth the overhead, and such things are relatively easy for the "parent" language to adopt.

"it" is a magic value that was introduced in Groovy, so a lot of people are familiar with it. You got used to "this" being a magic value, "it" is a pretty easy concept to grasp.

Besides, it's not any more magical than "_" (which has, what... eleven different meanings? [1]) and it's super convenient. Still, don't like it? Just explicitly name your closure parameter. But you'll be surprised how you will quickly stop doing that for trivial closure uses because finding names is such a pain.

You're right that Java 8 has been closing the gap, though, but note that Java 9 doesn't have any new language features that will close that gap further.

[1] http://stackoverflow.com/a/8001065/162410

> You got used to "this" being a magic value, "it" is a pretty easy concept to grasp.

FWIW I avoid "this" as much as possible. I prefer a named self, which Scala has a nice concise syntax for.

> Besides, it's not any more magical than "_"

Like I said, "_" looks like syntax. "it" looks like an ordinary value.

> which has, what... eleven different meanings? [1]

Sort of, but it's always obvious from context. I have literally never been confused by an occurrence of "_" in 3+ years of full-time Scala programming.

> ... was introduced in Groovy, so a lot of people are familiar with it

You're assuming here that a lot of people have used Groovy. People generally don't even use "it" in Gradle, the most common access people have to Groovy.

> I'm tired of the Kotlin hype (particularly with it unreleased, and so rarely used in production)

You call it hype, I call it enthusiasm.

But regardless of the names we use , what I find very interesting is that Kotlin is generating such positive feelings even though it's not even 1.0. I haven't seen this happen for languages in a while (probably "ever"). What's also striking is that most of what I read about Kotlin is positive, and again, languages hardly ever generate positive feelings so widely across the board.

Do you not remember when Java itself came out?

The positive feelings ring very false to me. Kotlin has announced a lot of features long before they were delivered, and taken a lot longer to deliver a working language than they originally claimed. It's the old "two types of languages" - most languages sound good when you talk about their features, it's only when you actually use them that the negatives become apparent.

I don't know anyone who's actually used both Kotlin and Ceylon and prefers Kotlin, and Ceylon is actually more mature (1.2 released recently, IIRC). But since King only advertises features that are actually implemented and release dates he can actually make, there's a lot more hype for Kotlin.

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.

Kotlin borrowed like 80% of mostly used Scala features and magically these features are ok in Kotlin, while in Scala they lead to millions of different ways to do one thing. Interesting.

Actually, most people who complain about Kotlin do so because they think Kotlin didn't borrow enough features from Scala. It's tough to satisfy everyone :-)

The bottom line is that if you like Scala, you are probably not going to like Kotlin and that's perfectly fine. Kotlin is for everyone else and it seems to be pretty successful with that audience so far.

I'm a fan of both actually. In my view they are targeting two different use cases. Kotlin is aiming for heavier Java interop using a smaller runtime. This is a big deal for Android. Scala on the other hand is a more independent language, with much less emphasis on interop.

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.

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

We are all eventually going to die...

It's not about will Java adopt more Scala features, it is about how will it look when it is all glued together. I think for Java it can only go for worse, since language is massive as it is right now. Adding more would only bring more confusion for the table. Also good question is how will it work with other components of same language. I am not programming in Scala, I mostly read about it and read it. Still on faculty, but few older friends of mine, who have finished faculty 3 years ago and started to work at local startup/small company all worked in Scala and they are amazed how good everything goes for the company and that couldn't but notice that "Developer Happiness" factor being pretty high. So all those things considered tells you something...

On side note: Lambdas and full generics were considered in first drafts of Oak (later Java). C++ did not have lambdas those days. They were dropped from Java because of project deadline pressure and no time to do them right, not some ideology.

> It's easy to churn out a lot of Scala code, but hard to read someone else's or debug a Scala program

I see this argument a lot in Internet forum discussions, but I've never met anyone who actually had problem reading production level Scala code more than problem reading Java code. Sure, people love to bring on Scalaz and other extreme type-level coded Haskell-like libraries where things can get hairy, because they're solving a complex problem. These people fail to show Java-equivalent of such complex Scala code, so a conclusion that Scala was complex is invalid.

However, when comparing things solving similar problems for which we have a Java project and a corresponding similar Scala project, let's say Apache Spark and Apache Hadoop, Spark's code wins in readability hands down.

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

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

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.

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

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

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.

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

Depends a lot on the style of Scala you write. If you write "Scala is a better Java style" (which is more what I do), it is not bad. If you write it as "functors and mondads are cool", it can be very hard for the other people to intelligently code review.

Agreed. However there is lot of "better" in the "Scala being better Java". It is not just nicer syntax. Even advanced features like implicit objects or abstract and path dependent types can be very useful and obvious at the same time, if used carefully.

I don't believe this is true, assuming your peers have had the proper training. As I said before we are one of the biggest scala shops and make heavy use of pure functional style and scalaz, it works out fine.

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.

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

I've heard this argument many times and it all boils down to "Scala is not Haskell", which is in fact a true statement. Scala is not Haskell and never meant to be a Haskell replacement, nor a pure FP non-strict language. Complaining effects or monads are broken in Scala is like complaining that nominal subtyping in Haskell is broken or that you can't just introduce state in Haskell whenever you want, like you can with Scala changing a val to a var. Different design choices, different strengths / weaknesses.

Anyway, Scala is probably one of very few languages that combines OOP and FP and at the same time has type system sophisticated enough that it can express directly or indirectly the stuff that Haskell can - maybe more verbose and there are some rough edges like you say, but hello, here is the news: Scala is not Haskell and it had to pay some price for other useful stuff that Haskell doesn't offer.

Also, Scala creators are generally aware of some shortcomings of the current Scala type system and are working hard on improving and simplifying things (DOT calculus). So if you know how to make effects or for yield notation better and fix these subtle problems - I think the community would appreciate your help.

> I've heard this argument many times and it all boils down to "Scala is not Haskell", which is in fact a true statement. Scala is not Haskell and never meant to be a Haskell replacement, nor a pure FP non-strict language.

Yes, but my point is that Scala's unholy combination of OOP/FP has been marketed as some sort of panacea... which it definitely isn't. I think, it's actually worse in both aspects: Erlang (modulo static type checking) beats it in the OOP realm, and Haskell (and Idris, etc.) beat it in the functional.

Try to use scalaz for anything serious, and I think you'll find out what I mean. Don't get me wrong, scalaz (and shapeles, etc.) are marvels of engineering, but they aren't sufficient in practice. Nor are they for any reasonable definition of the term 'usable'. Haskell/GHC is -- and in fact it's simple and easy.

Btw, now we can also enjoy 'cats'! Let's retread the whole "mtl" and "transformers" disaster once again in Scala! Fun! (I was around for the Haskell mtl/transformers/fundeps thing and... it didn't work. Monad &c. need to be part of standard library. For sanity.)

I just think programming languages is a realm where compromise doesn't work. Maybe I'm wrong, but...

> Anyway, Scala is probably one of very few languages that combines OOP and FP

Firstly, "Combine A+B does not necessarily improve anything"[1], but...

Secondly, see, this is the problem... having a few things signify "this cannot be mutated" does not an FP language make. It's far more complicated than that -- it's about culture. The Scheme authors recognized this and named anything that was "dangerous" (side-effecting) with a bang at the end so that it would be offsensive and stand out to any code reviewer. This is what FP is all about... not just paying lip service (which I think Scala is doing currently) to immutability.

EDIT: Look, I realize that I'm being an asshole with the beneift of hindsight, but still... I'm talking about what we should aspire to. Not just accept.

[1] I think the supreme example of this is in the O'Caml object system. It's basically better than any single-dispatch system out there, but nobody[2] actually _uses_ it. Why? Because it's just simpler to do in function style.

[2] Yeah, yeah, qualifiers, formal studies, etc.

There are conventions in scala to talk to the culture as well. Ya I agree that it can be hard to see effects occasionally. I just worked out a bug where some element was cached despite the fact that the function I wrote appeared to be pure. But still, in scala's culture braces at the end of a function are, by convention, representative of an effect.

Eg doSomething is pure and doSomething() has an effect. It's shades of grey. Scala ultimately may not be Haskell, but it's useful and a much better alternative to using Java. To lean on the JVM and be able to sell Scala is better than using Java just because it's what's already there. To transition away from java toward something better is a win. It's definitely a win. I'd love to work on haskell or introduce haskell in places that i work but no way in hell would I ever succeed. Only at a startup with the smartest of smart people. You can take interested ruby developers and chop them into decent scala devs and that's good for the pitch. How the hell do you take a team of mediocre devs and get them to write your next production system in haskell?

> Ya I agree that it can be hard to see effects occasionally.

Nono. The point is that they should be codified and forbidden in places they shouldn't be used. I cannot describe how much this matters to anyone who hasn't "absorbed" the Haskell mindset. (That's not your fault, it's mine. "More research/explanation needed" on my part.)

> ... and a much better alternative to using Java.

Yes, but it only if you use it as a "better Java". It fails _hugely_ if you try to do anything "advanced"... as in actual FP like lenses and things.

> I'd love to work on haskell or introduce haskell in places that i work but no way in hell would I ever succeed.

This is also a cultural problem. Migrate towards microservices and... there you go! Nobody actually cares what it's implemented in. (I think this is a somewhat sneaky/underhanded way to introduce it, but it... works.)

EDIT: If you want to see first-hand what I'm talking about try "monocle" or "shapeless", which -- while both being fantastically named and engineered -- fail on actual usage.

for/yield is fine. Haskell people love to get excited about the one extra flatten but it's really not a big deal.

Side effects in Scala are a little less obvious than unsafePerformIO calls, but not by much. One little unmanaged println isn't going to destroy the universe. The fact that Haskell will invisibly transform your code into lazy thunks, radically altering its performance characteristics, causes a lot more trouble IME.

Stack overflow problems are real, but you can get a lot of value out of the monad functionality without hitting them, particularly these days with a lot of effects being implemented as Free monad + interpreter. I wonder if Scala.js avoids the issue?

I'd probably switch to Ceylon or Idris if either had the ecosystem to match Scala. But for the time being they don't.

(EDIT: sorry, rampant editing. I apologize if you happen to reply to any of my intermediate edits.)

> for/yield is fine. Haskell people love to get excited about the one extra flatten but it's really not a big deal.

No, it's a big deal. It pollutes everything you do in "do" / "for/yield" notation.

Part of why do notation in Haskell is so amazingly beatiful and concise is that it doesn't force this absurd amount of pointless boilerplate on you.

(We can agree that they're technically equivalent, but SYNTAX FUCKING MATTERS, YO)

My thinking here is that Martin Odersky actually understood what was going on at a technical level, but didn't appreciate what was going on at the cognitive level of the programmer... and so just implemented the mechanism.

If you compound this with the semi-recent "cats"/"scalaz" schism over Monad and Functor, thus making us reexperience the monads-tf/monads-fd schism in Haskell-land... making me think that the supremely clever people behind these projects (no sarcasm!) never experienced the pain that comes from split ecosystems. Because if they had, they wouldn't have started "cats" without getting concensus first. My point is that you cannot meaningfully talk about Monad/Functor without that type definition being a core part of the language -- which it isn't in Scala.

Listen, I appreciate that they have a more difficult problem in some sense, because they've accepted subtyping as an actual thing that's useful. But that's their problem. Subtyping generally isn't very useful[1] and they're driven by OOP ideology... which is fine per se, but don't complain when it doesn't work out -- when the problems of subtyping are well-known and have been for the last 20-30 years.

[1] Use lenses and contra-/covariant functors instead when you actually need it.

> One little unmanaged println isn't going to destroy the universe. The fact that Haskell will invisibly transform your code into lazy thunks, radically altering its performance characteristics, causes a lot more trouble IME.

Yes, it will. Because it isn't just a little "println" here and there (in practice). The deal here is: I can mechanically scan all the code for unsafePerformIO and unsafeInterleaveIO, etc. I cannot scan Scala code mechanically for unsafe things because the possibilities are almost literally infinte. It's about "permit evil selectively" vs. "forbid evil when you see it". The latter doesn't work.

    making me think that the supremely clever people behind 
    these projects (no sarcasm!) never experienced the pain 
    that comes from split ecosystems. Because if they had, 
    they wouldn't have started "cats" without getting 
    concensus first.

What consensus? Do you understand why cat needed to be created in the first place?

It was created because it was impossible to work with these terrible, obnoxious (ex-)Haskell people anymore.

The main change from scalaz to cats is not the code, but the community: Friendly people behaving like adults who don't act gravely offended when people discuss potential approaches which don't look like 100% what Haskell came up with.

I think scalaz will fall out of use mid-term, because everyone is sick of their shit behavior.

No need to impune Haskell developers thanks. (Even if that wasn't your intention your comment does read that way.)

I'm just stating facts. No idea why these terrible people decided to join Scala in the first place. Maybe the Haskell community ejected them and they just picked their next community to harass?

Oh, fuck off.

You're complaining about "inclusiveness" and you say "terrible people" in the same breath. No. Fuck you, and fuck off.

> You're complaining about "inclusiveness"

Where?

> No. Fuck you, and fuck off.

That's exactly the kind of immature behavior which is not welcome in the community. Please stay in the Haskell land.

Don't imply this behavior is welcome in Haskell land!

lomnakkus, I've never heard of you in the Haskell community, but if you do consider yourself part of our community then act more decently in future. You're giving us a bad name.

> What consensus? Do you understand why cat needed to be created in the first place?

Consensus as in: Get the approval of the community or at least lobby for the inclusion of Monad/Functor/etc. in the Scala standard library. My point was that the inclusion in the standard library is key to making Monad/Functor/etc. work. If you don't have that then you end up with the sad sad situation of monad-tf/monad-fd except this time it's not Transformers[1], but the fundamental Monad/Functor/etc.

As for the rest of your comment: ... WHAT?

[1] Which, to be fair, were fairly controversial at the time.

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

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.

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

Certainly, but that's not what I was talking about is it?

My point was that there isn't a culture (in the JVM world) of just publishing the source. If there was there would be no problems other than source-incompatibility. The culture in Haskell-land is that either a) you publish the sources or b) you deal with whatever pain may come your way.

Mostly, people have followed approach a) when it comes to things like "parse JSON fast/reliably" (aeson), but b) when it comes to "oh, this is our trading platform/strategy". Which is fine... but the ecosystem usually benefits from the a) side of things.

(Shout out to Bryan o'Sullivan.)

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.

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.

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

I think you're the only one that prefers not having FunctionN interfaces. I remember someone releasing a library of all the separate cases in Java pretty soon after the functionality came out.

Optimizing lambdas with a JVM opcode is cool. Delaying implementing them until you can add an opcode for it is not cool. I feel like Java should have been able to implement them like Scala did, and add the optimization later if necessary.

> And regarding streams, I prefer one clean interface to having all the collection interfaces polluted with 1000 methods.

Agreed for methods that are "secondary", but I think many of those methods are fundamental to being a collection. It's very weird to me if I have to change my List into something else to do a basic list operation on it. And even for secondary operations I think a typeclass is a much more elegant way of separating those operations than having to wrap and unwrap.

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

Any polymorphic method will behave differently on different types - that's the whole point of polymorphism. I'd agree that map is a bad name for something with the semantics of the Scala method. Unfortunately at this point that's not realistically something we can change.

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

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.

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/

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

I, for one, welcome our Scala overlords.

> Scala 2.12 will require Java 8.

Goodbye Android.

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

No idea.

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

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.

Does Scala fix the null problem?

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.

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

Reply on news.ycombinator.com