Minutes of the 1st meeting of the Scala Center, Q2, 2016

Meeting date: Monday, May 9th, 2016

Executive Summary

The following agenda was distributed to attendees: agenda.

Jon Pretty was elected chairperson; Martin Odersky was elected technical advisor; Bill Venners was appointed Community Delegate.

The following proposals were adopted:

  • SCP-002: Clarification of Scala to Dotty migration path
  • SCP-003: Creation of Publicity Chair
  • SCP-004: Center to coordinate SIP/SLIP process
  • SCP-005: Ensurance of continuity of Scala.js project

Some other proposals were deferred.

Date, Time and Location

The meeting took place at 2:00pm on Monday, May 9 at Jay Suites in New York City.

Minutes were taken by Seth Tisue, acting secretary.


Attendees Present

  • Sébastien Doeraene, EPFL
  • David Grove, IBM
  • Nakul Jindal, IBM
  • Alexy Khabrov, Nitro
  • Heather Miller, EPFL
  • Adriaan Moors, Lightbend
  • Martin Odersky, EPFL
  • Tim Perrett, Verizon
  • Jonathan Perry, Goldman Sachs
  • Jon Pretty, EPFL
  • Raúl Raja, 47 Degrees
  • Seth Tisue, Lightbend
  • Bill Venners, Artima

(Perrett and Khabrov attended via videoconference link.)

Apologies received



Opening Remarks

As acting chairperson, Jon Pretty conducted the meeting, made the opening remarks, introduced the participants, and presented the goals of the meeting: to elect officers, develop and discuss proposals, and vote on which proposals should become recommendations. We aim to agree on what should be done, and on what can be done within the center’s financial and other limitations.

(It was noted that Scala Center Advisory Board has an unfortunate acronym. Can we do something about that?)


Scala Center Financial Statement

Financial Statements will be given from the 2nd meeting onwards, as we are just getting starte and have yet to (a) receive many funds, and (b) allocate funds.

Scala Center Activities

Other than establishing itself at EPFL, and recruiting founding members and an advisory board, the initial project of the Center was to get the Scala Massive Open Online Courses (MOOCs) off the ground, as specified by EPFL in the Center’s founding documents.

Other intial Scala Center projects initiated include:

  1. Scaladex Package Index
  2. Scala Fiddle

The first four MOOCs are targeted to launch on May 23 on Coursera’s new course platform. The automated grading has been the source of most of the delays.

Scaladex will be announced tomorrow, and Guillaume Massé will demo a working prototype during Heather’s keynote. Scaladex is targeted to be open-sourced and launched at Scala Days Berlin in June.

Tim asked how Scaladex compares to Doug Tangren’s package index implicit.ly, which never got anywhere close to full participation and completeness. Scaladex is different because library authors don’t have to explicitly participate, though they can – instead, Scaladex will automatically index Bintray, which mirrors Sonatype. Scaladex also has more features, such as categorization of libraries, and linking to GitHub repositories, Scaladoc, dependencies, and reverse dependencies.

Alexy suggested adding a crowdsourced voting system, so that obscure or unmaintained libraries don’t dominate search results.

Hosting for Scala Fiddle will be provided by the Scala Center.

All of these efforts (MOOCs, Scaladex, Scala Fiddle) were described in more detail in Heather’s Scala Days keynote on May 10, which will be made available online via scaladays.org.

Election of Officers


Jon Pretty stood and was elected unanimously.


No one stood or was nominated for the post. Seth Tisue will continue serving as acting secretary.

Technical Adviser

Martin Odersky was nominated by Jon Pretty and elected unanimously.

Other board members

Bill Venners was appointed by the Executive Director as Community Delegate.

Scala Center Proposals

Proposal texts are in the proposals and recommendations directory. The latter directory is for accepted proposals.

Proposal SCP-004: Clarification on how to write proposals

proposed by Bill Venners

This proposal wasn’t formally discussed. Hopefully now that an initial set of proposals exists and a first meeting has been held, the process has begun to become clear.

Outcome: Deferred for possible future discussion.

Proposal SCP-001: Native Execution of Scala/Spark via LLVM

proposed by David Grove

Denys Shabalin presented his work-in-progress on this at Scala Days on May 11.

IBM is interested in applying this to running large Spark jobs.

We reviewed the technical progress of the project to date. Denys is working on getting the Scala standard library working, but it isn’t done yet. He doesn’t yet want assistance working on the compiler, feeling it’s better as a one-person project for now, but there are many surrounding areas where assistance would be welcome, such as sbt integration, other build tool integration, IDE integration, and support for testing frameworks.

The major technical hurdle to be cleared before this work could become really useful would be to add garbage collection. (This was the same major hurdle that Geoff Reedy’s previous Scala-on-LLVM project never cleared.) This hasn’t become a focus yet because there is still important work remaining on the core compiler. From his work on the scala-offheap project, Denys has knowledge of native memory management for Scala, but nonetheless, adding GC support doesn’t need to be done by Denys himself; it could be a separate contribution. Martin asked if any board member’s organization might be able to provide relevant LLVM runtime technology to address this.

David asked what is the target level of support for the Scala language and standard library. Martin says that just as with Scala.js, the goal is to support the entire language, but libraries (including the standard library) are a separate matter.

Outcome: The board agreed that voting on this proposal now would be premature, so further discussion and a possible vote were deferred to a future meeting.

Proposal SCP-002: Clarification of Scala to Dotty migration path

proposed by Tim Perrett

