13 ms·

Scala 2.12 roadmap

81 points by based2 11y ago

jkot 11y ago
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 11y 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 11y ago
I, for one, welcome our Scala overlords.
reality_czech 11y 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.
- eklavya 11y 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!!).
  - incepted 11y 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.
    - eklavya 11y ago
      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?
      - pjmlp 11y ago
        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.
        merb 11y ago
        No Android will switch to newer OpenJDK so Scala 2.12 would be a valid target.
        pjmlp 11y ago
        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.
        merb 11y ago
        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.
- mercurial 11y 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.
  - pjmlp 11y 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. :\
- pjmlp 11y 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.
- lmm 11y 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.
  - incepted 11y 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.
- runT1ME 11y 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.
  - pkolaczk 11y 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...
    - brianwawok 11y ago
      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.
      - pkolaczk 11y ago
        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.
      - runT1ME 11y ago
        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.
- pkolaczk 11y 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.
  - lomnakkus 11y 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.
- lomnakkus 11y 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.
  - lmm 11y 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.
    - lomnakkus 11y 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. 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.)
- ninjakeyboard 11y 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 11y 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.
    - lmm 11y 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? 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.
vpkaihla 11y ago
Does Scala fix the null problem?
- lmm 11y 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.
- lomnakkus 11y 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.)
pjmlp 11y ago
> Scala 2.12 will require Java 8. Goodbye Android.
- airplane 11y ago
  Won't Android move to Java 8+ once they officially adopt OpenJDK?
  - pjmlp 11y ago
    No idea. They have included parts of OpenJDK 7, that is about it.
- acjohnson55 11y 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 11y 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/ http://scala-lang.org/news/2016-schedule/
CheKhovHeming2 11y 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 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.atlassian.jira.jira-projects-plugin:release-page https://issues.scala-lang.org/projects/SI?selectedItem=com.a... [3] https://github.com/scala/scala/milestones https://github.com/scala/scala/milestones

81 points by based2 11y ago

jkot 11y ago

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 11y 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 11y ago

I, for one, welcome our Scala overlords.

reality_czech 11y 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.

eklavya 11y 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!!).
- incepted 11y 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.
  - eklavya 11y ago
    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?
    - pjmlp 11y ago
      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.
      - merb 11y ago
        No Android will switch to newer OpenJDK so Scala 2.12 would be a valid target.
        pjmlp 11y ago
        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.
        merb 11y ago
        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.
mercurial 11y 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.
- pjmlp 11y 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. :\
pjmlp 11y 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.
lmm 11y 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.
- incepted 11y 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.
runT1ME 11y 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.
- pkolaczk 11y 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...
  - brianwawok 11y ago
    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.
    - pkolaczk 11y ago
      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.
    - runT1ME 11y ago
      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.
pkolaczk 11y 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.
- lomnakkus 11y 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.
lomnakkus 11y 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.
- lmm 11y 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.
  - lomnakkus 11y 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. 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.)
ninjakeyboard 11y 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 11y 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.
  - lmm 11y 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? 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.

vpkaihla 11y ago

Does Scala fix the null problem?

lmm 11y 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.
lomnakkus 11y 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.)

pjmlp 11y ago

> Scala 2.12 will require Java 8. Goodbye Android.

airplane 11y ago
Won't Android move to Java 8+ once they officially adopt OpenJDK?
- pjmlp 11y ago
  No idea. They have included parts of OpenJDK 7, that is about it.
acjohnson55 11y 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 11y 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/ http://scala-lang.org/news/2016-schedule/

CheKhovHeming2 11y 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 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.atlassian.jira.jira-projects-plugin:release-page https://issues.scala-lang.org/projects/SI?selectedItem=com.a... [3] https://github.com/scala/scala/milestones https://github.com/scala/scala/milestones