Minutes of the 6th meeting of the Scala Center, Q3 2017

Minutes are archived on the Scala Center website.

Summary

The following agenda was distributed to attendees: agenda.

Scala Center activities for the past quarter included progress on: compilation performance analysis, Scalafix, Scalameta, 2.13 collections, sbt and zinc 1.0, Scastie, Scaladex, Scala Native, the Scala websites, the Scala Platform, scalajs-bundler, and the Scala Center’s MOOCs.

Full details on these activities are in Heather’s report.

Three new proposals were made:

  • SCP-013: Aid the ecosystem in upgrading to sbt 1.0.x (Lars Hupel)
    • voted on and accepted
  • SCP-014: Production ready scalamacros/scalamacros (47 Degrees, SAP)
    • voted on and accepted
  • SCP-015: Improving performance and profiling of Zinc (James Belsey)
    • voted on and accepted

Date, Time and Location

The meeting took place virtually, via UberConference, at 3:00pm (UTC) on Tuesday, September 12, 2017.

Minutes were taken by Seth Tisue (secretary).

Attendees

Attendees present

Board members:

  • James Belsey, Morgan Stanley
  • Thomas Gawlitza, SAP
  • Stu Hood, Twitter
  • Lars Hupel, community/Typelevel
  • Raúl Raja Martinez, 47 Degrees
  • Adriaan Moors, Lightbend
  • Tim Perrett, Verizon
  • Jonathan Perry, Goldman Sachs
  • Frederick Reiss, IBM
  • Bill Venners, community/Artima

Also:

  • Eugene Burmako, Twitter
  • Andy Scott, 47 Degrees
  • Ólafur Geirsson, Scala Center (present only for the SCP-014 and SCP-015 discussions)

Officers:

  • Heather Miller (director), EPFL
  • Jon Pretty (chairperson), Propensive
  • Martin Odersky (technical advisor), EPFL
  • Seth Tisue (secretary), Lightbend

Proceedings

As chairperson, Jon Pretty conducted the meeting.

Activities

As Executive Director, Heather Miller summarized Scala Center activities since the last meeting.

Most of Heather’s remarks were based on her detailed report on the Center’s recent activities.

Note that Google Docs might not display the following animated GIFs demoing recent developments, so we reproduce the links here:

The following notes are a supplement to Heather’s report:

Scalafix: Seth asked what major work was left to do on Scalafix, e.g. for a 1.0 release. Olaf’s answer: Scalafix v1.0 will be released once the API stabilizes (there have been major breaking changes every 2-3 months until now, but he hopes that v0.5 will survive longer) and the feature set is comprehensive enough to support advanced rewrites such as explicitly inserting inferred types, implicits and macros.

Scastie: Scastie is “basically finished”, says Heather (with the recent addition of auto-completion and embedded mode).

Financial Report

MOOC money has arrived; Tapad has left the board; some funds were donated to ENSIME and ScalaQuest.

See Heather’s report for further details and figures on the Center’s financial situation.

Since there are several new proposals this quarter, Jon asked how much free time the engineers might have to work on them. Heather says that Guillaume is freed up now that Scaladex and Scastie are “basically done”.

Jon asked how much MOOC money came in. Heather explained that after the money was split between Coursera, EPFL, and the Scala Center, the Scala Center’s share was enough to continue funding herself and Julien for the next year.

Proposals

SCP-013: Aid the ecosystem in upgrading to sbt 1.0.x

Proposed by Lars Hupel.

See the proposal text for details.

Lars said he has been asked if the Scala Center really needs to take this on, given that the community has already done a lot of sbt 1.0 migration work on its own. In his response, he says that there is still a “long tail” of plugins that haven’t migrated yet, so there is room for the Scala Center to help.

Tim asked how successful “sbtfix” (the scalafix rewrites for sbt 0.13 -> 1.0 migration) has been. Heather, after asking Jorge, says that there hasn’t been much feedback. But note that sbtfix targets simple build definitions, not plugins. Migrating complex builds and plugins is harder, so that’s where the Scala Center’s help is most needed.

Jon asked “is there something else we could do make it harder to keep using Scala 2.10 and sbt 0.13”, or to state it more positively, to encourage migration? With regards to the status of Scala 2.10, Lars provided this link to a discussion on Discourse: https://contributors.scala-lang.org/t/continuing-or-dropping-scala-2-10-maintenance-in-the-ecosystem/1013/2 . Lars “thought the topic would be discussed more heavily” but it wasn’t, so he suggests encouraging library maintainers to drop 2.10 support; those stuck on an old Scala version usually aren’t that interested in upgrading to bleeding-edge library versions.

