Should Scala move in the direction of a mainstream language like Java?
Standing out of the crowd image via Shutterstock
In our latest issue of JAX Magazine, we dive deeper into reactive programming and analyze the most popular JVM language and where we are heading to. After talking to Martin Odersky, the creator of Scala, about the 2.12 version and the current state of this programming language, we invited six Scala developers to weigh in on Scala’s appeal and to express their opinion with regard to Scala’s future.
Some people say that after Java 8 introduced lambda expressions, Scala lost a bit of its appeal because functional programming is now also possible directly in Java.
What’s your take on that?
Heiko Seeberger: Java does not become a functional programming language by just adding lamdas. Scala is, by the way, not a pure functional programming language either. You can see that clearly by the way lambdas are embedded into the collection library of the Java Development Kit (JDK): over streams because you cannot work on the alterable collections with functional concepts. It is possible that Java 8 is a “starter drug” for Scala and other functional programming languages because developers can get a first impression of the functional programming concepts, learn to love them and then take a look around to see what else is out there.
Markus Hauck: Functional programming is more than just lambda expressions — they are just a small part of it. It is a completely different way of writing and organizing software. Java and the Java ecosystem are laid out on object-oriented programming so if you want to use functional programming in Java you have to first learn another language to really understand what functional programming even means. Since Scala is pretty good in that regard, why would you switch back to Java?
Daniel Westheide: Lambda expressions do not make a functional programming language. You can code functional in Java 8 but it is not as well-supported. There is no proper support for currying, for example, something that comes along with a worse type inference. A standard library that relies completely on immutable data structures is also a mandatory part of a functional programming language. This is not the case with Java and the surrounding ecosystem. Scala, on the other hand, relies completely on immutable data structures that are also implemented more efficiently in the Scala collections library because of structural sharing. Since all data types and structures are, other than in Java, usually immutable, you can do without expensive defensive copying. Furthermore, Scala provides a lot of tools that just belong to functional programming in a static typing programming language, like Case Classes, For-Comprehensions, Pattern Matching and Type Classes. I would really miss them in Java 8.
Ivan Kusalic: Lambdas are just a tiny part. Java is still a predominately imperative OO language. What about currying, pattern matching, higher kinds, immutability to name a few? It’s a step in the right direction, but without breaking backward compatibility, Java will never be Scala. And that’s ok, they both have their pros. But to say that Java 8 is a functional language is quite misguided in my opinion.
Daniela Sfregola: I don’t think Scala lost its charm after lambda functions were introduced in Java 8. I actually think the opposite! Java is still missing a lot of features that Scala can offer: implicits, for-comprehensions, traits, type inference, case classes, easy currency support, immutable collections….and much more! Introducing lambda expressions in Java 8 is an opportunity for OO developers to start tasting the power of functional programming — before going all the way to the dark force with languages like Scala or Haskell.
Julien Tournay: Lambdas are certainly a feature long awaited by the Java community. While it’s a step forward, it does not make functional programming possible in Java by itself.
A functional programming language, has, at the very least, first class support for immutability. Lambdas make basic functional techniques possible, and I’m very happy to see the Java community being excited about this new world of possibilities but Java is and will probably always be object-oriented above all.
Reactive programming means different things to different people and we are not trying to reinvent the wheel or define this concept. Instead, we are allowing our authors to prove how Scala, Lagom, Spark, Akka and Play coexist and work together to create a reactive universe.
If the definition “stream of events” does not satisfy your thirst for knowledge, get ready to find out what reactive programming means to our experts in Scala, Lagom, Spark, Akka and Play. Plus, we talked to Scala creator Martin Odersky about the impending Scala 2.12, the current state of this programming language and the technical innovations that await us.
Thirsty for more? Open the magazine and see what we have prepared for you.
An entire stack was formed around Scala. How can we define it?
Heiko Seeberger: The Scala ecosystem is very much alive and extensive. An important piece of this “toolbox” is represented by the products of the Lightbend Reactive Platform, especially Akka and Play. This should not be understood as an opposing model to JEE and Spring, but basically as a whole new approach to architecture: Anyone who wants to build systems as defined by the reactive manifest has to use modern tools like Akka, not technologies that still go by the “one thread per request” principle and let a distributed data base handle the distribution.
Markus Hauck: “Building Kit” could be used but it is not “loose”. You can use the parts of the stack individually quite nicely if you do not need the rest. At the same time, you can add parts of it later if you need them. But it is not a collection that fits by chance, there is a common focus that applies to all of them, namely to building reactive systems.
Daniel Westheide: Lagom is —in my opinion— indeed an attempt to offer an opposing model to Java EE and Spring and it addresses Java developers from the Enterprise environment. As of today, there is just a Java API while we are still waiting for a Scala API. The other tools in the stack are more like a loose toolbox.
If you choose Akka as an opposing model to Java EE and Spring, you will come to Event Sourcing and CQRS eventually. With Play in conjunction with Slick for the linking to relational databases, there is an alternative for Java EE and Spring that does not have such a big impact on certain architecture and technology decisions. The SMACK-Stack, consisting of Spark, Mesos, Akka, Cassandra and Kafka is very popular. But I do not look at it as an opposing model to Java EE or Spring because it is built to address a completely different set of problems: Fast Data and Big Data processing.
Ivan Kusalic: My context is not that of the typical CRUD scenarios and enterprise web applications, but of highly distributed systems in the cloud setup. Sometimes even on the DevOps side. I’ve played with the stack and it looks great but I’m only using Akka on a daily basis, so I will leave this question to people who can offer a more informed opinion.
Daniela Sfregola: I do not have much experience with JavaEE or Spring, so I do not feel comfortable comparing them.
Julien Tournay: It’s true that the Scala open-source community is very active. Spark is, of course, a huge driver of Scala’s adoption.
Is this stack an alternative to JEE or Spring ? Well, JEE and Spring are both large ecosystems so yes projects in the Scala ecosystem are competing against projects in the JEE or the Spring ecosystem. The projects developed by Lightbend share a vision of what they think Scala should be. They try to make everything they build usable to Java developers.
For example, you can use Play without writing a single line of Scala code. Of course, there’s a trade-off here. Developing for both languages requires more time. It can also be hard to design an API that is usable by a Java developer, while not impacting the design of its Scala counterpart.
But as Java is not limited to projects developed by Oracle (Spring is an excellent example of that), Scala is not limited to Lightbend’s initiatives either. The work done by Typelevel is especially interesting to me. They’s pulling Scala to more functional ways, and are also building a coherent ecosystem. I think people coming to Scala from a Java background will probably start using Lightbend’s technologies, and move some projects to Typelevel after a few month, once they’ve become comfortable with more functional ideas.
For what kind of applications can we use the stack?
Heiko Seeberger: A stack with Scala and Akka is suitable for every sort of application. Its advantages will not come into play for your personal website but when you need to build a highly available system. One of my favorite examples is Walmart Canada. They used traditional technology to build an online shop which crashed regularly at prior known days with high load peaks. After Walmart Canada switched to Scala, Akka and Play, not only did the outages disappear but they saved some software licensing costs too.
Markus Hauck: This stack is fitted for applications that have to react very fast and / or scale to big amounts of data. At the same time, it is modular enough to give the user the opportunity to choose and use only the parts he really needs.
Daniel Westheide: As I mentioned earlier, I do not see these technologies as a fixed stack — but as individual entities. Akka is ideal for applications where low latency plays a role because you can maintain the current state of the application in memory with Akka Persistence. This may be exciting not only for the IoT environment but also for trading, real-time bidding or multi-player games. When you say Akka Persistence, you also say Event Sourcing so Akka is a good choice for reasons other than latency and Throughput Event Sourcing around an audit log or as intermediate for business intelligence. Akka and Spark in conjunction with Cassandra and Kafka are predestined to implement the Lambda architecture.
Ivan Kusalic: I will have to allow the others to answer this question.
Julien Tournay: I guess Lightbend’s ecosystem is trying to be a reference stack to building distributed applications. There are definitely pretty cool projects in it. I quite like Akka Streams for example. Other than that, Scala is as general as Java. You can pretty much build anything :)
Check out our Scala expert checklist
Should Scala move more in the direction of a mainstream language like Java in the future?
Heiko Seeberger: What’s interesting is that the story about the missing compatibility continues to exist. Scala has been —since version 2.9 so since 2011— 100 percent compatible with minor releases. This was not the case previously and it was very annoying. If today comes a major release every two years that eliminates APIs which were marked as @deprecated, then I welcome it. For me, Scala is on the right path since there is still innovation happening even though developers are considerate of compatibility.
Markus Hauck: For me, Scala is and will remain an innovative language. Especially when developing a language in an explorative manner, it is important to let failures go, which Scala handled just fine in the past. Backward compatibility plays an important role as far as I’m concerned but not at any price.
Daniel Westheide: I think the current pace is quite ok. The times in which we had to face incompatible changes are behind us. The fact that Scala has spread over the past few years, even into big and traditional organizations, shows that backward compatibility is doing sufficiently well. Those who want more and faster innovation have the choice to access Scala’s Typelevel fork.
Ivan Kusalic: I, of course, want both. At this point more and more companies are using Scala, so backward compatibility becomes more important. This is not a reason for the language to stop evolving, though. There is hopefully a sweet spot somewhere on the spectrum between past Scala behavior and too conservative Java evolution.
Daniela Sfregola: I think Scala should do both! For any language, being widely used and having a good open source community that supports it is extremely important: the more the language is popular the easier this is going to happen, so attention to backward compatibility between different versions is something important to keep in mind. However, I also think that if the community is asking for a breaking change or new innovative features, breaking the compatibility with previous versions is a valid choice to keep the language alive and fun to work with.
Julien Tournay: That’s again a hard question to answer. Backward compatibility is extremely important, and one should be warry to break it at a language level. The Python community has been learning this the hard way since the release of Python 3, which after all these years, has failed to replace Python 2. Overall I hope the Scala language will continue to evolve and improve. I follow the work Dotty (the next major version of Scala) with a lot of interest.