Java had been the first language that I learnt, had professional experience in and so, kind of had an emotional connect with. It was only when my project required Scala knowledge along with Java that I started learning this beautiful language that contains the features of different languages like C, C++, Java etc. which makes it so much useful, scalable and productive. It teaches you so much about how to solve problems using different programming paradigms. Functional? Got that. Imperative? That too. Want the compiler to check your work? It’s got one of the strongest type systems around. Want to wing it? Compiler will believe you if you tell it you know what you’re doing.
Scala is a language that seems to have learned from the pain points of other languages, and proposes to solve some of them. It does a pretty good job at removing verbosity (like by inferring datatype on its own) and removing boilerplate code to an extent.
WHO ARE USING SCALA?
INTRODUCING SCALA, THE LANGUAGE
Scala lets you write code in an object-oriented programming (OOP) style, a functional programming (FP) style, and even in a hybrid style, using both approaches in combination.
Where Java makes developers write a lot of boiler code everyday including constructors, getters, variable initialization, semicolons and many others, Scala relieves them from this plight. The following example would illustrate more:
PARALLEL SCALA CODE:
Functions and Methods
Functions are constructed really easily in Scala:
The call ‘greet(“World”)’ returns Hello, World! as expected. The part before the ‘=’ defines the name of the function, then come its arguments, and after the ‘=>’ you’ll find the function body.
There are methods too:
They’re quite similar to functions, but their syntax is a bit different. An output type needs to be specified, like the Unit (equivalent of Java’s void) in front of the curly braces in this example.
On a more theoretical level, functions are generalization of methods. That’s because methods are always a part of a class. Functions can be part of a class but don’t need to; if they happen to be part of one, they’re called methods instead.
Classes and Objects
Classes in Scala are defined as follows:
Then you can define an instance of that class in the following way:
Objects in Scala are instances of their own definitions:
Unlike classes, they can’t take any parameters. They do return things though (last statement of a method is return statement, return keyword is not required), when you call their methods:
Exception handling in Scala
Though exceptions can be handled in Scala the way they are handled in Java, by using try/catch/throw, a Scala idiom is to use the Option/Some/None pattern instead. While using Option (Java equivalent of Optional) is generally a much better approach, one weakness of this approach is that the Option/Some/None doesn’t tell you why something failed, that is, why you got a None instead of a Some.
To overcome this drawback, you can use Either/Left/Right instead. Either works just like Option, with a difference being that with Either you can return a String that describes the problem that occurred (wrapped inside Left). Actually, you can return anything you want inside Left, though returning information about the problem is generally the intention. Right mostly contains response in case of successful execution without any problem.
In order to test Scala code, one can use conventional Junit tool popular in Java or if one wants more of Behaviour Driven Development, then ScalaTest can be used. In ScalaTest, you define tests inside classes that extend a style class such as FlatSpec.
Build tool for Scala
sbt is the most commonly used and first build tool that was specifically created for Scala.
Like Maven, sbt uses a standard project directory structure which looks like following:
For a simple little project, the build.sbt file only needs to contain a few lines, like this:
Use the sbt run command to compile and run your project.
OVERVIEW OF EXPERIENCE WITH SCALA
The application that I worked on was developed in both Scala and Java. Scala code handled the core logic of the application which required dealing with huge amount of data and Java was majorly used to integrate with third party APIs.
Interaction between Scala and Java were handled by:
- using a queue between Scala and Java application.
- API calls through HTTP.
- direct library calls.
Queue was used for asynchronous interaction that did not require an immediate response (like sending emails).
API calls were used where quick response was required without tight coupling. Most of the interaction between Scala and Java fell into this category.
Direct library call, though used at places, made the two system tightly coupled and development somewhat difficult and tedious. Besides, it was harder to manage database transactions using this since Scala was using Slick and Java was using Hibernate.
- 7 to 10 times less code (because of type inference, less boilerplate code, functional programming, traits)
- Easier to code for concurrency (through immutability, actors as well as the internal parallelism supported by functional programming model)
- It’s easy to invoke java code from Scala code and vice versa.
- Since Scala is written on top of JVM, it’s pretty mature platform
- It is easy to get started with Scala but it takes a long time to get a decent grip of the important features and become very productive
- Scala community is small and so hiring a Scala engineer is not easy. In-job training seems to be the main path to growth.
- Scala IDE plugin for eclipse is still in the making and has some limitations
- New features in latest Java negates some of Scala’s advantages that used to be exclusive to it.
References and useful links: