Scala runs...

  • on the JVM
  • on JavaScript in your browser
  • natively with LLVM beta

Scala in a Nutshell

click the boxes below to see Scala in action!

Seamless Java Interop

Scala runs on the JVM, so Java and Scala stacks can be freely mixed for totally seamless integration.

Type Inference

So the type system doesn’t feel so static. Don’t work for the type system. Let the type system work for you!

Concurrency & Distribution

Use data-parallel operations on collections, use actors for concurrency and distribution, or futures for asynchronous programming.

Author.scala
class Author(val firstName: String,
    val lastName: String) extends Comparable[Author] {

  override def compareTo(that: Author) = {
    val lastNameComp = this.lastName compareTo that.lastName
    if (lastNameComp != 0) lastNameComp
    else this.firstName compareTo that.firstName
  }
}

object Author {
  def loadAuthorsFromFile(file: java.io.File): List[Author] = ???
}
App.java
import static scala.collection.JavaConversions.asJavaCollection;

public class App {
    public List<Author> loadAuthorsFromFile(File file) {
        return new ArrayList<Author>(asJavaCollection(
            Author.loadAuthorsFromFile(file)));
    }

    public void sortAuthors(List<Author> authors) {
        Collections.sort(authors);
    }

    public void displaySortedAuthors(File file) {
        List<Author> authors = loadAuthorsFromFile(file);
        sortAuthors(authors);
        for (Author author : authors) {
            System.out.println(
                author.lastName() + ", " + author.firstName());
        }
    }
}

Combine Scala and Java seamlessly

Scala classes are ultimately JVM classes. You can create Java objects, call their methods and inherit from Java classes transparently from Scala. Similarly, Java code can reference Scala classes and objects.


In this example, the Scala class Author implements the Java interface Comparable<T> and works with Java Files. The Java code uses a method from the companion object Author, and accesses fields of the Author class. It also uses JavaConversions to convert between Scala collections and Java collections.

Type inference
scala> class Person(val name: String, val age: Int) {
     |   override def toString = s"$name ($age)"
     | }
defined class Person

scala> def underagePeopleNames(persons: List[Person]) = {
     |   for (person <- persons; if person.age < 18)
     |     yield person.name
     | }
underagePeopleNames: (persons: List[Person])List[String]

scala> def createRandomPeople() = {
     |   val names = List("Alice", "Bob", "Carol",
     |       "Dave", "Eve", "Frank")
     |   for (name <- names) yield {
     |     val age = (Random.nextGaussian()*8 + 20).toInt
     |     new Person(name, age)
     |   }
     | }
createRandomPeople: ()List[Person]

scala> val people = createRandomPeople()
people: List[Person] = List(Alice (16), Bob (16), Carol (19), Dave (18), Eve (26), Frank (11))

scala> underagePeopleNames(people)
res1: List[String] = List(Alice, Bob, Frank)

Let the compiler figure out the types for you

The Scala compiler is smart about static types. Most of the time, you need not tell it the types of your variables. Instead, its powerful type inference will figure them out for you.

In this interactive REPL session (Read-Eval-Print-Loop), we define a class and two functions. You can observe that the compiler infers the result types of the functions automatically, as well as all the intermediate values.

Concurrent/Distributed
val x = Future { someExpensiveComputation() }
val y = Future { someOtherExpensiveComputation() }
val z = for (a <- x; b <- y) yield a*b
for (c <- z) println("Result: " + c)
println("Meanwhile, the main thread goes on!")

Go Concurrent or Distributed with Futures & Promises

In Scala, futures and promises can be used to process data asynchronously, making it easier to parallelize or even distribute your application.

In this example, the Future{} construct evaluates its argument asynchronously, and returns a handle to the asynchronous result as a Future[Int]. For-comprehensions can be used to register new callbacks (to post new things to do) when the future is completed, i.e., when the computation is finished. And since all this is executed asynchronously, without blocking, the main program thread can continue doing other work in the meantime.

Traits

Combine the flexibility of Java-style interfaces with the power of classes. Think principled multiple-inheritance.

Pattern Matching

