6 ms·

Scala 2.12 Roadmap

86 points by gourlaysama 12y ago

jondot 12y ago
Honest question: with tooling (IDE) and build tools (SBT) to my understanding remaining as-is despite of developer feedback, and Java 8 presenting itself as a nice comeback (in my opinion) - is Scala adoption for big companies (Facebook, Google, Twitter) still going up as it were in the high times of it?
- dkhenry 12y ago
  You ask that like tooling and build tools are a big problem. I know there is a lot of vocal opposition to the state of the scala toolchain, but for those who use it as a daily driver it works great. Both the ScalaIDE eclipse plugin and the Intelliej Scala plugin are great and quite capable and as for the build tools, the problem has never been with the tools its been with the compile times which are slow across large code bases. That's not getting addressed, but there are ways around mitigating the effect of the compile times such as splitting the code base into smaller components and using the incremental compiler. I can't speak for large corporations, but I do see Scala adoption continuing to go up in the consulting space.
  - srean 12y ago
    Tooling yes that is needed and welcome, but for many software engineers, IDEs are the least exciting part of a language ecosystem. Plenty programmers, and that too very capable programmers manage just fine with an editor. Speaking strictly for myself I couldnt care less for an IDE, it is irrelevant for me, especially in the context of a language that is syntactically lot more terse than Java. I would rather have the Scala team focus on more pressing problems, code optimizers, compile times, run times, other backends (LLVM?, GCC?), more airtight abstractions around the JVM. These are damned hard problems and Scala has been making steady progress, so this is the part that I find exciting and promising. Then again many are incapable of programming without an IDE and throwing in an IDE often does not drastically improve the quality of their code either.
  - bad_user 12y ago
    Scala 2.11 went through a major refactoring of the compiler, it saw significant improvements in both total compilation time and incremental compilation and further improvements are planned in follow-up versions: http://www.scala-lang.org/news/2.11.0 http://www.scala-lang.org/news/2.11.0
- adriaanm 12y ago
  (Scala tech lead here). We're doing everything within our means to improve tooling -- we agree it's crucial. Which changes would you like to see that aren't happening? One engineer on the Scala team (Grzegorz Kossakowski) spent all of last year on a much better algorithm for incremental compilation (name hashing), sbt 0.13 was a giant leap in usability IMO, and both IDE plugins have made enormous progress over the last years (again, IMO).
  - bkeroack 12y ago
    I'm just starting with Scala and I find the IntelliJ Scala plugin immensely non-intuitive (and I'm a big JetBrains fan normally). Why do I have three different, apparently non-equivalent ways to create a new project (Java->Scala, SBT, Scala Module)? The tooling and documentation seems to assume familiarity with the Java ecosystem. I'm not a Java developer (nor do I want to be), I'm a Python guy. Am I really expected to learn Java first just so I can learn Scala?
    - dragosiulian 12y ago
      You might want to give the Eclipse Scala IDE a go. It's pretty easy to get started even if you're unfamiliar with Eclipse (watch the getting started video): http://scala-ide.org/download/current.html http://scala-ide.org/download/current.html Disclaimer: I'm the tech lead of the Scala IDE for Eclipse project
    - tormeh 12y ago
      My advice would be to just drop the IDE and go for editor+compiler. IDEs are always confusing.
      - kclay 12y ago
        I always wondered how that worked with scala. Giving how complex some libraries could be with use of implicits and not explicitly defining the return time I always thought it would be a bit troublesome to try to program without any use of intellisense. Then again I guess the same would apply to dynamic languages such as javascript and python so maybe my concerns are not really concerns.
