5 ms·

Scala 2.12.3 Released

153 points by virtualwhys 9y ago

pspeter3 9y ago
Are there any stats for the compiler speed difference?
- clhodapp 9y ago
  https://scala-ci.typesafe.com/grafana/dashboard/db/scala-benchmark https://scala-ci.typesafe.com/grafana/dashboard/db/scala-ben...
  - stewbrew 9y ago
    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.
    - caoilte 9y ago
      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.
    - jvican 9y ago
      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 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 https://github.com/scala/scala/pull/5603. Read discussion to find out why.
      - tormeh 9y ago
        >"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?
- jghn 9y ago
  If you follow a few links in they have this blogs list: https://developer.lightbend.com/blog/2017-06-12-faster-scala-compiler/ https://developer.lightbend.com/blog/2017-06-12-faster-scala...
hderms 9y ago
Compile time might be the only thing I truly dislike about scala.
- tasuki 9y ago
  With incremental compilation I find it's not a problem anymore. Obviously, ymmv, depending on your project size, used libraries, and other factors.
stephen123 9y ago
Woohoo
nancyp 9y ago
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 https://developer.android.com/kotlin/index.html
- _Codemonkeyism 9y ago
  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.
- xyzxyz998 9y ago
  Google hires more republican lobbyists now and approved Kotlin which by a Russian firm.
- pjmlp 9y ago
  Scala never had a good tooling story on Android, now even less that they moved into Java 8 bytecode.
  - bad_user 9y ago
    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-java-8-language-feature.html?m=1 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 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 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 ;-)
gopalv 9y ago
> 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.
- jvican 9y ago
  What do you mean? That you depend on other dependent projects releasing versions compatible with 2.12? Isn't this reasonable?
  - stephen123 9y ago
    It seems fine to me. And sbt has made cross compiling so easy. A library author can easily support many scala versions.
  - ajnin 9y ago
    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.
    - Cyph0n 9y ago
      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.
StreamBright 9y ago
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.
- jvican 9y ago
  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.
  - StreamBright 9y ago
    Yeah I think that is one of the more successful projects using Scala.
  - threeseed 9y ago
    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.
edem 9y ago
Is it binary compatible with the previous version?
- shmolyneaux 9y ago
  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.
AheadOfTime295 9y ago
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-scala-compile-time/ https://jobs.zalando.com/tech/blog/achieving-3.2x-faster-sca...

153 points by virtualwhys 9y ago

pspeter3 9y ago

Are there any stats for the compiler speed difference?

clhodapp 9y ago
https://scala-ci.typesafe.com/grafana/dashboard/db/scala-benchmark https://scala-ci.typesafe.com/grafana/dashboard/db/scala-ben...
- stewbrew 9y ago
  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.
  - caoilte 9y ago
    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.
  - jvican 9y ago
    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 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 https://github.com/scala/scala/pull/5603. Read discussion to find out why.
    - tormeh 9y ago
      >"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?
jghn 9y ago
If you follow a few links in they have this blogs list: https://developer.lightbend.com/blog/2017-06-12-faster-scala-compiler/ https://developer.lightbend.com/blog/2017-06-12-faster-scala...

hderms 9y ago

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

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

stephen123 9y ago

Woohoo

nancyp 9y ago

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 https://developer.android.com/kotlin/index.html

_Codemonkeyism 9y ago
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.
xyzxyz998 9y ago
Google hires more republican lobbyists now and approved Kotlin which by a Russian firm.
pjmlp 9y ago
Scala never had a good tooling story on Android, now even less that they moved into Java 8 bytecode.
- bad_user 9y ago
  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-java-8-language-feature.html?m=1 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 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 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 ;-)

gopalv 9y ago

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

jvican 9y ago
What do you mean? That you depend on other dependent projects releasing versions compatible with 2.12? Isn't this reasonable?
- stephen123 9y ago
  It seems fine to me. And sbt has made cross compiling so easy. A library author can easily support many scala versions.
- ajnin 9y ago
  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.
  - Cyph0n 9y ago
    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.

StreamBright 9y ago

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.

jvican 9y ago
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.
- StreamBright 9y ago
  Yeah I think that is one of the more successful projects using Scala.
- threeseed 9y ago
  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.

edem 9y ago

Is it binary compatible with the previous version?

shmolyneaux 9y ago
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.

AheadOfTime295 9y ago

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-scala-compile-time/ https://jobs.zalando.com/tech/blog/achieving-3.2x-faster-sca...