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

Executive Summary

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

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

None.

Proceedings

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?)

Reports

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:

Scaladex Package Index

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.

Scala Center Proposals

Proposal SCP-004: Clarification on how to write proposals

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.