- DCKing 12y ago
  If you frame your question in that way, it's hard to provide a good answer. IDE support and SBT are great for many people as was pointed out already, and they are improving. These complaints are, in my perception, quickly becoming a thing of the past. You also don't mention why you find Java 8 such a nice comeback. If it's mainly about lambdas, I don't think you properly understand why people use Scala. In addition, of the companies you mention, only Twitter uses Scala significantly.
  - acjohnson55 12y ago
    I'm going to opine that I think IDE support can (and probably eventually will) be a lot better. I don't think Scala support in IntelliJ or Eclipse is where Java support was in Eclipse 10 years ago. When I first used Eclipse with Java, it was like the IDE new the entire language it was masterful at providing me all the docs and refactorings I might want. Granted, Java then had a much bigger audience than Scala now, and Scala's a much bigger language for and IDE to fully understand. But I'm finding IntelliJ improves visibly on pretty much a biweekly basis. SBT to me is damn near disastrous, though. It's like they created this obtuse DSL for describing transformations to the immutable project settings, when they could have just used mutable features Scala already has, and obviated the need to learn a gnarly layer on top, with its weird rules and quasi-Scala syntax. The other thing that annoys the hell out of me is how difficult it is understand what keys exists in what scopes, what order tasks run in, and all the arbitrary translations between identifiers in the SBT shell versus the files themselves. I read the entire 40+ page Getting Started guide, and I still find it incredibly frustrating when I need to do nontrivial modifications to my build process. I really hope SBT is up for a complete overhaul. I don't think it is though, because I think it provides people who invest the time to learn all the magic incantations that warm fuzzy feeling of superiority, because only they can peer through the layers of inscrutable DSL-syntax and see the elegance far beneath. ...Now that I've got that out of my system, I agree that Scala is on the rise, and we'll see these aspects improve as more people start to realize just how powerful the language is building large systems -- the horizontal and vertical scaling benefits Odersky always talks about.
    - kasey_junk 12y ago
