Using Scala as a Junior Developer

Predictability

In functional programming, the result of a method only depends on the arguments passed to it, regardless of the state of the program. This helps to decouple the code, making it easier to test, maintain, and debug. For instance, let’s say we want to add 1 to all the elements of a list:

// result depends on the argument
var list = List(1, 2, 3)
def add1ToAll(l: List[Int]): List[Int] = l.map(x => x + 1)
add1ToAll(list) // List(2, 3, 4)
list = List(2, 3, 4)
add1ToAll(list) // List(3, 4, 5)

With this functional programming compliant implementation, I can predict the result without even computing it, because it depends only on the list I feed it with. I could even replace the function call with its result, and it would still work as expected.

However, if I do not comply with functional programming principles, I can’t be sure of the result without computing it, because it does not depend on the input anymore, but on the state of the program, which can change at any time:

// result depends on the state of the program
var list = List(1, 2, 3)
def add1ToAll(): List[Int] = list.map(x => x + 1)
add1ToAll() // List(2, 3, 4)
// list is changed somewhere else in the program
add1ToAll() // List(3, 4, 5)

Because we have side effects, it’s hard to tell what the behavior of the program is (what it does and in which cases), which can lead to an incorrect reading of the code and to bugs. That’s another benefit of the functional programming approach: it is easier to reason about the code. We can have “local” reasoning, meaning that we can operate on a scope without having to worry about the rest of the program:

// non-local reasoning
var mutableThing = ???
def smallSpaghetti() =
  if mutableThing == ??? then // do something
  else // do something else

Here I need to understand what is mutableThing, when and where it is modified to understand what the method does. This is not the case in functional programming, where we can have local reasoning:

// local reasoning
def complicateMethod(mutableThing: Any) =
  if mutableThing == ??? then // do something
  else // do something else

Readability and Reusability

Being able to pass functions as arguments, and to return functions, helps to write more generic (thus reusable) code, and to focus more on the algorithm itself, rather than the implementation details. For instance, let’s say we want to transform a collection. In FP, all we need to do is define a method that takes a transformation function as argument, and apply it to the collection. Then the developer can choose the transformation function they want to apply, and the method will do the rest. An example with a simple map method:

// FP-style
class MyArray[A](size: Int) {
  private val container = ???
  // ...
  def map[B](f: A => B): MyArray[B] = ???
}

MyArray(1, 2, 3).map(x => x + 1) // MyArray(2, 3, 4)
MyArray("a", "b", "c").map(x => x + "z") // MyArray("az", "bz", "cz")

You can find a complete example in the Scala Essential Courses

You could ask, “why would I use map when I can use loops ?”. Well, for each transformation, we need to manually initialize a new collection, iterate over the original one, and then apply the transformation to each element. This is not only more code, but it’s also less readable (we need to read the entire block to understand it).

// imperative-style
def add1ToAll(list: List[Int]): List[Int] = {
  var newList = List[Int]()
  for (i <- 0 until list.length)
    newList = newList :+ list(i) + 1
  newList
}
def addZToAll(list: List[String]): List[String] = {
  var newList = List[String]()
  for (i <- 0 until list.length)
    newList = newList :+ list(i) + "z"
  newList
}
add1ToAll(List(1, 2, 3)) // List(2, 3, 4)
addZToAll(List("a", "b", "c")) // List("az", "bz", "cz")

Type System and Type Inference

Scala has a very powerful type system that allows us to express very complex types while keeping the code readable. However, sometimes we can end up with veeeery long type names, which can be a bit annoying. But since Scala has a very powerful type inference system, we can write code without having to specify the type of every variable (the compiler will determine it for us). This is very useful as we do not pollute the code with types while keeping the safety they provide.

val x = 1                     // x: Int = 1
val list = List(1, 1, 2)      // list: List[Int] = List(1, 1, 2)
val str = list.mkString(", ") // str: String = 1, 1, 2
val longThing =               // longThing: Int = 10
  List(1, 2, 3, 4, 5)
    .map(0 until _)
    .filter(_.sum > 8)
    .flatten
    .sum
// same but without type inference
val longUglyThing: Int =
  List[Int](1, 2, 3, 4, 5)
    .map((x: Int) => 0 until x)
    .filter((r: Range) => r.sum > 8)
    .flatten
    .sum

You can activate an option in Metals (a scala language server for IDEs) to show the inferred types as a decoration in the editor, which I now use most of the time. I recommend the “minimal” setting option because it shows only relevant types (parameters, return types…).

Mix of Object-Oriented Programming and Functional Programming

