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