- adriaanm 12y ago
  I see Java 8 more as an even better gateway drug to Scala than Java 6, so I expect adoption to accelerate. (Then again, I'm biased.) Java-8-the-language is a pretty timid comeback. Functional programming is not just about lightweight syntax for function literals and some more type inference for polymorphic method calls. That's just the start. An FP language should also: * encourage immutability; * make it easy to write and refactor code that uses combinators (generic higher-order methods) --> local type inference is essential (IDE support for type inference doesn't help, unless other refactorings automatically update the synthetic type annotations) * encapsulating logic in functions rather than using dynamic dispatch (where it makes sense), naturally leads to pattern matching. Also, Scala has great support for asynchronous/event-driven/reactive programming through extensible for-comprehensions, and the macro-based scala-async framework. Then there's the OO side: interfaces with default methods are much more limited than traits,... I'm very excited about the VM improvements and the potential of more functional libraries in our eco-system, though! [edited for formatting]
  - hrjet 12y ago
    Having recently worked with a project employing Java 8, I whole-heartedly agree. The FP in Java 8 is so crippled as to be useless. Every time you use a lambda, you need to worry about checked exceptions and wrapping and unwrapping them. Also there is no Unit type, so you have to add `return null` everywhere. Moreover, the Java collection library is now a hodge-podge of ancient cruft haphazardly mixed with a half-hearted FP interface. Java seriously needs to drop pre 1.5 compatibility, and revamp the whole API.
    - cdmckay 12y ago
      If they revamped the API it wouldn't be Java anymore
- lmm 12y ago
  The IDE is much better than it was a year ago, in terms of stability, refactoring reliability, implicit highlighting.... It's still got a way to go, but it's there. I don't know about SBT, I've always found Maven to be better. Improvements to any language could be argued to threaten Scala, but most of Scala's advantages over Java still apply - better type inference, better concurrency support, case classes, pattern matching, higher-kinded types. Certainly I don't think anyone who's adopted Scala will be lured back by Java 8. If anything Java 8 seems to me to be more of a threat to C#, and especially to Kotlin, than to Scala. I don't know about big companies, but in London startups it feels like Scala adoption is still going up.
- pjmlp 12y ago
  > Java 8 presenting itself as a nice comeback On the enterprise, Java never went away. I am yet to see any JVM project that isn't using Java. Groovy is only used due to Graddle, Scala and others only by startups.
  - vorg 12y ago
    I wouldn't describe writing a build script for Gradle as "using" Groovy. Most Gradle build files out there seem to be fairly short, usually 20 to 100 lines long, and consist of nothing more than the standard DSL calls. The template was probably copied from some other project, and the blanks filled in. I've yet to see a Gradle build script that actually drops out of the DSL to use Groovy to do any programming. The build script "authors" would have no idea how to use any of the more advanced Gradle API calls or Groovy language features beyond collection literals and closures. Gradle even still ships with the ancient Groovy version 1.8.
    - pjmlp 12y ago
      Yes, that is pretty much my experience. In Germany there was a Groovy craziness in JUGs around 2010, mostly coupled to Grails projects. At JSF days in Austria Oracle guys were discussing adding first class support for writing JSF applications with Groovy. Fast forward to 2014, in our consulting projects when Groovy skills are requested, they usually mean that developer needs to take care of Gradle scripts.
  - adriaanm 12y ago
    > Scala [...] only [used] by startups That is not what we are seeing...
    - pjmlp 12y ago
      Outside some banks in London City and the typical Fortune 10 companies like Twitter, Facebook and friends, there is very little uptake if you expand the spectrum to the Fortune 500 boring corporate world. Which is the world I live in. Customers always ask for plain Java[1], since it gives them the highest value[2] for developer rotation. [1] Still Java 6 in most cases. [2] Which I actually find deplorable.
kclay 12y ago
As others are going to say, I wish they spent some of the time optimizing the compile times, yes you can fix it with multi-projects and the incremental compiler but sometimes that doesn't work to well especially when you start to throw in advance scala features like macros. But maybe they are hoping the new backend helps, from the docs it looks like it may in some cases.
- adriaanm 12y ago
  First off, macros are not just an advanced feature. They are experimental. Investments in tooling will always focus on official features first (not to say we ignore macros, but we have to prioritize). We spend a lot of time optimizing the compiler. Several big users have reported nice speed ups on 2.11. I won't quote numbers (too hard to benchmark accurately), but encourage you to give it a go. The upgrade is easy. Also, it's just generally a good idea to design your software so that it can be compiled incrementally in smaller modules.
  - kclay 12y ago
    With 2.11 I have noticed the same speed up so thank you for all the current optimizations that have been happening.
    - adriaanm 12y ago
      Thanks, happy to hear it!
yeasayer 12y ago
The requirement of Java 8 slightly shocked me at first, but then I saw that Scala 2.12 isn't expected before 2016, so now I guess it's right.
alphabetam 12y ago
Why not call it Scala 3, since it's a rather big change?
- DCKing 12y ago
  Scala 3 will be a bigger undertaking, likely to have a major amount of breaking of core language contructs and other fundamental changes. Experimentation is already underway: it's called the Dotty compiler [1]. [1]: https://github.com/lampepfl/dotty https://github.com/lampepfl/dotty
  - adriaanm 12y ago
    The changes as seen from the outside will be much more conservative than that. We're not ready to comment on specifics yet, but the main focus is to remove warts (deprecating them in 2.12/2.13 first where possible), make the type system and (thus) type inference more regular, and make safari^W scalac snappier. The compiler internals and language concepts are being simplified substantially (we've learned a lot of interesting lessons in compiler engineering in the last decade, some of which require bigger changes).
    - tormeh 12y ago
      Looking forward to it :)
- adriaanm 12y ago
  The Scala 2.x series is for source compatible releases. The goal is that you can just recompile your Scala 2.11 code on Scala 2.12. (As was the case for the upgrade from 2.10 to 2.11 -- modulo some changes necessary for important bug fixes.) We're reserving the bigger version bump for when source compatibility is not fully maintained. We take backwards compatibility very seriously, so the jump will be as small as we can make it (balanced with the need to keep evolving and improving the language). We'll share our thoughts on Scala's longer-term roadmap once they've crystallized (soon!).