Scala has been a pioneer in the mixing of these two paradigms and has been (and still is!) an inspiration for many languages. We benefit from the modularity of objects while having the safety and expressivity of functional programming. Also, unlike some other functional languages, it allows the usage of mutable variables, which can lead to performance improvements.

Multi-Platform

Scala can now run on multiple platforms. The main one is the JVM, meaning that it benefits from the Java ecosystem (which is pretty huge) and from a performant long-term runtime environment. And it will get even more performant with the Loom project (lightweight threads).

But it can also run on the browser thanks to the Scala.js project, bringing interoperability with JavaScript. And it can be run as native code (without the JVM) with Scala Native, which can be useful for low-level programming.

Implicits

Implicits are specific values that will be injected by the compiler when they are required (and if they are in available in the current scope). They are very useful to keep a context and not having to write it each time (reduce boilerplate code).

A nice example is with Future. A Future is a value that will be computed asynchronously in a separate thread. To do so, we need a thread manager as the Future only models the value, and we need to pass it each time we create a Future.

import scala.concurrent.ExecutionContext.global // a thread manager

Future(1 + 1)(global)
  .map(_ + 1)(global)
  .flatMap(x => Future(x + 1))(global)

Which is quite cumbersome. But the execution context can be passed implicitly, so we can write:

import scala.concurrent.ExecutionContext.Implicits.global

Future(1 + 1)
  .map(_ + 1)
  .flatMap(x => Future(x + 1))

Which is much more pleasant to read.

Implicits allows to have type classes, which define a generic behavior that is to be implemented with a specific type. It can be seen as a way to automatically extends a type with new behaviors if and only if their corresponding implementations are present in the current scope. It is particularly powerful in library design as it helps in decoupling the code by keeping the core behavior in the class and the “required” behavior in the type class. For instance:

trait Animal
case class Cat(name: String, age: Int) extends Animal
case class Dog(name: String, age: Int) extends Animal

trait InfoExtractor[T]:
  def extractInfo(t: T): String

extension [T <: Animal](t: T) def serialize(using s: InfoExtractor[T]): String = s.extractInfo(t)

given InfoExtractor[Cat] with { def extractInfo(t: Cat) = s"Cat: ${t.name}, ${t.age}" }
given InfoExtractor[Dog] with { def extractInfo(t: Dog) = s"Dog: ${t.name}, ${t.age}" }

val cat = Cat("Scala", 11)
val dog = Dog("Java", 25)

cat.serialize // "Cat: Scala, 11"
dog.serialize // "Dog: Java, 25"

We could use standard interfaces to reproduce type classes, but then we would have to manually pass the implementation each time which has 2 drawbacks:

• It is cumbersome to write and it pollutes the code with “context” arguments (arguments that will always be the same in the current scope)
• When changing the implementation, it must be done everywhere to keep the same behavior and we might forget some places, leading to unexpected behaviors

You can find more about implicits (also called given/using clauses in Scala 3) in this article

But implicits comes with a trade-off: they can be hard to understand at first, and might lead to unexpected behaviors where the wrong implicit is injected. Especially when there are multiple implicits of the same type in the scope (look at the implicit resolution process to avoid this). Still, it is a very powerful feature that helps in making the code more expressive by masking some boilerplates (I know that I’m giving global as execution context, so I don’t want to see it each time).

Conciseness

While having a very robust type system, Scala is not verbose at all. The syntax is very concise and somewhat similar to Python’s syntax. We can even define our own operators with special characters (+, ++, -, +?…) and in infix position (e.g. 1 |& 1 instead of 1.|&(1)), which is so cool to express logic in a readable way.

Lambda syntax can also very concise. For instance:

• We can use placeholders _ in lambdas like .map(_ + 1) instead of .map(x => x + 1). The n-th placeholder is replaced by the n-th argument, so we can write .map(_ + _) instead of .map((x, y) => x + y), but we cannot reuse the same placeholder twice (e.g. .map(_ + _) is not a valid replacement for .map(x => x + x)).
• If the lambda is composed of a single method call whose arguments are the same (same type & order) as the lambda’s arguments, we can define the lambda with only the method name like .map(println) instead of .map(x => println(x)).

Pattern Matching

This is one thing I cannot not talk about. Pattern matching allows to easily control the execution flow based on patterns. A pattern can be almost anything: a type, a value, a destructured object…

sealed trait Pattern
case class Simple(x: Any) extends Pattern
case class Complex(x: Int, s: String, p: Option[Pattern]) extends Pattern

