Scaladex is a catalogue of open source libraries. It’s automatically generated based on data collected from GitHub and Maven Central.

Scaladex aims to be a one-stop index to go to get all info about a project. Use it to find which releases are compiled for a specific Scala version or backend (including Scala.js and Scala Native), or use it to map out the different modules made up by a large project. Scaladex additionally lays out different artifacts’ dependencies, and whether those dependencies are compile or test dependencies. Scaladex even points users to Scaladocs generated for each artifact!

The Scala Platform Process provides organizational support for a broad range of open source software projects. The mission of the process is to provide high-quality software for the good of the Scala community. Through a collaborative and meritocratic development process, the Platform delivers a stable collection of libraries with widespread use and a low barrier entry for beginners and intermediate users, ready for serious production use.

You can find more information on the Scala Platform here. If you would like to get involved into OSS development of the Scala Platform, let us know over Gitter.

A SIP (Scala Improvement Process) is a process for submitting changes to the Scala language. Its main motivation is to become the primary mechanism to propose, discuss and implement language changes. In this process, all changes to the language go through design documents, called Scala Improvement Proposals (SIPs), which are openly discussed by a committee and only upon reaching a consensus are accepted to be merged into the Scala compiler.

The aim of the Scala Improvement Process is to apply the openness and collaboration that have shaped Scala’s documentation and implementation to the process of evolving the language. This document captures our guidelines, commitments and expectations regarding this process.

Our mission is to develop quality and widely accessible educational materials, and to make them freely available. We have launched 4 courses along with a capstone project on Coursera. All courses can be taken for free (without a certificate).

Functional Programming Principles in Scala

Course on Coursera

Functional Program Design in Scala

Course on Coursera

Parallel Programming

Course on Coursera

Big Data Analysis with Scala and Spark

Course on Coursera

Functional Programming in Scala Capstone Project

Course on Coursera

We have also created a Scala Exercises interactive tutorial that is based off of our above MOOCs. Walk through the material of the functional programming in Scala MOOCs as an interactive tutorial!

Scalafix is a refactoring tool created at the Scala Center with the mission to help automate the migration between different language and library versions.

A scalafix rewrite is a small program that can transform Scala code. Scalafix comes with several built-in rewrites, for example RemoveUnusedImports and ExplicitReturnTypes. It is also possible to implement custom rewrites with scalafix. Custom rewrites can be distributed in source and executed from source, without the overhead of publishing artifacts to Maven Central.

Scalafix rewrites are either syntactic or semantic. A syntactic rewrite can use tokens and parsed abstract syntax trees. A semantic rewrite can use the same features as a syntactic rewrite in addition to extracted semantic information from the compiler, including resolved names, reported compiler messages and inferred type annotations. Semantic information is extracted from an instrumented version of the Scala compiler using Scalameta.

It is possible to run scalafix as a standalone command-line interface or as an sbt plugin. Integrations for other build tools and potentially IDEs are planned in the future.

See the official documentation for more information about scalafix.

Scastie is… Scala + sbt in your browser! You can:

• use any version of Scala (scalac), or even alternate backends such as Dotty, Scala.js, Scala Native, and Typelevel Scala.
• use any library published on Maven.
• save and share Scala programs/builds with anybody

This is all possible because Scastie is based on sbt, allowing us to support newer Scala versions and resolve library dependencies on Maven.

Want to see what Scastie can do? Check out our ray tracer demo using Scala.js on Scastie!

Scastie is an original idea from Aleh Aleshka (OlegYch).

scalajs-bundler is an sbt-plugin that provides a module bundler for Scala.js projects that use npm packages: it bundles the .js file emitted by the Scala.js compiler with its npm dependencies into a single .js file executable by Web browsers. It aims to provide a replacement for jsDependencies.

scalajs-bundler uses npm and webpack under the hood. It also supports Yarn.

Scala Native is an ahead-of-time compiler for Scala. Its goal is to compile Scala code to native binaries, using the Scala compiler as front-end, its own optimizer and LLVM as back-end.

Scala Native follows the behavior of Scala on the JVM (Java Virtual Machine) as much as possible and can compile existing Scala programs with little to no modification.

By moving away from the JVM (Java Virtual Machine), Scala Native introduces Scala as a candidate for system programming, latency-sensitive applications and other areas where the JVM’s warmup time would be problematic. Finally, Scala Native offers interoperability with existing C libraries.

The Scala Center is involved in multiple aspects of the development of Scala Native:

• sbt-crossproject is an re-implementation of Scala.js’ crossProject and %%% to support Scala Native, allowing users to publish and depend on Scala Native libraries.

• We added support for regexes, which helped greatly in implementing other missing features (java.util.Formatter, String.split, etc.)

• We contributed I/O support and java NIO support. Scala Native programs can now perform I/O operations using the same APIs as they would on the JVM.

• Support for testing frameworks was added by the Scala Center. The supported test frameworks include uTest and ScalaCheck.

The Scala collections library underwent a major redesign in Scala 2.8. While the current design proved to be successful in many areas, several pain points have become apparent over the years which indicate fundamental issues with the design that cannot be removed through gradual minor changes. This prompted the request for strawman proposals for a new design in the context of Dotty. We propose that the Scala Center work on the implementation of this new design for the Scala 2.13 standard library. The work in progress can be seen in the following github repository: https://github.com/scala/collection-strawman

Improvements

Scala tutorial based on the existing MOOCs.