programminggeek 12y ago
I would be more excited to use Scala if the compile times didn't suck so much. Even on a tiny project, it just feels like it takes too long to do anything. I guess I'm too used to Ruby and PHP where I save and things happen right away. My test suite runs in less than a second. Stuff like that. Instead, everything takes 5-10 sec and that just breaks my flow constantly. I used Golang and while I don't love the language I love the compiler a lot. It's really fast and nice and feels like a dynamic language. Anyhow, Scala compiler has been slow forever and probably will be slow forever. Oh well.
- adriaanm 12y ago
  This is where IDEs and sbt's ~compile come in handy. I don't hit build very often, since the IDE tells me about my mistakes interactively, and, once it's happy, a build makes for a great micro-break :-)
  - acjohnson55 12y ago
    I agree that for code changes, incremental compilation is usually reasonably painless. Compile times really kill me when I have to do a lot of clean builds, like when modifying my build scripts.
  - kasey_junk 12y ago
    One of the things I was hoping for in improved scala tooling was better IDE agnostic solutions for developers. For instance, I much prefer to use vim than an IDE, but due to the near requirement to have syntax checking in the editor to avoid long compile cycles I always end up giving up and using an IDE. That a common response to slow tooling complaints is that an IDE hides these issues is an indictment of the scala tool chain.
    - eeperson 12y ago
      SBTs upcoming client server split[1] should make such tooling IDE agnostic. [1] https://github.com/sbt/sbt/wiki/Client-server-split https://github.com/sbt/sbt/wiki/Client-server-split
wtetzner 12y ago
How will the requirement for Java 8 affect the ability to write Android apps in Scala 2.12?
- frowaway001 12y ago
  It will likely be necessary to use existing third-party tools to translate newer bytecode back to a version which Android understand. (Although I certainly hope that Google finally just deals with it and supports those class files by default in his dex/art software.)
  - pjmlp 12y ago
    They were pretty clear on the Android Google IO fireside talk that Java is Android's official language. However they refrained to make any comment about Java 8 support when asked about it. They went cheapskates by not wanting to pay Sun, it is about time they settle their issues with Oracle.
ape4 12y ago
I'd like to see the Scala version numbers be based on Java versions.
needusername 12y ago
> We can’t have one Scala binary version target two different Java versions without further artifactId name mangling. Yes you can. The classifier is made for this and the POM reference even uses this as an example. > Even if maven did have support for specifying the required Java version, It does. You can for example use different profiles that are activated by the JDK version. Again the POM reference covers this.

86 points by gourlaysama 12y ago

Honest question: with tooling (IDE) and build tools (SBT) to my understanding remaining as-is despite of developer feedback, and Java 8 presenting itself as a nice comeback (in my opinion) - is Scala adoption for big companies (Facebook, Google, Twitter) still going up as it were in the high times of it?

dkhenry 12y ago
You ask that like tooling and build tools are a big problem. I know there is a lot of vocal opposition to the state of the scala toolchain, but for those who use it as a daily driver it works great. Both the ScalaIDE eclipse plugin and the Intelliej Scala plugin are great and quite capable and as for the build tools, the problem has never been with the tools its been with the compile times which are slow across large code bases. That's not getting addressed, but there are ways around mitigating the effect of the compile times such as splitting the code base into smaller components and using the incremental compiler. I can't speak for large corporations, but I do see Scala adoption continuing to go up in the consulting space.
- srean 12y ago
  Tooling yes that is needed and welcome, but for many software engineers, IDEs are the least exciting part of a language ecosystem. Plenty programmers, and that too very capable programmers manage just fine with an editor. Speaking strictly for myself I couldnt care less for an IDE, it is irrelevant for me, especially in the context of a language that is syntactically lot more terse than Java. I would rather have the Scala team focus on more pressing problems, code optimizers, compile times, run times, other backends (LLVM?, GCC?), more airtight abstractions around the JVM. These are damned hard problems and Scala has been making steady progress, so this is the part that I find exciting and promising. Then again many are incapable of programming without an IDE and throwing in an IDE often does not drastically improve the quality of their code either.
- bad_user 12y ago
  Scala 2.11 went through a major refactoring of the compiler, it saw significant improvements in both total compilation time and incremental compilation and further improvements are planned in follow-up versions: http://www.scala-lang.org/news/2.11.0 http://www.scala-lang.org/news/2.11.0
