Scala runs on...

  • JVM
  • 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 higher-order 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);
}
Learn More

or visit the Scala Documentation

IDEs for Scala

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.

Learn More
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!

Upcoming Training

See more training or add one to our feed

Upcoming Events

Scala Days (North America)

Scala Days (North America)

  • New York, NY, USA
  • 19 Jun 2018 - 21 Jun 2018
Scalapeño

Scalapeño

  • Beersheba, Israel
  • 02 Jul 2018
Curry On

Curry On

  • Amsterdam, The Netherlands
  • 16 Jul 2018 - 17 Jul 2018
Scalawave

Scalawave

  • Gdańsk, Poland
  • 06 Sep 2018 - 08 Sep 2018
Scala Italy

Scala Italy

  • Florence, Italy
  • 14 Sep 2018 - 15 Sep 2018
Lambda World

Lambda World

  • Seattle, WA, USA
  • 17 Sep 2018 - 18 Sep 2018

See more events or add one to our feed

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

Announcing the Build Server Protocol v1.0.0

Friday, June 15, 2018

I’ve always been convinced that the choice of an editor, IDE or build tool is personal and, therefore, asking you to go out of your way to learn a new tool to write Scala is not a viable solution. First, because changing people’s habits is difficult and takes time. Second, it frustrates beginners who just want to learn the language. Last, it distracts seasoned developers from writing good Scala code until they master their toolchain. In the worst case, people will give up and not learn the language because the “cognitive overhead” would be too high.

Instead it is much better if we, tooling developers, can bear the burden of shipping tools that integrate with your existing workflow and you, as a user, can just install them with a quick search and a single click.

Today, I introduce the Build Server Protocol, a project that I believe plays a fundamental role in bringing us closer to making this vision a reality.

Any IDE, Any Build Tool

Traditionally, every IDE has implemented a custom integration for each supported build tool in order to extract build information such as classpaths or source directories for every project in your build. This information is necessary for the IDE to present you with a workspace where you can browse, write and compile Scala code. Every time you “Import Project” from IntelliJ or Eclipse, the IDE carries out this process on the background.

Likewise, all build tools are expected to integrate with all available IDEs. Most of them allow you to export their build to an external project model so that user adoption is not hurt by lack of official IDE support. This support isn’t as thorough and polished as the one provided by IDEs, but usually gets the job done at the expense of supported features.

So, IDEs create their own custom build tool integrations and build tools provide their own custom IDE integrations. Why should you care?

It turns out the growing number of language servers and build tools in the wider programming community means tooling developers spend a lot of time working on these integrations. This work, that needs to be duplicated on each side every time there is a new IDE or build tool and distracts developers from working on bugfixes and performance improvements, ends up affecting us – their end users. This is a big deal; we developers rely on build tools and IDEs for everything! If they are slow to evolve and maintain, then our developer experience takes a hit.

The idea behind the Build Server Protocol is to standardize the protocol for how build tools (servers) and IDEs (clients) communicate, so a single Build Server can be re-used in multiple IDEs, and IDEs can support build tools with minimal effort.

As a result, end users are provided with the best developer experience and tooling developers can improve the quality of their integrations with less effort and time, without locking out a part of the programming language community from good language support. This is especially important for the Scala community that has had a lot of recent activity in the build tools space with the increasing adoption of build tools like Pants, Bazel or mill.

Relationship with the Language Server Protocol

BSP is a win for both IDEs implementors, build tool vendors and their users! But this is, in fact, not the first time this idea is applied to tools. Microsoft’s Language Server Protocol (LSP) applied the same concept to language servers and editors. What is then BSP’s relationship with LSP?

BSP and LSP are complementary. While LSP specifies endpoints for communication between an editor acting as a client and a language server, BSP specifies endpoints between a language server acting as a client and a build server.

It turns out that if we want to create language servers to support Scala in editors like Visual Studio Code, vim or Sublime, we also need to integrate with build tools to support features like compiler diagnostics or code navigation. One of the main properties of BSP is that it can be implemented alongside LSP.

The Build Server Protocol v1.0.0

Today I’d like to announce v1.0.0 of the Build Server Protocol. This version has been the result of a fruitful collaboration between the Scala Center (me and Ólafur Páll Geirsson) and Justin Kaeser, the JetBrains developer responsible for sbt support in IntelliJ IDEA.

Justin and I have spent the past months implementing a prototype of the Build Server Protocol between IntelliJ IDEA (client) and Bloop (server). Bloop is a build-tool-agnostic compilation server that integrates with build tools such as sbt, mill or Maven to allow you to compile, test and run your applications much faster and outside of your stock build tool. Bloop has a client-server architecture, so it is the perfect project to implement BSP.

The goal of this prototype was two-fold. On the one hand, we wanted to experience first-hand the challenges of implementing BSP and learn new insights to improve the protocol. On the other hand, we wanted to provide Scala developers a faster “Import Project” that would work across different build tools now, even though build tools don’t yet provide implementations of build servers.