Think “switch” on steroids. Match against class hierarchies, sequences, and more.

Higher-order functions

Functions are first-class objects. Compose them with guaranteed type safety. Use them anywhere, pass them to anything.

Traits
abstract class Spacecraft {
  def engage(): Unit
}
trait CommandoBridge extends Spacecraft {
  def engage(): Unit = {
    for (_ <- 1 to 3)
      speedUp()
  }
  def speedUp(): Unit
}
trait PulseEngine extends Spacecraft {
  val maxPulse: Int
  var currentPulse: Int = 0
  def speedUp(): Unit = {
    if (currentPulse < maxPulse)
      currentPulse += 1
  }
}
class StarCruiser extends Spacecraft
                     with CommandoBridge
                     with PulseEngine {
  val maxPulse = 200
}

Flexibly Combine Interface & Behavior

In Scala, multiple traits can be mixed into a class to combine their interface and their behavior.

Here, a StarCruiser is a Spacecraft with a CommandoBridge that knows how to engage the ship (provided a means to speed up) and a PulseEngine that specifies how to speed up.

Switch on the structure of your data

In Scala, case classes are used to represent structural data types. They implicitly equip the class with meaningful toString, equals and hashCode methods, as well as the ability to be deconstructed with pattern matching.


In this example, we define a small set of case classes that represent binary trees of integers (the generic version is omitted for simplicity here). In inOrder, the match construct chooses the right branch, depending on the type of t, and at the same time deconstructs the arguments of a Node.

Pattern matching
// Define a set of case classes for representing binary trees.
sealed abstract class Tree
case class Node(elem: Int, left: Tree, right: Tree) extends Tree
case object Leaf extends Tree

// Return the in-order traversal sequence of a given tree.
def inOrder(t: Tree): List[Int] = t match {
  case Node(e, l, r) => inOrder(l) ::: List(e) ::: inOrder(r)
  case Leaf          => List()
}

Go Functional with Higher-Order Functions

In Scala, functions are values, and can be defined as anonymous functions with a concise syntax.

Scala
val people: Array[Person]

// Partition `people` into two arrays `minors` and `adults`.
// Use the anonymous function `(_.age < 18)` as a predicate for partitioning.
val (minors, adults) = people partition (_.age < 18)
Java
List<Person> people;

List<Person> minors = new ArrayList<Person>(people.size());
List<Person> adults = new ArrayList<Person>(people.size());
for (Person person : people) {
    if (person.getAge() < 18)
        minors.add(person);
    else
        adults.add(person);
}

Run Scala in your browser

Scastie is Scala + sbt in your browser! You can use any version of Scala, or even alternate backends such as Dotty, Scala.js, Scala Native, and Typelevel Scala. You can use any published library. You can save and share Scala programs/builds with anybody.

Run Scala code interactively

Online Courses

Functional Programming Principles in Scala

  • Free (optional paid certificate)
  • New sessions starting every 2 weeks!

Functional Program Design in Scala

  • Free (optional paid certificate)
  • New sessions starting every 2 weeks!

Parallel Programming

  • Free (optional paid certificate)
  • New sessions starting every 2 weeks!

Big Data Analysis with Scala and Spark

  • Free (optional paid certificate)
  • New sessions starting every 2 weeks!

Functional Programming in Scala Capstone

  • Free (optional paid certificate)
  • New sessions starting every 2 weeks!

Programming Reactive Systems

  • Free (optional paid certificate)
  • New sessions starting every 2 weeks!

Upcoming Training

Scala ecosystem

The Scala Library Index (or Scaladex) is a representation of a map of all published Scala libraries. With Scaladex, a developer can now query more than 175,000 releases of Scala libraries. Scaladex is officially supported by Scala Center.

The Scala Library Index

What’s New

BLOG

Scala 3 in sbt 1.5

Thursday, April 8, 2021

We are delighted to announce that sbt 1.5.0 supports Scala 3 out-of-the-box.

From the sbt user viewpoint, Scala 3 is just another Scala version, since every default task and setting works the same.

