It isn't that Java 8 will kill Scala, it is that Scala has demonstrated the utility of lambdas to the point where they can safely be incorporated back into Java. So Scala has "won", but in my opinion likely Scala will now fade away.
Java is necessarily very conservative with adopting language features, because it is very careful to maintain backwards compatibility. Java is a bit like Debian stable - out of date compared to Debian testing or even other distros - but solid as a rock. For features to make it into Java, they really need to be proved first in other languages or in external libraries.
This isn't the first time Odersky has advanced Java either - he worked on Pizza, which showed how to add Generics to Java. Scala demonstrates how to add functional features to Java. Generics were a huge advance, and I think lambdas will be as consequential.
So if Scala does die, it will be as a sacrificial lamb, rather than as a casualty of an unseen war.
I like to think of lambdas as the hook that shows Java developers how Scala can help their code but its other features are what make them stay.
As the article says, "type inference, traits, vals, implicits, case classes, value classes, static objects, pattern matching, type variance, macros, immutable datatypes, lazy vals, existential types, higher-kinded types, type classes".
(Pattern matching is amazing, I don't know how I lived without it)
Agreed: there's definitely still more features in Scala. But Java has taken "Scala - the good parts"; or at least, what they consider the good parts. That'll be enough for many people, and my guess is it will suck the air out of Scala's room.
I do consider some of those other features important, and wish we could have them in Java, but they aren't as well-proven yet. (For me, it is easy immutable classes; I like pattern matching but can cope without it.)
I think it's more that they've taken one good part, but in their defense it's probably one of the best parts :).
Pattern matching and specifically algebraic data types are probably the most important to me since I find algebraic data types to be such an incredibly powerful data modeling tool. I find that almost any problem I encounter in my daily work can easily be modeled using algebraic data structures and from there the code is always some set of "trivial" set of pure pattern matching functions. Unfortunately the full power of pattern matching (compiler-checked exhaustiveness/consistency checks, specifically) can only really be emulated with the visitor pattern in Java -- which is just too much boilerplate syntax to make it useful outside of special cases.
I loathe implicits with the heat of a thousand suns. I mean, I love implicit conversions for easy addition of syntactic sugar, but they should be used very sparingly.
It could just be my indoctrination into Python's more of Explicit Over Implicit, but I hate it when things mysteriously turn into things or get passed as implicit arguments because something was in scope. My most hated form is nested implicit conversions, it kills code readability immediately if you can't figure out what type or object actually got passed in. And I'm using IDEA btw, so about as much tooling on hand to interpret said code as I'm likely to get.
Of course, you don't have to use implicits, but so much idiomatic Scala code (if I can interpret Typesafe's output to indicate idiomatic Scala) uses it, so I guess it's here to stay.
I do love the pattern matching though, especially when it's destructuring.
Yes, but when an implicit conversion has been applied to an implicit conversion has been applied to a... ...well, underlining it helps but can't convey all that has gone on.
As a Scala and Java developer, I am not even slightly tempted to replace Scala as my main language for my next project with Java 8. If I'm forced to write Java, it might better be Java 8, but if I have a choice, there are so many things (as the OP correctly states) that make Scala compelling for me beyond Lambdas that just adding that feature to Java doesn't really mean anything to me. Ruby has Lambdas, so does Python and JavaScript, Dart and I'm sure any other modern language. I like Scala because of so many other things other than lambdas that a single comment is not enough.
But to name a few (some were referenced by the OP)
Everything is an expression, For comprehensions (especially with multiple futures, resolving the callback triangle of death in a beautiful syntax IMHO), Implicit conversions, Case classes, Pattern Matching, Tuples, The fact that everything has equals and hashcode already correctly implemented (so I can put a tuple, or even an Array as a key in a map), string interpolation, multiline string, default parameters, named parameters, built in dependency injection, most complex yet most powerful type system in any language I know of, type inference (not as good as Haskell, but better than the non existent in Java). The fact I always get the right type returned from a set of "monadic" actions thanks to infamous things like CanBuildFrom (which are pure genius). Let's not forget pass by name arguments and the ability to construct a DSL. Extractors (via pattern matching). And many more.
I think Scala is here to stay, at least for Scala developers, I am 100% sure you will not find a single Scala developer that will say: "Java 8 got lambdas? great, goodbye scala forever!". Only reason I can think of is compile time and binary compatibility. If we ignore those two, all I can say is that this just proves how Scala is in the right direction (since Java 8 lambdas and default interface methods and steams are so clearly influenced)
I do wish however that Scala will improve Java 8 interoperability, e.g. support functional interfaces the same way. and add new implicit conversions to Java 8 collections as well as take advantage to improvements in the JVM.
I will replace Scala as soon as I find a language that gives me what Scala does and does it better. So far I didn't find such a language (examined Haskell, Clojure, Go, Kotlin, Ceylon, Dart, TypeScript, Rust, Julia, D and Nimrod, Ruby Python, JavaScript and C#, some of them were very promising but since I need a JVM language, and preferably a statically typed one, it narrowed down the choices pretty quickly)
Java 8 is by far not even close, sorry. Great improvement, I'm very happy for Java developers that will get "permission" to use it (might be easier to adopt than Scala in an enterprise) but this is not a reason for a Scala shop to consider moving back to Java.
I would use Java 7 rather than Scala in production environment. There are different reasons, some actually concern language features but one of the biggest is IntelliJ's capability as Java IDE. It blows away all of the other alternatives as efficient way of creating readable code that is breeze to refactor. Even though Java lacks features that make life easier, the lack of features is important, too. And as a former Scala enthusiast (when it was not so hot), I just dislike Scala's monstrosity. I have high hopes for Kotlin because it has some advanced stuff that have been clearly included by the experience of using Scala. And it in all likelihood will have very good IntelliJ interop, because JetBrains.
I don't get it why people fuzz over languages without a context of tools.
"Production environment" is a very relative and subjective notion. We used Scala on the server-side for basically real-time bidding, with the servers receiving several thousands of requests per second per server instance, with a total of about 30,000 reqs per sec of real traffic coming in, to which we had to reply in a maximum of 100ms which included the network roundtrip. Without Scala, without the ease with which I could juggle with concurrency issues and asynchronous processing of streams, I couldn't have pulled it off. So in other words, Java is unfit for a production environment from my perspective.
> one of the biggest is IntelliJ's capability as Java IDE
That's a pretty shallow reason if you ask me, because the speed of writing code is not the point and IntelliJ IDEA 13 is also very, very good for Scala development.
> I just dislike Scala's monstrosity. I have high hopes for Kotlin
Well, there's your problem. You thought that Scala is something that it isn't, like a "better Java". If you approached it like that, without delving in its FP capabilities that Java 8, Kotlin, Ceylon, Groovy cannot match (or whatever "better Java" is the fad du jour), then of course it was a bad experience.
Just a quick comment: If I wanted to embrace functional programming, I would skip Scala and goto Haskell, ML, or Clojure. And if I cared, I should really dig deep into this subject (tool vs. language). Scala just doesn't fit my needs. btw. I've preordered that book awhile ago just for supporting it but not really interested in it.
Becoming professional, and gaining experience has given insight in helping to choose stack in respect to matureness, stability, tool support, documentation etc. It's not that you cannot write Scala code for production and be happy about it. But I rather not. Writing fast is only one part of it. IntelliJ supports the whole aspect of development cycle, and it's good to hear Scala plugin is catching up. Just my opinion.
> If I wanted to embrace functional programming, I would skip Scala and goto Haskell, ML, or Clojure.
Interesting choice of languages. Out of that list, only Haskell is suitable for the argument you're trying to make.
Is that SML or Ocaml? If that's SML, well it's a really poor choice. And what makes you think Clojure is better for functional programming? I'm not arguing that it isn't, it's just interesting seeing it in a list of what are supposed to be better choices for FP. Because in my opinion, Clojure is just as dirty as Scala or maybe even more so. And it's also a Lisp and the styles and patterns used tend to be different in Lisps, than what you do in Haskell or Scala.
That book I linked is not about Scala, but about FP and just happens to use Scala as the language. It's a good book. If you preordered it, it would be a waste to not read it.
What I meant is that if I needed to switch from Java to a language that is oriented towards functional style, I would not consider Scala -- not because it wouldn't be a good choice regarding FP (I'll leave arguing about how well a language is suited to FP for others) but because considering all it has to off, and how its promise was not fulfilled for me -- or maybe it was me what changed.
It's much, much better than it used to be but it is still not as good as the Java support. I write both in my day job and while I much prefer scala, anyone who feels that IntelliJ's scala support is equal to java is deluding themselves. At least a few times a day I come across something where I start shaking my fist at the IDE over something which would Just Work for java.
That said, it is improving and closing the gap rapidly.
Perhaps you're using more of the IDE features than I am. I spend most of my day in IntelliJ writing Scala code (and a bit less maintaining old Java code) and haven't spotted any major issues with the features that I use.
Scala tooling has improved hugely, just look at the Scala IDE and the IntelliJ Scala plugin now vs. 2 years ago.
The only area where I have ongoing issues with my IDE (Scala IDE) is with the play template plugin, can really wreak havoc in both template and controller layers with spurious errors that break mouse-hover type inference click-through-to-type functionality. Even here there's been a ton of improvement, 2 years ago in the template layer there was no semantic highlighting, no indication of _valid_ errors, and stack trace error lines pointed to lines in the generated template, not the .scala.html source file, fun times o_O
Recently switched to XML literals in place of Play's @ templates, not surprisingly the above issue has disappeared, and am now left with a fully functional IDE, code completion, refactoring, and the all the rest, pretty thrilled about the IDE story in Scala to be honest.
I +1 that, the tooling of Scala is comparable to what is available to Python and Ruby developers, given that building a proper IDE for such language is not a simple task, but right now Scala IDE (eclipse-based) and Intellij IDEA's support is more than satisfying to me.
> I don't get it why people fuzz over languages without a context of tools.
Because many rather stay in 1970 era of PDP11 command line and text editors and never experienced with the 1960 ideas implemented in Xerox PARC 1970 languages and 1980 GUI environments.
If you're talking about tool availability and production readiness then I think Scala has the advantage over Kotlin. By the time Kotlin reaches a similar level of maturity, how many features will it have that haven't found their way into Java?
(I don't think Scala's a thousand-year language, but I think Kotlin drops too much of what makes it good; I'd look to the likes of Ermine as a potential future replacement. But more to the point, Scala is production-ready today - I know because I use it in production)
These are all great reasons to stick with Scala. However, to survive Scala must also attract new developers; I think a better Java will lessen that influx.
I'd say the bigger threats to Scala in terms of adoption are potentially Kotlin (and the strong JetBrains tooling that will inevitably come with it), typed Clojure, and Haskell.
Otherwise, Java 8 is not a game changer for the simple fact that the enterprise moves at a snail's pace in terms of adoption. Teams with the flexibility to switch from pre-Java 8 to Java 8 will likely also have the freedom to choose an alternate JVM language, or perhaps even Haskell if they're not tied to the JVM.
Good points, but one huge advantage of Java is much faster compile times and much more mature tooling.
I actually favor Clojure to Scala as a matter of personal choice, but Java has lots of valid use cases dealing with tooling and compatibility to existing systems.
sub projects + incremental builds on a warmed up JVM make for a very quick dev cycle.
Deploying is another matter, full builds lag far behind Java, something that will not be changing anytime soon, scalac is doing a ton of work under the hood.
I wonder if Java's syntax and use of lambdas will be near how nice it is in C#. They're extremely useful and convenient in c# especially with all the automatic casting around them. Adding to an Event with a simple myEvent += (int x) => {doThing(x);}
> This isn't the first time Odersky has advanced Java either - he worked on Pizza, which showed how to add Generics to Java. Scala demonstrates how to add functional features to Java. Generics were a huge advance, and I think lambdas will be as consequential.
Don't assume because Pizza's purpose was to get generics into Java then Scala's purpose is to get lambdas into Java. Scala's purpose could've been to lead Java developers onto Haskell by providing a stepping stone at the halfway point. And of course purposes can change: Scala's aim may now be just to make as much money as possible for Typesafe's owners. It wouldn't be the first programming language to have been repurposed in that direction.
I just can't imagine going back to Java. The cumbersome object definitions. The endless type declarations. The lack of case classes (algebraic types). The lack of pattern matching. The lack of named arguments. The difficulty in creating immutable objects.
Even implicits; they can be overused but in my mind they're just a better way of dealing with contextual information than stateful objects like ThreadLocal.
I also think Scala has shown Kotlin the way, and Kotlin – in terms of adopting features based on maturity – is half way between Scala and Java, which is a better place to be, IMO, at least for those companies that want to try new things but don't want to mess with the cutting edge, either.
Personally, I think Scala is a decent research language for testing out language features, but it is not a right fit for adoption in large organizations. Obviously, others will disagree, but that's not the point.
The point is that some organizations and developers want to use cutting edge languages, and the majority are more conservative. Neither of them is "right", and both are necessary. Early adopters show the way by trying new things sometimes successfully and sometimes less so, and without them we'll be stuck in our old ways. But if everyone were an early adopter, the industry would frantically jump from one language to another, re-inventing libraries and not getting much actual work done.
Java 8 has the potential to kill languages that were designed with the purpose of being a "better Java". Scala ain't one of them. Clojure ain't one of them either.
Surely some people that just want Java with closures will not move to Scala anymore. Some people that moved because they wanted a better Java, may move back to Java, because Scala is actually painful when used as a better Java. But Scala will thrive, as it's a very well designed language that achieves the best combination between OOP and FP available.
In fact Java 8 is good news for Scala, because of the JVM improvements and because Java developers will be more comfortable in consuming libraries built with Scala, like Play and Akka. This is extremely good news, because with the Java ecosystem being so massive, Scala will gain more users than it will lose once people start seeing the possibilities.
One great thing about these new language features is that you don't have to use them. You can run on jdk8 and program as if it was your grandmas vm. This was true for generics and will be true for lambdas etc. As programmers become more advanced they understand the need for the more advanced features and start to adopt them - but they are not strictly required from the start.
To be fair, Java's generics are so awfully implemented that I stay away from them as much as I can - i.e. invariant, with use-site variance notations by means of existential types and freaking wildcards (instead of declaration-site like how Scala does it, which is much saner).
And I'm not even ranting about the generics being based on type-erasure, like so many other people are doing. Type-erasure is actually one of the best features of Java, since reification implies doing damage in the runtime which would have impacted other languages and with a good type system, you wouldn't need reification anyway.
In Haskell, typeclasses are special-cased and you can only have one implementation for a given type. In Scala, typeclasses arise naturally as a pattern out of more primitive building blocks, and are "just another type" that you can pass around and manipulate in ordinary ways.
I used Scala at my previous startup, but for my new startup I decided to build the backend in Java 8. Biggest reasons were the tooling/IDE is just miserable in Scala and the lack of developers in the market. I am really happy with my decision to build our backend with Java 8, quite a joy to write lambda expressions and have the tooling of Java.
I mean, the title is kind of link-baity. But the article even answers the question:
"What about type inference, traits, vals, implicits, case classes, value classes, static objects, pattern matching, type variance, macros, immutable datatypes, lazy vals, existential types, higher-kinded types, type classes."
Scala is a lot more than lambdas. For one thing, Groovy also has lambdas. They weren't remotely unique to Scala. The real power of Scala comes from other things, like how you can use the combination of case classes and the builtin data extracting pattern matchers to easily pass complex messages around. That is something special.
Lambdas are dead common. They're in practically every language other than Java, and now finally even Java has them. It's good that Java now gets them too, but if that was enough to kill Scala, then Scala wouldn't have been anything special.
Maybe using OCAML as a base for F# was a smart move. It seems C# and F# will be more different than Java and Scala. Yet F# is not different enough to justify the move in many cases.
Java is necessarily very conservative with adopting language features, because it is very careful to maintain backwards compatibility. Java is a bit like Debian stable - out of date compared to Debian testing or even other distros - but solid as a rock. For features to make it into Java, they really need to be proved first in other languages or in external libraries.
This isn't the first time Odersky has advanced Java either - he worked on Pizza, which showed how to add Generics to Java. Scala demonstrates how to add functional features to Java. Generics were a huge advance, and I think lambdas will be as consequential.
So if Scala does die, it will be as a sacrificial lamb, rather than as a casualty of an unseen war.