def matchPattern(p: Pattern): Unit = p match {
  case Simple("lulu") => println(s"Simple: lulu")
  case Simple(1 | 2) => println(s"Simple: 1 or 2")
  case Simple(x: Int) if x == 10 => println(s"Simple int: $x")
  case Complex(x, s, None) => println(s"Complex without pattern")
  case _ => println("Other")
}

You can even define your own pattern with an extractor: an object with an unapply method whose argument is the value to match and return type a boolean if you simply want a match or not, or an Option[T] if you want to extract a value of type T from the value to match.

object Even {
  def unapply(x: Int): Boolean = x % 2 == 0
}
object SimpleComplex {
  def unapply(p: Pattern): Option[(Int, String, Option[Pattern])] = p match {
    case Complex(x, s, p @ (None | Some(_: Simple))) => Some((x, s, p))
    case _ => None
  }
}

The @ is used to extract the value from the pattern and bind it to a variable. Now we can use these patterns in our match:

// ...
  case SimpleComplex(x, s, p) => println(s"A complex with a simple pattern or nothing")
  case Simple(Even()) => println(s"Simple even number")
// ...

The pattern matching is exhaustive, meaning that if you forget a case, the compiler will warn you. And if don’t do as he says, he might throw an exception at runtime if it does not find any match. To overcome this, you can use a wildcard pattern _ or a simple variable name without constraint (e.g. case rest => ???) to match anything else.

Also, the matching is done in order, so the first match will be executed. Meaning that the most specific cases must be placed on top of the list, and the most generic ones at the bottom. However, the compiler will warn you if a case is unreachable.

Internship at Teads

In 2021, I started looking at the Scala language, and since I became quite interested in it, I decided to try it in a “real-world” case and look for a company using Scala. This way, I could evaluate my “match” with the language. There was Teads, a company that I knew was intensively using Scala (90% of their backend is Scala). Again, I would like to thank them for giving me a nice opportunity that helped open some doors later.

That’s how I landed on Scala and started going “in depth”. Before the internship, I learned the basics of the language and functional programming, but I was far from using it efficiently. During it, I learned quite a lot: the basics of pure functional programming with the Cats-effect framework, the difference between map and flatMap (which was not easy at first), for-comprehensions, and even a bit about variance…

Once it was finished, I was a little bit frustrated not to have been able to do more, but it motivated me to keep learning Scala. I did this by following both the beginner and advanced courses on Rock The JVM and by doing some puzzles with Scala on CodinGame. Even though I had the initial motivation, I was surprised not to have many difficulties following these video-based courses and keeping a certain rhythm in it (I had lots of difficulties following online courses during the COVID pandemic).

Internship at the Scala Center

As I was moving forward with Scala, I became more and more enthusiast about it, and I wanted to learn more about it. At the same time, I thought of beginning to contribute to open source projects: to learn, help others (even though at this stage it was more learning than helping :smile:), and also for the possibilities open-source can provide. While searching for companies using Scala, a teacher of my school (Polytech Montpellier) in charge of the Scala/FP course told me about the Scala Center, a non-for-profit Scala language foundation, situated in the EPFL (Ecole Polytechnique Fédérale de Lausanne) aiming at promoting the language, contributing to and coordinating its ecosystem (among other things, you can find more details on their 5-year report). It seemed to correspond to what I was looking for, so I applied for an internship there.

And I got accepted for a 5-month internship on the scala implementation of the debugger in VS Code (scala-debug-adapter) ! My job was to create a new evaluation mode that would be faster, allows more expression (access to private members, access to runtime type… since we are in a debug session). There I learnt a huge amount of things about Scala and more general concepts:

• Quick view of how an IDE interacts with build tools (sbt…)
• Compiler concepts (type-checking, overloads resolution…)
• Scala compiler academy (link here)
• Implementation of interoperability with Java in the bytecode
• First steps in open-source contributions
• Meta-programming & code manipulation with scalameta (AST, trees, symbols, tokens…)
• Write more expressive Scala code and my own monad
• Created a video script & slides about asynchronous programming with Future and made some research about Loom as it appears to be a game changer for asynchronous programming on the JVM (and at the same time realized the huge amount a work required to make a single video of 15 min :sweat_smile:)
• …

Next steps

One big default of mine is my shyness. I am not comfortable at all in entering new areas, to the point where I wait for people to come to me instead of going to them. Thankfully, on both of these internships, they all did, so it helped me a lot in integrating with the team. But still, I need to work on it, so I started participating a little bit in the organization of conferences.