Yet Scala 3 changes the picture of compatibility in the ecosystem and is going to change our way of dealing with Scala versions and library dependencies. That new reality is reflected in sbt by the scalaBinaryVersion setting and by the new CrossVersion.for3Use2_13 and CrossVersion.for2_13Use3.

Scala 3 early adopters, we encourage you to jump to sbt 1.5.0 and to drop the soon-to-be deprecated sbt-dotty plugin.

Just another Scala version

Using Scala 3 in sbt is as short as:

// project/build.properties
sbt.version=1.5.0
// build.sbt
ThisBuild / scalaVersion := "3.0.0-RC2"

All the default tasks and settings are supported. You can manage dependencies, compile, test, run, package and publish your program or library.

Most sbt plugins should work the same, as long as they do not rely on a Scala 2 compiler plugin or a Scala 2-specific option.

The doc tasks

On a Scala 3 project, the doc task invokes the new Scaladoc tool which uses TASTy files to generate the documentation.

For your own curiosity, you can run the show tastyFiles command to see the TASTy files of your Scala 3 project.

Porting a Scala 2 project

You can change the scalaVersion of your project or you can add Scala 3 to the crossScalaVersions setting.

crossScalaVersions := Seq("2.13.5", "3.0.0-RC2")

It is likely that you need to upgrade some dependencies, to change some compiler options or to remove some compiler plugins. Read the Scala 3 migration tutorial to learn more about those steps.

A new compatibility era

Scala 3 introduces TASTy, an intermediate representation of Scala programs, that is designed for stability during the lifetime of Scala 3. The current state of TASTy makes us confident that all Scala 3 minor versions are going to be backward binary compatible. Thus we will be able to apply the Semantic Versioning scheme to the Scala compiler.

Concretely it means your Scala 3.x project can depend on libraries compiled with Scala 3.y, where y is lower or equal to x.

This is materialized in sbt by the scalaBinaryVersion setting which is set to “3” on all Scala 3 versions (starting from 3.0.0).

Let’s take an example:

// build.sbt
lazy val hello = project.in(file("."))
  .settings(
    scalaVersion := "3.0.0",
    libraryDependencies += "org.typelevel" %% "cats-core" % "x.y.z"
  )

We can print the scalaBinaryVersion:

sbt:hello> show hello / scalaBinaryVersion
[info] 3

As a consequence, the cats-core dependency will be resolved to cats-core_3.

If I bump the scalaVersion to 3.1.0, then the exact same cats-core_3 artifact will be used and it will still be compatible.

Suppose now that I publish the project as a library, it will be published as hello_3 and be available for all projects whose Scala version is greater than 3.1.0.

This is good news for Scala 3 library maintainers, who will not be pressured to release for the latest Scala 3.x version.

For application developers it allows you to use the most recent Scala 3.x version, without worrying about the availability of your dependencies.

A smooth transition

While the state described above is an undeniable improvement, it does not make the transition from Scala 2.13 to Scala 3 easier. Yet we claim this transition will be smoother than ever thanks to the interoperability between the two versions of the language.

Disclaimer for library maintainers

Using the interoperability between Scala 2.13 and Scala 3 in a published library is generally not safe for your end-users. Unless you know exactly what you are doing, it is discouraged to publish a Scala 3 library that depends on a Scala 2.13 library (the scala-library being excluded) or vice versa. The reason is to prevent library users from ending up with two conflicting versions foo_2.13 and foo_3 of the same foo library in their classpath, this problem being unsolvable in some cases.

Using Scala 2.13 libraries in Scala 3

The Scala 3 compiler is able to type check Scala 2.13 types and to resolve Scala 2.13 implicits. It means you can safely use Scala 2.13 libraries in a Scala 3 application.

This feature has been extensively tested in the Scala 3 community build for more than a year. It is now natively available in sbt by using CrossVersion.for3Use2_13:

// build.sbt
lazy val hello = project.in(file("."))
  .serttings(
    scalaVersion := "3.0.0-RC2",
    libraryDependencies +=
      ("org.typelevel" %% "cats-core" % "x.y.z").cross(CrossVersion.for3Use2_13)
  )

Here sbt resolves cats-core_2.13 instead of cats-core_3 (or more precisely cats-core_3.0.0-RC2), and it can compile and run the project successfully.

