Minutes of the 14th meeting of the Scala Center, Q3 2019

Minutes are archived on the Scala Center website.

Summary

The following agenda was distributed to attendees: agenda.

Lunatech has joined the Advisory Board. They are represented by Erik Bakker.

Jamie Thompson, a new engineer, started work at the Center in August. Ólafur Geirsson left at the end of July.

Scala Center activities for the past quarter focused on dependency management in sbt, Coursier, MOOCs, Scala 2 and 3 interoperability, Metals and Bloop, Scala libraries and documentation, implicits, Scala.js, the SIP process, a contributors’ summit, and closing out Scala Days 2019.

Full details on these activities are in Sébastien’s report.

The board discussed (but did not yet vote on) a proposal (SCP-021) for improvements to Zinc, submitted by Adriaan Moors of Lightbend.

Seb presented thoughts on the future of the Center, the main themes it intends to address, and how it should interact with the advisory board to plan that work.

Date, Time and Location

The meeting took place virtually on Wednesday, September 11, 2019 at 3:00pm (UTC).

Minutes were taken by Seth Tisue (secretary).

Attendees

Officers:

  • Stu Hood (chairperson), Twitter
  • Sébastien Doeraene (director), EPFL
  • Martin Odersky (technical advisor), EPFL
  • Seth Tisue (secretary), Lightbend

Board members present:

  • Erik Bakker, Lunatech
  • James Belsey, Morgan Stanley
  • Thomas Gawlitza, SAP
  • Oli Makhasoeva, 47 Degrees
  • Adriaan Moors, Lightbend
  • Rob Norris, community/Typelevel
  • Jonathan Perry, Goldman Sachs
  • Bill Venners, community/Artima

Apologies:

  • Frederick Reiss, IBM
  • Julien Tournay, Spotify

Proceedings

Stu introduced the meeting. He is serving as chairperson of the advisory board for a year, as part of the new plan to rotate the position annually.

He said there was confusion this time about the appropriate and allowed timing of proposal submissions. “I think it would probably be good to formalize it” before the next meeting.

Erik Bakker introduced himself and Lunatech, the newest company to join the board. Lunatech is a services company of about 100 people, based in the Netherlands, France, and soon Belgium. They offer Scala services, as well as Java and Kotlin.

Activities

As the Center’s Executive Director, Sébastien Doeraene summarized Scala Center activities since the last meeting.

Most of Seb’s remarks were based on his detailed report on the Center’s recent activities. The following notes are a supplement to Sébastien’s report.

Scala Days 2019 financial accounting isn’t fully complete yet, but it appears that the conference broke even, as hoped.

Stu and Seb discussed technical details of the Center’s recent work on sbt dependency management (SCP-020). Interested potential users should feel free to direct their own questions to the Center, after reviewing the technical information in the activity report.

Stu conveyed Olaf’s, and his own, excitement about the native-image-based version of Coursier.

Financial report

With the addition of Lunatech, the board now includes nine companies as well as one contributor member (VirtusLab).

The Center received financial results for the MOOCs from the last three quarters. The figures were “very similar to before”. For the courses that already existed, enrollment is at “a steady state”. For the new course (“Reactive Programming”), enrollment is still growing, so it’s too soon to be sure how popular it will be.

The Center currently has three full time engineers. Alexandre Archambault is leaving as an EPFL employee, primarily because of EPFL’s restrictions on remote work. (Seb: “There is nothing we can do about it. We tried, it didn’t work.”) The Center hopes to employ him as a consultant.

Job ads will be launched shortly, since the Center intends to hire one or two more engineers.

Stu asked if it might be possible for the Scala Center to become an independent nonprofit, and not be subject to these EPFL requirements. Seb: “EPFL isn’t giving us money, the Center is autonomous financially. But we do get benefits like the building, the offices, legal support, human resources, and the university’s brand. Replacing those things would require money.” It’s “not completely off the table” that the Center might separate from EPFL someday, but not anytime soon. Martin: “We were thinking about doing that”, when bureaucratic hurdles arose, but becoming independent would involve many issues and hassles. So for now it’s “mostly inertia” but if there were a “convincing proposal” we would consider it.

Community feedback

Bill and Rob reported on recent community controversies. Bill said he has been talking to various people on all sides and trying to “listen and understand” where everyone is coming from. He summed up by saying that the concern he heard most often is that community flare-ups “are bad for Scala adoption and bad for business”. Some of the other attendees also relayed feedback and opinions from various sources, and some discussion among board members followed.

None of this controversy directly involved the Center, but the Center hopes to help when it can by facilitating connections in the community and offering advice on conflict resolution. Seb mentioned that the Center still plans to organize training for community moderators; stay tuned.

Proposals

The following new proposal was discussed by the board, but any formal vote will wait for a future meeting.

SCP-021: Focusing on backwards compatibility for Scala 2.14 and Scala 3.0

Proposed by Adriaan Moors on behalf of Lightbend. Eugene Yokota, also of Lightbend, initially drafted the proposal.

“We propose enhancements to the core of the compilation toolchain, Zinc. Zinc provides Scala compilation services, including incremental compilation, to build tools and IDEs.” See the proposal text for details.

The discussion that followed became quite involved, both technically and in terms of coordination and balancing of concerns between many interested parties. What follows is only a portion of the points made and concerns raised.