The first version of BSP has been designed to support the most basic language integration in an IDE/editor. IDEs can find all the modules defined in a workspace, ask for their dependencies, compile, test, run, and get notifications on modified build targets, among a few other features.

Our IntelliJ-Bloop implementation doesn’t yet implement all these endpoints. Instead, it focuses on providing a faster integration than the traditional project import. You can now import your project, browse Scala code with full language support and get compiler diagnostics from the build tool in IntelliJ’s editor.

The process to import project via BSP is as follows:

  1. Export your build to Bloop. The Bloop server will immediately pick up these changes.
  2. Import the build from Bloop to your IDE via BSP.

In total, this two-step process takes up to 15 seconds in a medium-sized build where all the dependencies have already been fetched. It is already available in IntelliJ EAP 2018.2 under a experimental flag. To try the prototype out, read the full instructions to get Bloop and IntelliJ set up.

You can see it on this demo importing akka/akka:

Demo of BSP import for akka/akka

The two-step process is fast, but it currently requires too much user intervention and needs to be repeated every time something changes in the build. What can we do to improve it?

Bloop could do a better job at exporting your sbt build every time you start up your sbt shell or reload your build to pick up new changes. This would remove the need for the first step. But the process is still ardous for users; they need to still perform the manual step of reloading the project every time the build tool and IDE go out of sync.

BSP has been designed to deal with this issue from the start. The fact that it encourages a bidirectional communication between the build tool and the IDE means that build tools can send notifications to IDEs whenever there is a change in your build. What’s most interesting is that a future release of a build tool supporting BSP would suffice to provide this state-of-the-art project import experience instantly.

Aside from importing your build, the BSP prototype also allows you to get compiler diagnostics directly from your build tool instead of diagnostics from IntelliJ’s presentation compiler. Build tool diagnostics are always correct since the compilation happens in your build tool and the results are streamed to the IDE.

Demo of BSP compile for akka/akka

To learn more about the Build Server Protocol, check out the slides of my talk with Justin at Scalasphere 2018.

Next steps

The next steps will focus on increasing adoption of the protocol and enhancing the availability and quality of the integrations for users.

First, the Scala Center will keep collaborating with Jetbrains to improve IntelliJ’s BSP import for Bloop and other build tools. The goal is to bring BSP import to a production-ready level where users can benefit from a build-tool-agnostic import project that is both faster and more reliable.

Second, I’d like to invest some resources in creating a better synergy between build tool authors and IDE implementors. The Scala Tooling Protocols Working Group created by Jon Pretty a few months ago will help us discuss and refine the protocol so that all tooling developers in our community can implement the protocol at scale and gain more experience from this process.

Third, I’d like to collaborate more closely with developers working on Scala language servers like Metals or Dotty IDE to bring Scala support to all editors. There is a big chunk of Scala developers that don’t use IntelliJ and I’d like to make sure that they benefit from a smooth developer experience too.

Last but not least, I’d like to reach out to folks in other programming language communities to find out ways we can pull our efforts together. The Build Server Protocol is a language-agnostic protocol that can be modified to add support for any programming language and I would love to see other communities improving the future of the build tools and IDE communication.

How to get involved

The best way to share your thoughts on the Build Server Protocol or to get involved in its development is to open an issue or pull request to scalacenter/bsp. Most of the features in the specification have tickets and review discussions elaborating on the design goals, like these closed and open tickets.

If you want to help integrating BSP in your favorite editor or IDE, or you’d like to help test the integrations, join our scalacenter/bsp Gitter channel and let’s discuss ways we can work together.

Acknowledgements

I’d like to thank my colleague at the Scala Center, Ólafur Páll Geirsson, for being the co-author of the Build Server Protocol. His help and insights, as well as his detailed understanding of LSP, have been fundamental in designing BSP and focusing on the ergonomics of the clients (IDEs) first.

Finally, I’d like to thank Justin Kaeser and, more broadly, JetBrains for being part of this initiative. I am optimistic our collaboration can lead to better and faster developer tools for the broad of the Scala community.

Recently

Introducing Accessible Scala

  • Thursday, June 14, 2018
  • •
  • Guillaume Massé
  • BLOG

Scala is proudly a welcoming environment for all. The Scala Center is demonstrating this by supporting the development of Accessible Sca...

Scala 2.13’s Collections

  • Wednesday, June 13, 2018
  • •
  • Julien Richard-Foy
  • BLOG

One more article about the standard collections, really? Indeed, during the last 18 months a lot of work has been done on the collections...

Scala 2.13 Collections Feature Freeze

  • Tuesday, June 5, 2018
  • •
  • Stefan Zeiger

How’s 2.13 coming? Scala 2.13.0-M4 was released two weeks ago and we are now heading towards the final milestone before RC1. The planned...
View our blog

Talk to us!

Mailing Lists/Forums

Scala Users

Scala Users

for general Scala questions, discussion and library announcements.

 Scala Contributors

Scala Contributors

for Scala contributions, language evolution dicussions, standard library, Scala platform evolution discussions and more.

Real-Time Chat

More chat rooms are listed on the Community page

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 IBM Verizon Goldman Sachs 47 Degrees SAP Twitter Your company