Scala 2.12.3 Released | Hacker News Reader

Scala 2.12.3 Released

github.com

153 pointsvirtualwhys39 comments

Since Kotlin has been officially supported by Google for Android, Scala has a strong competition which I hoped to become Java3 one day. https://developer.android.com/kotlin/index.html

If you chose Scala for .map(), less noise and functions over Java 7, yes. If you chose Scala for type classes and the power of the type system then no.

Scala never had a good tooling story on Android, now even less that they moved into Java 8 bytecode.

Google is bringing Java 8 support, and from what I understood from one of their engineers, they are working on supporting invokeDynamic as well, so we might get the whole package: https://android-developers.googleblog.com/2017/03/future-of-...

Scala 2.12 has moved to Java 8 indeed, however this means modern features that are used for encoding Scala: invokeDynamic and default interface methods.

These should make Scala compiled code faster and more stable in regards to backwards compatibility. Both Java 6 and 7 have need EOLed. We cannot stand still because of Android's shitty support.

Google has effectively fractured the ecosystem, pulling off what Microsoft couldn't do with J#, and they got away with it. I actually think that they preferred to announce Kotlin as being a first class citizen as a marketing trick in order to offset the lack of support for Java 8.

Even so, Scala does in fact have great Android support:

1. Scala 2.11 will remain supported for some time, language-level features have already been backported from 2.12 and Typelevel.org also has a commitment to support it even further

2. We have great integration with the tool chain, see https://github.com/scala-android/sbt-android

3. For a pretty cool open source project made with Scala, that uses functional programming libraries like Cats and Monix, see: http://www.9cards.io

So if you think about it, given all the other tooling available, compared with other languages Scala actually has stellar support, along with actual projects ;-)

> Google has effectively fractured the ecosystem, pulling off what Microsoft couldn't do with J#, and they got away with it.

Mostly because of the SV love, that Microsoft lacked.

Sun and Oracle were right all along.

> Even so, Scala does in fact have great Android support:

I don't agree with it, because for me having to deal with SBT, outdated android plugins in InteliJ and GUI DSLs instead of Gradle, Android Studio and Studio GUI designer isn't a synonym for great.

Maybe it changed during the last two years, but that was the scenario I faced.

I think it has very much changed. In any case, open source tools are there to be improved by the community. If you feel sbt is not solving your problems in the right way or could be improved, please get in touch with us. We're always happy to make the tool easier to use, at all levels.

I am not really into Scala, just wanted a better alternative to Java 6 on Android.

Finally getting some kind of official support for Java 8 and addition of Kotlin solved that problem.

Mostly because of the SV love, that Microsoft lacked.

Or because one is the official language for targeting the most popular consumer OS in the world, whereas the other is just a transitional language that has no real advantages over the alternatives for the same platform.

Ah! So the original Java from Sun/Oracle is a transitional language that has no real advantages over the alternatives for the same platform, while Google's fork is the official language for targeting the most popular consumer OS in the world.

So they can get away with what Microsoft wasn't allowed to do , I get it.

Oracle could have gone to courts and stopped Google. Oh wait, they did and failed.

It is sad that Oracle's legal could not deliver on copyright or patent cases.

No, J# had no advantages on the .NET platform over the alternatives (C# and F#).

We are talking about J++ vs Android Java.

Arent IntelliJ and Android Studio one and the same? Hard for me to see how you can have "outdated Android plugins" in one, but great tooling in the other.

Android Studio is a fork of InteliJ, and includes parts of CLion as well.

InteliJ is always behind Android Studio, specially Canary version.

> Scala 2.11 will remain supported for some time

Even though I very much wanted this to be true, that promise has been broken. Scala 2.11 has been EOL'ed 3 months ago with 2.11.11.

Kotlin is not just for Android. It is superior on the backend as well with 100% Java interop and binary compatibility to boot.

Java 3 will always be Java ;-) it's how the industry works.

Re: compilation speed, a story with happy end: Achieving 3.2x Faster Scala Compile Time

Diagnostics:

- A method that takes an additional, implicit parameter that needs to be filled in by the compiler

- the Scala compiler synthesized an argument for that parameter using macros

- instead of using an existing value in the implicit scope

Conclusion: that's why a small source file took so long to typecheck.

Details at https://jobs.zalando.com/tech/blog/achieving-3.2x-faster-sca...

Compile time might be the only thing I truly dislike about scala.

With incremental compilation I find it's not a problem anymore. Obviously, ymmv, depending on your project size, used libraries, and other factors.

Are there any stats for the compiler speed difference?

https://scala-ci.typesafe.com/grafana/dashboard/db/scala-ben...

Maybe I'm reading these graphs wrong but isn't 2.12.x almost always at about the same level as 2.13 for 2017 compilations? Both of which don't seem that much faster than 2.11.

You're not reading them wrong. There are two things that made 2.13 faster than 2.12, one of which is suprising.

1. Ports from 2.12.x: https://github.com/scala/scala/pull/6001.

2. The removal of Scala parallel collections from the Standard library: https://github.com/scala/scala/pull/5603. Read discussion to find out why.

>"The removal of Scala parallel collections from the Standard library"

Does this just mean that the import statement has to be changed, or does it mean that I need to use SBT to dynamically download yet another thing?

I think optimizations get ported between 2.12 and 2.13 (remember 2.13 is pre-release).

Nearly twice as fast is pretty impressive IMO.

If you follow a few links in they have this blogs list: https://developer.lightbend.com/blog/2017-06-12-faster-scala...

Too bad major projects got stuck on 2.10 and there is no safe way to upgrade to anything newer. We were running into issues even upgrading to 2.11 with Spark.

Which are these major projects? Spark?

As far as I'm concerned, they are working on a way to upgrade to Scala 2.12. But closure serialization is the main blocker IIRC, for now.

Spark has been a massive disappointment with their Scala support.

I appreciate they have legitimate reasons and am not critical of them for it. It's just that many users of Spark are doing so through vendors like Cloudera, Hortonworks, Amazon EMR etc. And so, since companies often don't have the money/time to just continuously upgrade production Hadoop clusters often users are stuck on older versions of Spark for a very long time e.g. months or years.

This translates to if you're working in Big Data everything you touch must support 2.10.

Yeah I think that is one of the more successful projects using Scala.

> All 2.12.x releases will be fully binary compatible with 2.12.0

That's the scary bit of detail about Scala releases, so far - I find that an upgrade of the compiler is only possible if you've ready to build up everything.

What do you mean? That you depend on other dependent projects releasing versions compatible with 2.12? Isn't this reasonable?

Not really, if a library is stable and doesn't need any change it's likely that the developer will not bother to recompile it, or even will abandon it, making it unusable (unless you compile a new version yourself). You also need that all your dependencies are updated before you can upgrade yourself. I haven't touched Scala in a while so I don't know if it is still the case but it seems like a serious problem, in the long run it will be the cause of many lost libraries.

In Java you can use an old dusty library from 15 years ago without a problem.

I still disagree in this specific case.

2.12 was a major release; even a semi-active developer would recompile. If a dependency did break, then sbt just helped you avoid using an unmaintained library.

It seems fine to me. And sbt has made cross compiling so easy. A library author can easily support many scala versions.

Is it binary compatible with the previous version?

Yes, it is stated on the page

> As usual for minor releases, Scala 2.12.3 is binary compatible with the whole Scala 2.12 series.

Woohoo

Reply on news.ycombinator.com