at the same time having access to the JVM ecosystem of libraries and frameworks.
The richer the type system (Scala’s type system is richer than Kotlin’s, which in turn is richer than Java’s), the more of the verification work is done by the compiler, instead of relying on human labor. And that’s what computers are made for: to perform the boring, mundane, repetitive tasks. Verifying that types match is definitely one such task.
But, a rich type system is not only useful when writing the code, even more so when reading the code. Being able to navigate a codebase, understand what it is doing and refactor with no (or less) fear are very important traits of a language, both from technical and business perspectives.
Another point that is often raised in the discussion is whether Scala should continue on the path of a fusion OO/FP language or going only the FP route. I’m on the fusion side, especially that FP and OO aren’t alternatives, but are complementary to each other.
FP is programming with functions, though not any functions — only such, which are referentially transparent (see this reddit answer, in a previously linked thread, which is a great explanation of referential transparency). OO is communicating with objects using “messages”, or in our terminology, virtual method calls. There’s no reason why these two approaches can’t live together, as Scala has already shown!
In a tweet about the good sides of Scala, John de Goes mentioned some of the OO features which are useful in the purely-functional approach as well: first-class modules (via object composition), dot syntax (calling methods on objects) and first-class type classes/instances, among others. These are all elements of a successful combination of the two concepts. Maybe there are more on the horizon?
The “fusion” isn’t a finished project, there’s definitely room for discussions. One area for example is the proposed syntax for extension methods, which replaces much of the more confusing implicit conversion usages. Another is a better syntax for type classes; the proposal from some time ago falls short and doesn’t address some of the most common usages of monads in Scala. Some proposals are better, others need work, but it’s good that they are coming, and good that there are discussions around them; this helps to keep the language alive and ultimately arrive at the best solution.
What we know now, is that there will be a tool to automatically migrate code from Scala 2 to Scala 3, using scalafix. As Scala is a statically typed language, that’s a task that can be done on large scale and is much easier than e.g. in the case of Python. But of course there’s no magic: even if the tool will convert 99% of the code correctly, there’s still the 1% that is most problematic. And because there’s no magic, manual effort will be required to migrate these fragments.
That’s the cost of using an actively developed language: you get the latest features, but then some of them turn out to be not so good and need to be adjusted. Even having that in mind, the changes aren’t revolutionary. Scala 3 is a very similar language to Scala 2, without major paradigm shifts.
One reassuring fact is that the Scala team is taking the migration seriously. While previously migrating within major Scala versions (e.g. 2.8 to 2.9) was quite painful, recent migrations were much better. There are three parties involved: EPFL, ScalaCenter
, and each of them works (often together) to make the migrations smoother. For example, there’s the binary-compatibility MIMA tool
, and a large number of community libraries are continuously built
to make sure that they work with new Scala versions.
Finally, while not yet done (so not possible to verify), TASTY is supposed to enable using binaries from Scala 2 in Scala 3.
Hence, while migration is going to be a problem — as with all migrations — I’m quite confident that it will be seriously taken into account by the people who work on Scala.
So why use Scala?
What are the business reasons to use Scala, then? All of the above mentioned technical advantages translate directly to business advantages. Having a language which helps write complex code with less bugs is less downtime and happier users. Writing highly concurrent, low-latency applications with the help of one of the Scala concurrency toolkits means bigger profits for the company.
And let’s not forget Spark: the leading platform for distributed data analysis. Scala is not only used to implement Spark, but also to define the computations themselves, providing one more example of a data-scientist-friendly abstraction hiding a complex computational model.
We have our problems of course, but then, who doesn’t? The good news is that there’s an active effort of a large number of people using Scala daily to improve the tooling, libraries and the language itself. And I can only assume that they are sticking to Scala because even though it’s far from perfect, there’s nothing better for their problem domain.
Scala allows you to evolve your programming style, whether coming from Java, Ruby, or just starting with programming. There’s no one good way to do Scala; you can go with the more imperative approach of Akka, or the more functional approach of Cats and Scalaz.
What could seem to be a problem: sub-communities centered around “reactive”, “fused” OO/FP and pure-FP programming, is in fact a huge advantage. This diversity causes discussions to receive a lot of varying opinions, from different points of view. This, in turn, is great for learning how to approach solving problems differently, and enriching one’s own toolbox.
Whichever direction you go in Scala, there’s quite a substantial community working on the development of the libraries and frameworks, happy to help new users and discuss ideas.'
This article was written by Adam Warski and posted originally on blog.softwaremill.com