Jonathan is a proponent of Bazel, and made a comparison with how Bazel handles Java: an “interface JAR” is generated containing only signatures and omitting private methods, which is then hashed and used as an input for downstream compilation, before code generation upstream is complete. Adriaan responded that it is more challenging in Scala to capture the information (“outlines” or a “Scala signature JAR”) needed for downstream compilation. It is “feasible”, but “a technical challenge”. Jonathan expressed hope that if it is solved, that the solution would be usable within Bazel as well.

Stu is interested in outline compilation for Twitter’s needs as well. He has discussed it with Jorge as well.

Seb observes that this kind of “incremental compilation” is quite different than what Zinc has traditionally supported. One difference is grain size; existing incremental compilation in Zinc is fine-grained, interface JARs are coarser.

Stu acknowledged that the discussion about outlining is only indirectly related to the actual proposal from Lightbend, but Adriaan thought it was relevant enough to merit combined discussion, and that the Center could hopefully help “coordinate” these overlapping concerns.

Rob asked for clarification on what it means for Zinc to have “closer coordination with the Scala compiler”. Adriaan described it as follows: “Currently, Zinc has an additional abstraction layer on top of how the compiler represents your program. sbt injects phases that build up that model, then Zinc hashes those. So we propose to use the internal compiler structures to do the hashing directly, in the short term mostly for performance,” but in the longer term to reduce the maintenance burden of multiple representations.

Seth asked if part of that maintenance burden is that a single Zinc version needs to support multiple compiler versions. Adriaan said that isn’t the “biggest” pain, but it’s “part” of the pain.

Stu asked about Scala 3 support. Adriaan said that Lightbend plans to target 2.13 and probably 2.12, but wouldn’t initally target Scala 3.

Stu said that Bazel and other similar build tools are heading down a path that involves “less Zinc and more outlining”, so although the Zinc work may still be the right thing for the community, perhaps the proposal would be stronger, and beneficial to more stakeholders, if it incorporated more about outlining. (Jonathan agreed.) Adriaan expressed willingness to evolve the proposal before the next meeting.

Other business

Seb said “we’ve been reflecting” about the Scala Center’s last 3.5 years: “about the history, the projects that succeeded, the projects that maybe hit a dead end. How can we present to the board, to the community also, what our plans are for the future?”

In the Center’s early days, Seb said, there were several proposals made at each board meeting. As the years passed, there were fewer proposals and the Center spent more time working on long-term projects, which weren’t always presented to the board ahead of time. So to increase transparency and encourage feedback from the board, our plans, for transparency, and as a means of getting feedback, “I’d like to say what we think are the projects we will work on in the next 3 to 18 months.”

Seb identified three major themes in the Center’s efforts:

  1. Scala 3 migration
  2. beginners’ experience and learning materials
  3. community

Scala 3 migration: several pieces of software coming from the Center have been very successful: Metals (supported by Bloop), Scalafix, and Scalafmt. These tools will support the migration to Scala 3.

Beginners’ experience: “we’d like to build an easy, one-step install for everything Scala”, like Rustup. It would provide a JVM, the latest Scala, a build tool, an IDE, and perhaps also things like Ammonite. Perhaps this could be made available through the VS Code Marketplace.

Beginners also need learning materials. Alvin Alexander’s “Hello Scala” book is being integrated into the Scala website. But “I think we can go further,” perhaps on the model of “The Rust Book” and “The Swift Book”. MOOCs will continue to play a role in this area. Collaborating with ScalaBridge on materials for beginners would be good as well.

In the area of community, “it’s less easy to nail down specific things”, but the Center could “improve the discoverability of libraries. Scaladex was one attempt at doing this”, but it needs to be improved. The Center should also “improve our communication skills, make ourselves more visible… we don’t know precisely what we need to do, but we think it’s something we could work on.”

Rob observed: “I spend a lot of time talking to beginners on Gitter and stuff. Their big questions are typically how do I install stuff, what IDE do I use, what books should I read?” This lines up well with what Seb has in mind.

Stu said he found Seb’s list “convincing”. He also observed that there’s a divide, among Scala learners, between people who are already comfortable with JVM stuff, and those who aren’t. It’s hard to meet both groups’ needs at the same time. (Rust doesn’t have to face this.)

In the “community” area, Seth asked about training for moderators, which Seb had mentioned earlier. Is that ready for discussion? The Center has a draft document with thoughts in this area, but it hasn’t circulated yet.

The discussion shifted instead to how to expand the circles of Scala development. Stu recommended learning from the Rust community. Martin said that one thing he likes about how Rust is developed is that people outside of Mozilla can have still have formal roles in the development of the language and tooling. As examples of good steps in this direction, he mentioned VirtusLab’s involvement with IDE and tooling development, and Miles Sabin’s work with the Dotty team. Can we “further that and involve more people”, including in “formal consulting roles”?

Stu returned to the topic of how the Center and the board ought to interact with each other around longer-term projects and goals. Seth suggested that it could make sense for the Center to do a short survey of board members, asking them to gauge their level of support for current or proposed projects, since that isn’t always apparent in the whole-board, group setting.

Conclusion

As usual, the next meeting will be in approximately three months, likely in early December, almost certainly held virtually.