scala

Tutorials about the Scala programming language.

The Scala 3 “Dotty” procedure syntax

As a note to self, the Scala 3 “Dotty” procedure syntax is going to look like this:

def f() = { ... }
def f(): Unit = { ... }

This Scala 2 procedure syntax is being dropped:

def f() { ... }

You can find the official Dotty procedure syntax page at this link.

As for me, I’m adding this page right now because I noticed today that this procedure syntax (without the parentheses) also works with Dotty:

How to create a Scala 3 (Dotty) project with SBT

I can never remember how to create a Scala 3 (Dotty) project with SBT (in early 2019), so:

# create a new Dotty project
sbt new lampepfl/dotty.g8

# create a dotty project that cross compiles with scala 2
sbt new lampepfl/dotty-cross.g8

# start a dotty reply from within your sbt project
$ sbt

> console
scala> _

More information: dotty.epfl.ch/docs/usage/getting-started.html

A good reason to use sealed traits and classes in Scala

This scala-lang.org documentation page shares a good reason to use “sealed” traits and classes: When you created sealed traits, the compiler can easily tell all of the subtypes of your class or trait, and as just one benefit, you don’t need to add a default, “catch-all” case in your Scala match expressions.

Debate about making Scala classes final by default

contributors.scala-lang.org has become my favorite website this past week. It’s very interesting to read through the debates about new language features for Scala 3 (Dotty). For instance, in the Make concrete classes final by default discussion I think everyone agrees they wish they had gone that way with Scala 2, but it would cause too many problems if they tried to make this a new standard in Scala 3. The discussion — in addition to reading Effective Java — makes me wish I had used final before all of my classes.

In another discussion titled, Why does Scala need its own build tool (SBT), someone makes a claim that Martin Odersky and his team created SBT as a build tool solution, and Mr. Odersky replies, “Definitely not my answer. I was always very skeptical of SBT’s approach and remain so.”

Bloop’s compiler performance is ~29% faster than SBT (on at least one project)

I had read that Bloop was faster than Scala compiler tools like scalac and fsc, so I wondered if it was faster than SBT, and if so, how much faster. So I downloaded Eric Torreborre’s specs2 source code, which has 880 source code files, and compiled the entire project with both SBT and Bloop.

SBT performance

To test SBT’s speed, I ran all the commands from inside the SBT command prompt, which I usually do anyway to avoid the SBT/JVM startup lag time. I also ran clean and compile several times before recording SBT’s speed, because I thought that would be a better reflection of real-world usage and performance. I ran the tests four times, and the average time with SBT was 49 seconds, and that was very consistent, always coming in between 48 and 50 seconds.

Bloop performance