Improvements for http://docs.scala-lang.org/

This initiative focuses on improving day-to-day tools that all Scala developers depend on: Zinc (Scala’s incremental compiler) and sbt, the most prominent Scala build tool.

Our involvement in these projects have helped them to improve on the following topics:

1. Reproducibility.
2. Performance.
3. Usability.
4. Documentation.
5. Welcoming experience to OSS developers.

These contributions started off after the “Improve builds with direct dependencies” proposal was finished before the estimated end time.

Summaries

To see our contributions to Zinc follow this link.

To see our contributions to sbt read this thread.

Give us feedback

We’re open to your feedback! If you feel like something should be fixed or improved in either of these tools, chime in over Scala Contributors.

Scalameta is a compiler-agnostic metaprogramming toolkit that can be used to build a wide range of Scala developer tools. Tools currently using Scalameta include

• scalafix (refactoring)
• scalafmt (formatting)
• scastie (worksheet-mode)
• metadoc (online code browsing with “jump to definition”)
• stags (ctags generator)

The Scala Center contributes to the development of Scalameta’s “Semantic API”. The Semantic API enables tools to query for information from an instrumented compiler such as inferred types, resolved symbols, implicits, reported compiler messages and more. Such information opens possibilities to build a wide range of new developer and productivity tools for Scala. In particular, the Semantic API is used by scalafix, another Scala Center project with the mission to help automate the migration between different Scala compiler and library versions.

Scalameta is compiler-agnostic. This means Scalameta’s syntactic and semantic model is not tied to a particular compiler version such as scalac, dotc or the IntelliJ Scala Plugin. By being compiler agnostic, Scalameta enables developer tools to be portable across multiple environments and support many different dialects or flavours of Scala.

See the official Scalameta website to to learn more about Scalameta.

Dotty is a platform to try out new language concepts and compiler technologies for Scala with a focus is mainly on simplification. Eventually, Dotty is planned to become Scala 3. The Scala Center has contributed to the development of Dotty on several fronts

• Migration tool (scalafix)
• Community build (lampepfl/dotty-community-build)
• Reporting incompatibilities with Scala 2.x (dotty/issues)
• Next generation macros (scalamacros/scalamacros)

The goal of this proposal is to expose the cost that Scala code has in Scalac’s compile times, and display it to users via a console and an interactive environment.

From the proposal:

“As a user of the Scala compiler investigating slow build times is difficult. We propose enhancing the current flags and tooling within the Scala compiler to identify hotspots in or caused by users’ code. For example a macro may be significant or called more often than expected (e.g. in implicit resolution). Providing tooling that generates user-understandable reports e.g. per macro times called and total times or identifying poor implicit resolution allows users to tune their builds for optimal performance.”

The proposal focuses on three areas:

1. Data collection (which requires changes to the Scala compiler.)
2. Data visualisation and comparison (which requires a compiler plugin + an IDE integration)
3. Reproducibility (which requires the development of an sbt plugin)

More information is available in the scalac-profiling repository.

The goal of this project is to bring non-experimental and portable macros to Scala 2.x and Dotty.

From the proposal:

Def macros and macro annotations have become an integral part of the Scala 2.x ecosystem. Well-known libraries like Play, sbt, Scala.js, ScalaTest, Shapeless, Slick, Spark, Spire and others use macros to achieve previously unreachable standards of terseness, type safety and performance.

Unfortunately, Scala macros have also gained notoriety as an arcane and brittle technology. The most common criticisms of Scala macros concern their difficult metaprogramming API based on compiler internals as well as a lack of featureful editor support. Even five years after their introduction, traditional macros don’t expand properly in Intellij. This leads to a proliferation of spurious “red squiggle” errors, even in simple projects. As a result of these problems, the language committee has decided to retire the current macro system.

• November 27th 2017 - What’s happening with macros
• October 9th 2017 - Roadmap towardss non-experimental macros

Bloop is a command-line tool for fast edit/compile/test workflows. Its primary goal is to compile and test your project as fast as possible, offering a snappy developer experience. Bloop does not aim to replace your stock build tool, but rather complement it.

Build tools are complex applications that need to cover a wide range of use cases, from building and testing your project to deploying it, integrating with external tools, resolving dependencies and any build-related tasks.

Such a vast array of requirements make build tools like sbt, Maven and Gradle create their own configuration models and DSLs to be customizable, whether that is programmatically or declaratively. It is easy that in the process of creating a build tool, performance is sacrificed by ease of customization, readability or maintenance.

On the other hand, there is also the problem that build tools move slowly and have a hard time upgrading to new changes upstream (for example, in compiler APIs). As a result, Gradle, Maven, Leiningen, and CBT have not yet been migrated to Zinc 1.0, which offers faster incremental compilations than its predecessor. As a result, users of these tools are not benefiting from the latest state of the art.

bloop aims to fix both problems:

1. It’s specialized on only providing as fast as possible edit/compile/test workflows, rather than covering all of the needs of general build tool like sbt.
2. It allows other build tools to integrate with it.

You can think of bloop as a powered CLI for Zinc, rather than as a brand new build tool – bloop does not aim to replace your stock build tool, rather complement it.

In practice, this means that when users are only going to compile and test their project, they can use bloop instead of a full-blown resource-hungry build tool; and that generic build tools can delegate to bloop to compile and test users’ projects instead of creating their own Scala and Java integrations, which are hard to maintain.