James asked about the proposed effort level: “it’s just three weeks’ work?” Lars says porting plugins is “not that hard” so yes, a lot could be done in that time, many plugins just needed “two or three hours” of work for him to port himself, and a Scala Center person with more sbt experience would probably be even faster. But the time spent on this should be spread over a longer calendar time, to leave time for back-and-forth with plugin maintainers.

Heather voiced a doubt about setting a precedent or example of the Scala Center taking on work involving “migrating people’s code for them”. While no one directly addressed this objection, the final voting presumably reflected the modest effort level requested.

Voting: 9 in favor, 1 opposed (SAP), no abstentions. The proposal is accepted.

SCP-014: Production ready scalamacros/scalamacros

Proposed by 47 Degrees and SAP, in collaboration with Eugene Burmako from Twitter.

See the proposal text for details.

Eugene says that macros aren’t a focus for him at his job at Twitter. “I can personally do some volunteer efforts”, he says, but an engineer from the Scala Center could make a dramatic difference.

Someone asked what “production ready” means in this context. Heather mentioned “should whitebox macros be included or not” as an example of an unresolved question. Eugene says that he would “defer to Adriaan and Martin” on the question of how official the work on the prototype might eventually become. “A lot of people depend on macros,” said Adriaan, and confirmed that the Lightbend team supports the rework and hopes:

  • in 2.13 we experiment with Scalamacros (e.g., via compiler plugins to begin with and feature flags in later minor releases)
  • in 2.14 Scalamacros no longer “experimental” and scala.reflect is deprecated

Martin also voiced his support for pulling the rework into Dotty as soon as it is ready.

Jon asked if there is “risk” that a new macro system that doesn’t support everything the old one did (e.g. whitebox macros) could result in some users choosing not to move to a newer Scala, holding back the advancement of the language. James and Martin acknowledged this is as a real concern, but both expected this will all work out as long as the rework effort stays appraised of community reaction as it progresses. Eugene suggested that especially at the start the rework effort should produce a roadmap, for community feedback, before too much coding happens.

Martin framed the question of whitebox macros in terms of Dotty’s design goals. Dotty, he says, wants to be a “capable language” rather than a “language toolbox”. So it matters whether whitebox macros are being used to do “Scala-like” things, or to turn Scala into something else. So “we will have to look at each one” of the ways whitebox macros are being used. Adriaan agreed and mentioned a current collaboration with Miles Sabin to improve scalac so that Shapeless and other libraries can rely less on macros and other nonstandard techniques.

Bill expressed a hope for overall simplification of macros, a “smaller and simpler” system.

Heather expects achieving consensus on all the issues could take quite a while. This is an open-ended effort with many open questions about content and timing, but nonetheless, the advisory board could authorize 4-5 months of work on this and then re-assess at a future meeting.

Heather says Ólafur would work “part time on this and part time on Scalafix” with likely participation from Guillaume and Jorge as well. Martin expects that his Ph.D student Fengyun Liu would participate as well.

Ólafur suggested prioritizing black-box def macros as a clear starting point.

Jon suggested two rounds of voting, one on whether the proposal is even ready for an up/down vote, and if that vote passes, the actual up/down vote. The first vote passed, so final voting did proceed.

Voting: 7 in favor, 0 opposed, 3 abstentions (IBM, Verizon, Lars). The proposal is accepted.

SCP-015: Improving performance and profiling of Zinc

Proposed by James Belsey from Morgan Stanley.

See the proposal text for details.

There was some back and forth between Heather, James, and Jon about the expected effort level. The engineer expected to take this on would be Jorge, who (Heather says) is “enthusiastic” about it.

Stu confirmed that Zinc’s test suite doesn’t have comprehensive coverage of incremental compilation.

Jonathan found the other two proposals “more compelling” than this one, but wasn’t actually opposed.

Jon asked Heather if all three proposals were within the Center’s capabilities. Heather said yes, modulo the open-endedness of the macros work.

Jon apologized for the “horrible magenta color” in the voting spreadsheet, used to distinguish None from Some(None).

Voting: 6 in favor, 4 opposed (47 Degrees, SAP, Twitter, Verizon), no abstentions. The proposal is accepted.

Closing remarks

All three proposals passed. The new voting spreadsheet was judged a success (except for that appalling magenta).

Bill had no community feedback to report. Lars mentioned that the “sbt/scala/dbuild/community build” proposal still isn’t ready but he’s still talking to Alastair about it.

The next meeting will be in approximately three months.