Scala 2.12 Roadmap
scala-lang.org
scala-lang.org
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).
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?
Disclaimer: I'm the tech lead of the Scala IDE for Eclipse project
I've never seen their choice of editor improve their coding speed. Haven't seen it on videos online. The idea that being fluent in VIM makes you an all around faster/better coder and the IDE is a crutch just isn't supported by evidence IME.
I use IntelliJ. The startup is a bit slower. And the minute or so pause if I change up dependencies can be annoying (though that's rare). On the other hand I always have method signatures at my fingertips, depend a lot less on the web version (of the same documentation), can jump into compiled libraries for exploring interfaces, and instead of a fuzzy "ack-like" symbol search, I have true jump-to-definition/open-class, etc. I have access to the FSC which provides continuous feedback as well. Ensime is a pale shadow of IntelliJ IME.
Maybe those things aren't important to some people. I find it makes me very productive though, and I haven't met a VIM user who can outpace me yet (though I did see some true VS.NET/RAD-tooling masters back in the day that could put me to shame).
All this just to say: Use what works for you. If that's IntelliJ, cool. If it's VIM, great. But there's a lot of anti-IDE sentiment out there. It's just another tool. Use it if it makes sense. Judge it on it's own merits. You are not less (or more) of a coder for using IntelliJ.
As long as you stay away from Eclipse at least. I think we can all agree on that. ;-) (Seriously Eclipse... It's 2014, and you still can't easily theme your IDE with a couple clicks?)
Visual Studio has incredibly good fuzzy code completion and gEdit has a total lack of features to be confused by and good font rendering. I just look at all the menus and buttons in Eclipse and I can't stand it. All this stuff can't possibly be necessary.
Since VS is not available for neither Scala nor Linux I'm left with gEdit.
For example, "jsfmt" with match "jsonFormat", and display the matches as I type so I can arrow-down and hit ENTER if I see what I want (or just keep typing until the list filters down to the one I want).
Implicit invocations get underlined by default as well. Which is nice since I'm rarely at loss for understanding what the compiler is doing to make this code work.
I just create a build.sbt, project/build.properties, and then open my SBT project in IntelliJ. Since they added SBT import support a few months ago that works really well for me.
It's hard to pinpoint a developer 'instinct', but I think a build/dependency tool like rubygems or npm is one of the first things a developer bumps into, and becomes a central part of the experience _very early_, even before the experience of the language. With that in mind, SBT present a cryptic (some times even non-scala) like feel to it.
Actually npm doesn't even solve the issue of dependency management well for client-side dependencies - people apparently use Bower for that - and then just wait until you get the idea of building mixed apps. And then building stuff may not be so required for one-off JS scripts, but if you want to run a linter over your code, or to package dependencies in a single binary based on Common.js or AMD and maybe to do minification for distribution, then you're in for a world of hurt. And in case you think it's unfair to compare the clusterfuck that is Javascript's ecosystem against SBT/Scala, you may be interested to know that Scala.js (the Scala to Javascript compiler) is a pleasure to work with, one reason being that it just works with SBT.
The Ruby ecosystem is somewhat close to sane, but beginners still have to deal with gemspec versus bundler, rubygems versus Rails, rvm vs rbenv, plus the issue of native dependencies (for Scala/SBT, the only native dependency is the JVM itself and until 2016 at least Java SE 6 is all you need). And Python for example - is another example of a clusterfuck.
It's easy to forget as experienced developers that we did experience pain when we started with our current platform. Lets face it - when it comes to dependency management and build systems, we should be ashamed of ourselves. And now after having worked with other environments, SBT may suck (it does, it really does), but to me it sucks less than everything else I tried, because at least it solves most of my needs out of the box and for the edge cases there's usually a plugin available.
Rake is a cancer. SBT Tasks are far from straightforward, but they're certainly no more complex once you start throwing in dependencies. Tasks could use some work. But dependencies, project definitions, build settings, cross compilation, all light years ahead of anything in Ruby-land.
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.
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.
That said, later versions are starting to at least move in the right direction with the removal/de-emphasizing of the cryptic symbols and the consolidation of the core concepts.
I was only able to get over my hatred of sbt when I came to realize that it isn't a build tool. It is a hugely powerful task system with declarative, type safe syntax. That you can use it to build scala projects is just a side effect. Whether anyone needs a hugely powerful task system is another question...
In older versions of SBT (SBT 0.7 and earlier) the configuration was done using immutable settings. In SBT 0.10 there was a switch to the current model. I believe this was done to make the configuration more declarative. A side of affect of this is that builds can now be easily parallelized without becoming nondeterministic. It also means that, in general, you shouldn't care what order tasks a re run in.
As far determining what keys are available in which scopes, I have always found this pretty easy to determine by using the 'inspect' command in the SBT repl. Although, perhaps I am not entirely under standing your issue here.
SBT does have a problem for specific cases when you do need tasks to run in a particular order. However, this is something that is currently intended to be addressed[1] in the SBT 1.0 release, which is scheduled for the end of this year.
It's easy to inspect a single setting with `inspect`, but it's very unwieldy to try to examine the entire dependency tree this way.
The very un-Scala-esque syntactic rules in build.sbt files also are a huge pain for anybody who just needs to dabble. Clearly, writing Build.scala files was a major drag, but it really feels to me that the answer should have been a better pure Scala API, rather than a DSL. It's a really leaky abstraction.
View an example of my pain here: http://stackoverflow.com/questions/24286551/get-assets-to-co...
Yeah, I can certainly understand your frustration about finding info for the '<<=' operator. This is an unfortunate side effect of cleaning up the API. All of the old examples uses it but now the documentation doesn't explain it up front.
It sounds like your problem with examining the dependency tree might be solved by one of the 'inspect' sub commands (tree|uses|definitions). Running 'inspect tree <command>' will give you the entire dependency tree for '<command>'.
I'm not sure I understand your last point. What do you mean by 'better pure Scala API, rather than DSL'? Do you mean that the SBT API is not very good? Do you mean that the '.sbt' files are annoying to use? I'm a little confused since the DSL is a Scala API.
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]
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.
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.
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.
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.
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.
I wouldn't describe various investment banks, twitter and amazon as "startups".
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.
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.
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.
I think a faster compiler is coming, but probably not right away. From another comment on this page, it sounds like Scala 3 is going to break source compatibility to remove or improve a lot of the stuff that's holding progress back.
Well a C++ clean build would probably take a few hours. I know the projects I worked on did.
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.
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).
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!).
(Although I certainly hope that Google finally just deals with it and supports those class files by default in his dex/art software.)
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.