adriaanm 12y ago
(Scala tech lead here). We're doing everything within our means to improve tooling -- we agree it's crucial. Which changes would you like to see that aren't happening? One engineer on the Scala team (Grzegorz Kossakowski) spent all of last year on a much better algorithm for incremental compilation (name hashing), sbt 0.13 was a giant leap in usability IMO, and both IDE plugins have made enormous progress over the last years (again, IMO).
- bkeroack 12y ago
  I'm just starting with Scala and I find the IntelliJ Scala plugin immensely non-intuitive (and I'm a big JetBrains fan normally). Why do I have three different, apparently non-equivalent ways to create a new project (Java->Scala, SBT, Scala Module)? The tooling and documentation seems to assume familiarity with the Java ecosystem. I'm not a Java developer (nor do I want to be), I'm a Python guy. Am I really expected to learn Java first just so I can learn Scala?
  - dragosiulian 12y ago
    You might want to give the Eclipse Scala IDE a go. It's pretty easy to get started even if you're unfamiliar with Eclipse (watch the getting started video): http://scala-ide.org/download/current.html http://scala-ide.org/download/current.html Disclaimer: I'm the tech lead of the Scala IDE for Eclipse project
  - tormeh 12y ago
    My advice would be to just drop the IDE and go for editor+compiler. IDEs are always confusing.
    - kclay 12y ago
      I always wondered how that worked with scala. Giving how complex some libraries could be with use of implicits and not explicitly defining the return time I always thought it would be a bit troublesome to try to program without any use of intellisense. Then again I guess the same would apply to dynamic languages such as javascript and python so maybe my concerns are not really concerns.
DCKing 12y ago
If you frame your question in that way, it's hard to provide a good answer. IDE support and SBT are great for many people as was pointed out already, and they are improving. These complaints are, in my perception, quickly becoming a thing of the past. You also don't mention why you find Java 8 such a nice comeback. If it's mainly about lambdas, I don't think you properly understand why people use Scala. In addition, of the companies you mention, only Twitter uses Scala significantly.
- acjohnson55 12y ago
  I'm going to opine that I think IDE support can (and probably eventually will) be a lot better. I don't think Scala support in IntelliJ or Eclipse is where Java support was in Eclipse 10 years ago. When I first used Eclipse with Java, it was like the IDE new the entire language it was masterful at providing me all the docs and refactorings I might want. Granted, Java then had a much bigger audience than Scala now, and Scala's a much bigger language for and IDE to fully understand. But I'm finding IntelliJ improves visibly on pretty much a biweekly basis. SBT to me is damn near disastrous, though. It's like they created this obtuse DSL for describing transformations to the immutable project settings, when they could have just used mutable features Scala already has, and obviated the need to learn a gnarly layer on top, with its weird rules and quasi-Scala syntax. The other thing that annoys the hell out of me is how difficult it is understand what keys exists in what scopes, what order tasks run in, and all the arbitrary translations between identifiers in the SBT shell versus the files themselves. I read the entire 40+ page Getting Started guide, and I still find it incredibly frustrating when I need to do nontrivial modifications to my build process. I really hope SBT is up for a complete overhaul. I don't think it is though, because I think it provides people who invest the time to learn all the magic incantations that warm fuzzy feeling of superiority, because only they can peer through the layers of inscrutable DSL-syntax and see the elegance far beneath. ...Now that I've got that out of my system, I agree that Scala is on the rise, and we'll see these aspects improve as more people start to realize just how powerful the language is building large systems -- the horizontal and vertical scaling benefits Odersky always talks about.
  - kasey_junk 12y ago