A French Scala user Discord server was launched not long ago by some ScalaIO members, and since they were looking for volunteers, I decided to join them after a first experience in conference organization.

I have also had the chance to join the volunteering team of Scala Days Madrid 2023 (co-organized by the Scala Center), thanks to Darja Jovanovic (Executive Director of the Scala Center) who asked if I wanted to and transmitted my request to the organization team, after my school gave me the authorization. I will be hosting a track for the two conference days. I am really looking forward to it but also a bit stressed :upside_down_face:

Personal Difficulties

def method(a: Int, b: Int, c: Int, d: Int): Int = a+d+c+d
val f: (Int, Int) => Int = method(1, 2, _, _)
f(3, 4) // 12
f(5, 6) // 18

def method(a: Int, b: Int): Int => Int =
  if (a > b) (x: Int) => a * x + b
  else (x: Int) => b * x + a

val f1: Int => Int = method(1, 2)
val f2: Int => Int = method(3, 1)
f1(3) // Int = 7
f2(3) // Int = 10

val list = List(1, 2, 3)
val anotherList = list.map(x => x + 1)            // List(2, 3, 4)
val listOfList = list.map(x => List(x, x + 1))    // List(List(1, 2), List(2, 3), List(3, 4))
val flatList = list.flatMap(x => List(x, x + 1))  // List(1, 2, 2, 3, 3, 4)

val anOption = Some(1)
val anotherOption = anOption.map(x => x + 1)           // Some(2)
val optionOfOption = anOption.map(x => Some(x + 1))    // Some(Some(2))
val flatOption = anOption.flatMap(x => Some(x + 1))    // Some(2)

def getA: Option[A] = ???
def getB(a: A): Option[B] = ???

val res: Option[Option[B]] = getA.map(a => getB(a))

val res: Option[B] = getA.flatMap(a => getB(a))

Tips

import scala.util.Random

def byValue(t: Int): Seq[Int] =
  for
    _ <- 0 until 3
  yield t

def byName(t: => Int): Seq[Int] =
  for
    _ <- 0 until 3
  yield t

byValue(Random.nextInt(10000))  // : Seq[Int] = Seq(2551, 2551, 2551)
byName(Random.nextInt(10000))   // : Seq[Int] = Seq(6419, 9607, 1189)

class A(var x: Int) // mutable type

val a = new A(1)
a.x = 2
a.x                 // : Int = 2 <-- no immutability

class A {
  def method: String = if (Random.nextBoolean) then "not null" else null
}
val nullable: A = if (Random.nextBoolean) new A() else null

val res1: A = if (nullable != null) nullable.method else null
val res2: String = if (res1 != null) s"Length: ${res1.size}" else null

val res3: Option[String] =
  for
    res <- Option(nullable)
    str <- Option(res.method)
  yield s"Length: ${str.size}"

@tailrec
def factorial(n: Int): Int =
  if (n == 0) 1
  else n * factorial(n - 1) // error

@tailrec
def factorial(n: Int, acc: Int = 1): Int =
  if (n == 0) acc
  else factorial(n - 1, n * acc) // ok

def factorial(n: Int): Int =
  def loop(n: Int, acc: Int): Int =
    if (n == 0) acc
    else loop(n - 1, n * acc)
  loop(n, 1)

def fiboRC(n: Int): Int =
  if (n <= 1) n
  else fibo(n - 1) + fibo(n - 2)

def fiboTR(n: Int): Int =
  def loop(n: Int, acc1: Int, acc2: Int): Int =
    if (n <= 1) acc1
    else loop(n - 1, acc2, acc1 + acc2)
  loop(n, 0, 1)

def fiboWL(n: Int): Int = {
  var acc1 = 0
  var acc2 = 1
  var i = 0
  while (i < n) {
    val tmp = acc1
    acc1 = acc2
    acc2 = tmp + acc2
    i += 1
  }
  acc1
}

val list1 = List(1, 2, 3)
val list2 = List(4, 5, 6)
val list3 = List(7, 8, 9)

// for-comprehension
for
  i <- list1
  j <- list2
  k <- list3
yield (i, j, k)
// standard way
list1.flatMap: i =>
  list2.flatMap: j =>
    list3.map((i, j, _))

for
  i <- list1
  if i % 2 == 0
  j <- list2
  k <- list3
yield (i, j, k)

list1: i =>
  if i % 2 == 0 then
    list2.flatMap: j =>
      list3.map((i, j, _))
  else Nil

for
  i <- if (condition) then list1 else list2
  j <- list3
yield (i, j)