6 ms·

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 n

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

by jondot 12y ago

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.