adriaanm 12y ago
I see Java 8 more as an even better gateway drug to Scala than Java 6, so I expect adoption to accelerate. (Then again, I'm biased.) Java-8-the-language is a pretty timid comeback. Functional programming is not just about lightweight syntax for function literals and some more type inference for polymorphic method calls. That's just the start. An FP language should also: * encourage immutability; * make it easy to write and refactor code that uses combinators (generic higher-order methods) --> local type inference is essential (IDE support for type inference doesn't help, unless other refactorings automatically update the synthetic type annotations) * encapsulating logic in functions rather than using dynamic dispatch (where it makes sense), naturally leads to pattern matching. Also, Scala has great support for asynchronous/event-driven/reactive programming through extensible for-comprehensions, and the macro-based scala-async framework. Then there's the OO side: interfaces with default methods are much more limited than traits,... I'm very excited about the VM improvements and the potential of more functional libraries in our eco-system, though! [edited for formatting]
- hrjet 12y ago
  Having recently worked with a project employing Java 8, I whole-heartedly agree. The FP in Java 8 is so crippled as to be useless. Every time you use a lambda, you need to worry about checked exceptions and wrapping and unwrapping them. Also there is no Unit type, so you have to add `return null` everywhere. Moreover, the Java collection library is now a hodge-podge of ancient cruft haphazardly mixed with a half-hearted FP interface. Java seriously needs to drop pre 1.5 compatibility, and revamp the whole API.
  - cdmckay 12y ago
    If they revamped the API it wouldn't be Java anymore
lmm 12y ago
The IDE is much better than it was a year ago, in terms of stability, refactoring reliability, implicit highlighting.... It's still got a way to go, but it's there. I don't know about SBT, I've always found Maven to be better. Improvements to any language could be argued to threaten Scala, but most of Scala's advantages over Java still apply - better type inference, better concurrency support, case classes, pattern matching, higher-kinded types. Certainly I don't think anyone who's adopted Scala will be lured back by Java 8. If anything Java 8 seems to me to be more of a threat to C#, and especially to Kotlin, than to Scala. I don't know about big companies, but in London startups it feels like Scala adoption is still going up.
pjmlp 12y ago
> Java 8 presenting itself as a nice comeback On the enterprise, Java never went away. I am yet to see any JVM project that isn't using Java. Groovy is only used due to Graddle, Scala and others only by startups.
- vorg 12y ago
  I wouldn't describe writing a build script for Gradle as "using" Groovy. Most Gradle build files out there seem to be fairly short, usually 20 to 100 lines long, and consist of nothing more than the standard DSL calls. The template was probably copied from some other project, and the blanks filled in. I've yet to see a Gradle build script that actually drops out of the DSL to use Groovy to do any programming. The build script "authors" would have no idea how to use any of the more advanced Gradle API calls or Groovy language features beyond collection literals and closures. Gradle even still ships with the ancient Groovy version 1.8.
  - pjmlp 12y ago
    Yes, that is pretty much my experience. In Germany there was a Groovy craziness in JUGs around 2010, mostly coupled to Grails projects. At JSF days in Austria Oracle guys were discussing adding first class support for writing JSF applications with Groovy. Fast forward to 2014, in our consulting projects when Groovy skills are requested, they usually mean that developer needs to take care of Gradle scripts.
- adriaanm 12y ago
  > Scala [...] only [used] by startups That is not what we are seeing...
  - pjmlp 12y ago
    Outside some banks in London City and the typical Fortune 10 companies like Twitter, Facebook and friends, there is very little uptake if you expand the spectrum to the Fortune 500 boring corporate world. Which is the world I live in. Customers always ask for plain Java[1], since it gives them the highest value[2] for developer rotation. [1] Still Java 6 in most cases. [2] Which I actually find deplorable.

kclay 12y ago

As others are going to say, I wish they spent some of the time optimizing the compile times, yes you can fix it with multi-projects and the incremental compiler but sometimes that doesn't work to well especially when you start to throw in advance scala features like macros. But maybe they are hoping the new backend helps, from the docs it looks like it may in some cases.

adriaanm 12y ago
First off, macros are not just an advanced feature. They are experimental. Investments in tooling will always focus on official features first (not to say we ignore macros, but we have to prioritize). We spend a lot of time optimizing the compiler. Several big users have reported nice speed ups on 2.11. I won't quote numbers (too hard to benchmark accurately), but encourage you to give it a go. The upgrade is easy. Also, it's just generally a good idea to design your software so that it can be compiled incrementally in smaller modules.
- kclay 12y ago
  With 2.11 I have noticed the same speed up so thank you for all the current optimizations that have been happening.
  - adriaanm 12y ago
    Thanks, happy to hear it!

yeasayer 12y ago

The requirement of Java 8 slightly shocked me at first, but then I saw that Scala 2.12 isn't expected before 2016, so now I guess it's right.

alphabetam 12y ago

Why not call it Scala 3, since it's a rather big change?

DCKing 12y ago
Scala 3 will be a bigger undertaking, likely to have a major amount of breaking of core language contructs and other fundamental changes. Experimentation is already underway: it's called the Dotty compiler [1]. [1]: https://github.com/lampepfl/dotty https://github.com/lampepfl/dotty
- adriaanm 12y ago
  The changes as seen from the outside will be much more conservative than that. We're not ready to comment on specifics yet, but the main focus is to remove warts (deprecating them in 2.12/2.13 first where possible), make the type system and (thus) type inference more regular, and make safari^W scalac snappier. The compiler internals and language concepts are being simplified substantially (we've learned a lot of interesting lessons in compiler engineering in the last decade, some of which require bigger changes).
  - tormeh 12y ago
    Looking forward to it :)