If the Dotty project eventually becomes the new standard version of Scala (perhaps Scala 3.0), users will have to choose when or whether to migrate. Tim emphasized the high level of investment (billions of dollars) into Scala-based technologies that now exists in many large enterprises. How can this investment be protected through this migration? If users have to rewrite too much code, or embark on a full rewrite, they might simply choose not to migrate instead. Migration of custom tooling, advanced pure-functional and type-level code, and so forth could present special difficulties. If too many large users don’t migrate, a schism in the community could result, similar to the Python 3.0 situation. “This is a big concern for companies”, Tim said. Will the open-source world jump over before big shops are ready?

There was a group discussion of past Scala version transitions; 2.7 to 2.8 is remembered as especially painful (though described by Martin as “worth it”). Some shops still have 2.9 code, and 2.10 code remains common. Points of similarity and difference with the Python 3 situation were discussed; Scala has the major advantages of a type system and the JVM as ongoing foundations. A few people mentioned the need to provide offer users incentives along with upgrade pain points, an appealing mixture of changes that don’t merely clean things up internally or implementationally but also offer nice user-visible wins so moving forward is appealing.

Martin maintained that there are important “areas of improvement” that should still be pursued, even if some migration issues result. The pain of migration can be reduced through good communication and by providing good tooling, perhaps including automated code-rewriting tools. The Dotty compiler already provides a Scala 2 backward compatibility mode; perhaps the Scala 2 compiler should have a Dotty forward compatibility mode added that detects and warns about code that won’t work as-is in Dotty.

Adriaan pointed out that some Dotty improvements can be backported to the current mainline Scala compiler (for 2.13, 2.14, and so on). The more the two compilers converge, the more potential migration pain might be averted. There are some areas in which convergence is already happening, e.g., in the changes to code generation in Scala 2.12.

All of this discussion was complex and difficult to adequately summarize.

Jon asked what could the Scala Center could do to help, other than by bringing interested parties to the table and facilitating communication. Adriaan suggested that perhaps the automatic code-rewriting tool (that Martin has long advocated creating) could be a Scala Center project. He and Martin discussed whether that tool should use scala.meta. Martin thought that could depend in part on Eugene Burmako’s plans.

Outcome: The board voted; all were in favor. Jonathan and Tim volunteered to start working on drafting a document with concrete recommendations.

Proposal SCP-005: Ensurance of continuity of Scala.js project

proposed by Alexy Khabrov

This proposal was made informally at the meeting; proposal text will follow later.

The proposal is for the Scala Center to ensure continuity of the Scala.js project, resources permitting.

At present, the core Scala.js project members are Sébastien Doereane and Nicolas Stucki. The funding for Stucki’s position runs out in August.

There was a discussion of whether Scala.js could yet be considered “production ready”, “enterprise ready”, “bulletproof”, and so forth. If not, what it would take to get it there?

Issues the Scala.js project don’t have resources to address right now include: IDE support, integration between backend and frontend code, integration with JavaScript ecosystem (such as npm and ES6 modules and libraries). Scala.js does a good job in dealing with JavaScript the language, but there isn’t a good story yet of managing dependencies coming from both ecosystems (e.g. with bower).

Sebastien: “A bunch of enterprises are already using Scala.js in production right now, and they are very OK with it.” Enterprises aren’t all the same.

A general discussion of production-readiness followed. Multiple board members shared their experiences with this at their own companies. A common theme was the need for large shops to accommodate a spectrum of different skill levels among developers, and for the development teams that maintain long-lived systems to be resilient as developers come in and out.

Outcome: The board voted; a clear majority was in favor. (There were two “no” or “abstain” votes.)

Proposal SCP-003: Creation of Publicity Chair

proposed by Alexy Khabrov

This proposal was briefly discussed and well received. Everyone was receptive to creating an unpaid position for this.

Outcome: The board voted; all were in favor.

Proposal SCP-004: Center to coordinate SIP/SLIP process

proposed by Adriaan Moors

This proposal was made informally at the meeting; proposal text will follow later.

The proposal is for the Scala Improvement Process and Scala Language Improvement Process to be merged and moved under the auspices of the Scala Center. Adriaan framed the issue as restoring the community’s faith in the language improvement process. How do we encourage people to volunteer, commit, and have faith, excitement, and trust in the process of how you change the language? And, we need clear communication to all Scala stakeholders exactly how the language is governed and what the establishment of the Center means for that.

Working this out may be difficult, but the proposal that the Center should take over and more clearly define the process wasn’t considered controversial, so discussion was brief.

Heather said a search is underway to find someone to run the process.

There seemed to be general agreement that the new GitHub-based process that was initiated by Dick Wall, and piloted by the committee in 2015, was successful and worth continuing, so we expect that process will be followed for future improvement proposals.

Outcome: The board voted; all were in favor.

Other business

The timing and location of future meetings was discussed. Meetings will be quarterly. We agreed to have one meeting annually where everyone should attend in person if they can. This will probably be at the Scala Days in North America, just like this time. Other meetings will be by videoconference primarily, but we’ll look for opportunities to colocate with a conference so at least some attendees can come together in person.

Presently there is only one Community Delegate on the Advisory Board. Heather and Jon are interested in amending the bylaws to add at least one more, but there wasn’t time to discuss it, so this has been deferred to the next meeting.

When voting, we weren’t clear on whether Martin actually had a vote or not, according to the bylaws. Jon will find out.

Poor remote audio at this meeting was noted; we should improve that for future meetings.

Closing remarks

See you next time!