The story is different for macros since the Scala 3 compiler cannot expand a Scala 2.13 macro. If you run into this case the compiler will clearly state that it is not possible.

Use Scala 3 libraries in Scala 2.13

Conversely, the Scala 2.13 compiler is able to type check most Scala 3 types (not the most exotic ones such as match types) and to resolve Scala 3 given instances.

This is made possible by the Scala 2.13 TASTy reader, contributed by Jamie Thompson at the Scala Center. You can learn about it in the Forward Compatibility article.

The TASTy reader was introduced in 2.13.4 and is still an experimental feature. You can enable it with the -Ytasty-reader compiler option.

In a Scala 2.13 project, you can declare a Scala 3 dependency using CrossVersion.for2_13Use3:

// build.sbt
lazy val hello = project.in(file("."))
  .settings(
    scalaVersion := "2.13.5",
    scalacOptions += "-Ytasty-reader",
    libraryDependencies +=
      ("org.typelevel" %% "cats-core" % "x.y.z").cross(CrossVersion.for2_13Use3)
  )

Notice here that sbt will try to resolve cats-core_3, which does not exist at the time of writing. But you can try the TASTy reader on cats-core_3.0.0-RC1 by setting:

libraryDependencies += "org.typelevel" % "cats-core_3.0.0-RC1" % "x.y.z"

The macro story is the same here: the Scala 2.13 compiler cannot expand a Scala 3 macro.

The sandwich pattern

During the transition from 2.13 to 3, you can have a Scala 3 module layered in between two Scala 2.13 modules.

The sandwich pattern

lazy val main = project.in(file("main"))
  .settings(
    scalaVersion := "2.13.5",
    scalacOptions += "-Ytasty-reader"
  )
  .dependsOn(middle)

lazy val middle = project.in(file("middle"))
  .settings(scalaVersion := "3.0.0")
  .dependsOn(core)

lazy val core = project.in(file("core"))
  .settings(scalaVersion := "2.13.5")

Here the classpath of the main application contains the Scala 3 compiled classes of the middle module which itself depends on the Scala 2.13 classes of the core module.

Such a thing is possible as long as all modules depend on the same binary artifacts of their library dependencies. Having foo_2.13 and foo_3, for some library foo, under the same classpath is fraught with problems and it won’t be permitted by sbt resolvers.

This example shows that it is possible to migrate a big Scala application one module at a time, while running the tests continuously to progress confidently.

The inverted sandwich, with 2.13 being in the middle, is also possible.

FAQ

What about incremental compilation?

Scala 3 is compatible with Zinc, the Scala incremental compiler. We benefit from incremental compilation in sbt out-of-the-box.

What about Scala.js?

The Scala.js plugin version 1.5.0 is already compatible with Scala 3 and sbt 1.5.

You can also use for3Use2_13 and for2_13Use3 in a Scala.js project.

// project/plugins.sbt
addSbtPlugin("org.scala-js" % "sbt-scalajs" % "1.5.0")
// build.sbt
lazy val hello = project.in(file("."))
  .enablePlugins(ScalaJSPlugin)
  .settings(
    scalaVersion := "3.0.0-RC2",
    libraryDependencies +=
      ("org.typelevel" %%% "cats-core" % "x.y.z").cross(CrossVersion.for3Use2_13)
  )

Here sbt resolves the cats-core_sjs1_2.13 artifact.

What about Scala Native?

Scala Native is not yet compatible with Scala 3.

Wrapping up

Using Scala 3 in sbt 1.5.0 is simpler than ever. It is supported out-of-the-box and should interact well with the existing plugins of the sbt ecosystem.

With Scala 3.0.0-RC2, the second release candidate before the final version, you can give Scala 3 a try, experiment with the new features and test the interoperability with Scala 2.13 both ways.

Twitter Feed

See more tweets, or

Follow Scala on twitter

The Scala language is maintained by

  • Scala Center
  • Lightbend

Scala Center is supported by

EPFL Goldman Sachs 47 Degrees Twitter Spotify Lunatech VirtusLab Your company