adriaanm 12y ago
The Scala 2.x series is for source compatible releases. The goal is that you can just recompile your Scala 2.11 code on Scala 2.12. (As was the case for the upgrade from 2.10 to 2.11 -- modulo some changes necessary for important bug fixes.) We're reserving the bigger version bump for when source compatibility is not fully maintained. We take backwards compatibility very seriously, so the jump will be as small as we can make it (balanced with the need to keep evolving and improving the language). We'll share our thoughts on Scala's longer-term roadmap once they've crystallized (soon!).

programminggeek 12y ago

I would be more excited to use Scala if the compile times didn't suck so much. Even on a tiny project, it just feels like it takes too long to do anything. I guess I'm too used to Ruby and PHP where I save and things happen right away. My test suite runs in less than a second. Stuff like that. Instead, everything takes 5-10 sec and that just breaks my flow constantly. I used Golang and while I don't love the language I love the compiler a lot. It's really fast and nice and feels like a dynamic language. Anyhow, Scala compiler has been slow forever and probably will be slow forever. Oh well.

adriaanm 12y ago
This is where IDEs and sbt's ~compile come in handy. I don't hit build very often, since the IDE tells me about my mistakes interactively, and, once it's happy, a build makes for a great micro-break :-)
- acjohnson55 12y ago
  I agree that for code changes, incremental compilation is usually reasonably painless. Compile times really kill me when I have to do a lot of clean builds, like when modifying my build scripts.
- kasey_junk 12y ago
  One of the things I was hoping for in improved scala tooling was better IDE agnostic solutions for developers. For instance, I much prefer to use vim than an IDE, but due to the near requirement to have syntax checking in the editor to avoid long compile cycles I always end up giving up and using an IDE. That a common response to slow tooling complaints is that an IDE hides these issues is an indictment of the scala tool chain.
  - eeperson 12y ago
    SBTs upcoming client server split[1] should make such tooling IDE agnostic. [1] https://github.com/sbt/sbt/wiki/Client-server-split https://github.com/sbt/sbt/wiki/Client-server-split

wtetzner 12y ago

How will the requirement for Java 8 affect the ability to write Android apps in Scala 2.12?

frowaway001 12y ago
It will likely be necessary to use existing third-party tools to translate newer bytecode back to a version which Android understand. (Although I certainly hope that Google finally just deals with it and supports those class files by default in his dex/art software.)
- pjmlp 12y ago
  They were pretty clear on the Android Google IO fireside talk that Java is Android's official language. However they refrained to make any comment about Java 8 support when asked about it. They went cheapskates by not wanting to pay Sun, it is about time they settle their issues with Oracle.

ape4 12y ago

I'd like to see the Scala version numbers be based on Java versions.

needusername 12y ago

> We can’t have one Scala binary version target two different Java versions without further artifactId name mangling. Yes you can. The classifier is made for this and the POM reference even uses this as an example. > Even if maven did have support for specifying the required Java version, It does. You can for example use different profiles that are activated by the JDK version. Again the POM reference covers this.