This page is work in progress for the upcoming GSOC 2018

Google Summer of Code

This year the Scala team applied again for the Google Summer of Code program to work with enthusiastic students on challenging Scala projects

This page provides a list of project ideas. The suggestions are only a starting point for students. We expect students to explore the ideas in much more detail, preferably with their own suggestions and detailed plans on how they want to proceed. Don’t feel constrained by the provided list! We welcome any of your own challenging ideas, but make sure that the proposed project satisfies the main requirements mentioned below.

How to get involved

The best place to propose and discuss your proposals is our “contributors” discussion forum. This way you will get quickly responses from the whole Scala community.

Previous Summer of Code

We encourage you to have a look at our 2017, 2016, 2015, 2014, 2013, 2012, 2011, Summer of Code 2010 pages to get an idea on what we and you can expect while working on Scala.

Project Ideas

Here are some project ideas. The list is non-binding and any reasonable project related to Scala that is proposed by a student will be thoroughly reviewed.

Mill Build Tool

Mill is a new Scala build tool, inspired by CBT and Bazel, which aims to be a full substitute for Scala’s venerable SBT. Building upon the principles laid out here and here, Mill aims to be dramatically simpler than current build tools both inside and outside the Scala community while still preserving the rich functionality people expect from a build tool.

This is a catch-all header for multiple possible Mill-related projects, whose exact scope will be finalized closer to the GSOC date

Supervised by @lihaoyi

Scalafix in the editor

Scalafix is a linting and refactoring tool, which aims to help automate migration between different Scala compiler and library versions. Currently, the primary way to interact with Scalafix is in batch mode through a command-line interface. However, many users have requested the ability to use Scalafix interactively through an editor.

A proof-of-concept integration running Scalafix from VS Code through the Language Server Protocol is already working. Many popular IDE refactorings like “Move class” and “Organize imports” are missing, however.

The scope of this GSOC project would be to implement new Scalafix refactoring rules to be used from an editor. The project can start small with simple refactorings, and gradually step up as progress happens. Scalafix is a fast moving project, so you will be working in a codebase with multiple contributors.

Supervised by @olafurpg

scalajs-bundler 1.0

scalajs-bundler provides useful features with a high level of configurability, making it easier for Scala.js developers to use NPM packages. However, several important requests haven’t been fulfilled yet: moving the parts that fetch NPM packages to a separate sbt plugin, making it possible to use scalajs-bundler without sbt, documenting how to get a super productive development setup with fast hot-reloading, etc. The GSOC project consists in tackling all scalajs-bundler remaining issues for a 1.0 version.

Supervised by @julienrf.

CBT support for Play Framework

Implement everything necessary to have a smooth development experience with Play framework and cbt, e.g. restarting the server on change, bundling/minimizing js/css, integration with scalajs. Take guidance from sbt plugin.

Supervised by @cvogt.

CBT Coursier integration

Allow using coursier as the resolver in cbt.

Supervised by @cvogt.

CBT Ticket hunt

Bring down these open tickets for cbt by picking some of the most urgent or interesting ones.

Supervised by @cvogt.

Debugger integration for Scala Native

Scala Native is an optimizing ahead-of-time compiler for Scala. It’s implemented in Scala and generates optimized LLVM IR for the whole program. In this project you’re going add support for LLVM source-level debugging information to the compiler toolchain. This information is necessary to make external debuggers such as LLDB and GDB work with Scala Native applications.

Supervised by @densh

Windows support for Scala Native

Scala Native started as a *nix-only toolchain. A number of major APIs such as files, sockets and threads are implemented on top of POSIX APIs. This poses major challenges in porting the toolchain to Windows. In this project you’re going to continue working on the Windows port of Scala Native based on prior work by @muxanick.

Supervised by @densh

Binding generator for Scala Native

Scala Native provides bindings for several C and POSIX APIs out of the box. To help complete and maintain the list of supported APIs as well as seamlessly use 3rd party native libraries support for automatically generating bindings is needed. The goal is to create a Scala Native program that parses C header files using libclang and generates a Scala Native API as well as an sbt plugin to use the binding generator in a project.

A previous proof-of-concept may serve as a starting point.

Supervised by @jonas

Web-based test UI for Bloop

Bloop is a command-line tool for fast edit/compile/test workflows. In this project, you’ll be working on a web-based client controlling test execution with the goal of providing instant and interactive feedback. You’ll have to extend the protocols that allow Bloop to communicate with other tools and develop the new client. Majestic is a similar project for Javascript tooling.

Supervised by @Duhemm.

REPL modernisation

The Scala REPL is a tool for evaluating expressions. This project is going to aim at making the REPL more modern and easier for programmers to use. We’re going to work on features like multi-line editing or watch variables that update as you work on your program. We’re going to start small and go from there.

Supervised by @marialivia16.

Project name

Project description.

Link to the corresponding code repository, if relevant.

Supervised by @username.

Requirements and Guidelines

General Student Application Requirements

This is the seventh time the Scala project has applied to the Summer of Code, and from previous years’ experience, increased popularity of the language and stories of other mentor organizations we expect a high number of applications. First, be aware of the following:

Make sure that you understand, fulfill and agree to the general Google Summer of Code rules

The work done during GSoC requires some discipline as you have to plan your day-to-day activity by yourself. Nevertheless, you can expect regular contact with your mentors both via the usual means of communication for you project as well as personal guidance via email, chat or phone. The mentor is there for you in case you get stuck or need some guidance during your 3 month coding project.

The official SoC timetable mentions May 14 as the official start of coding. If you have time, you are encouraged to research your proposals even before that (and definitely learn the basics of Scala, if you haven’t done that already).

Student Application Guidelines

Student proposals should be very specific. We want to see evidence that you can succeed in the project. Applications with one-liners and general descriptions definitely won’t make the cut.

Because of the nature of our projects students must have some knowledge of the Scala language. Applicants with Scala programming experience will be preferred. Alternatively, experience with functional programming could suffice, but in your application we want to see evidence that you can quickly be productive in Scala.

You can think of Google Summer of Code as a kind of independent internship. Therefore, we expect you to work full-time during the duration. Applicants with other time commitments are unlikely to be selected. From our previous experience we know that students’ finishing their studies (either Bachelor, Master of PhD) are likely to be overwhelmed by their final work, so please don’t be too optimistic and carefully plan your time for the project.

If you are unsure whether your proposal is suitable, feel free to discuss it on our “contributors” discussion forum. We have many community members on our mailing list who will quickly answer any of your questions regarding the project. Mentors are also constantly monitoring the mailing list. Don’t be afraid to ask questions. We’d love to help you out!

General Proposal Requirements

The proposal will be submitted via the standard web-interface at https://summerofcode.withgoogle.com/, therefore plain text is the best way to go. We expect your application to be in the range of 700-1500 words. Anything less than that will probably not contain enough information for us to determine whether or not you are the right person for the job.

Your proposal should contain at least the following information, but feel free to include anything that you think is relevant: