Minutes of the 7th meeting of the Scala Center, Q4 2017
Minutes are archived on the Scala Center website.
The following agenda was distributed to attendees: agenda.
Scala Center engineering activities for the past quarter focused on Scala 2.13 collections, macros, Scalafix and Scalameta, Scala compiler profiling, Zinc, and Bloop. Progress was made in other areas as well.
Full details on these activities are in Heather’s report.
Other topics discussed at the meeting included LSP (Language Server Protocol) support for Scala.
No new proposals were submitted this quarter.
Date, Time and Location
The meeting took place virtually, via UberConference, at 4:00pm (UTC) on Friday, December 1, 2017.
Minutes were taken by Seth Tisue (secretary).
- Ross Baker, Verizon
- James Belsey, Morgan Stanley
- Thomas Gawlitza, SAP
- Stu Hood, Twitter
- Lars Hupel, community
- Adriaan Moors, Lightbend
- Juan Pedro Moreno, 47 Degrees (filling in for Raúl)
- Frederick Reiss, IBM
- Bill Venners, community
- Jonathan Perry, Goldman Sachs
- Heather Miller (director), EPFL
- Jon Pretty (chairperson), Propensive
- Martin Odersky (technical advisor), EPFL
- Seth Tisue (secretary), Lightbend
As chairperson, Jon Pretty conducted the meeting.
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.
The report also includes links to multiple blog posts on scala-lang.org detailing recent work.
These notes are a supplement to Heather’s report:
The staff engineers at the Center are the same as last quarter.
New to the Center since late October is Darja Jovanovic, an intern. She’s focusing on communication and community organizing, including Scala Days, the Scala Improvement Process, and the Scala Platform Process.
Lars had been working on something Bloop-like and wished he’d known sooner the Scala Center was doing something similar. Some discussion ensued about when the right time to announce new experimental work. (There are downsides to announcing too early, too.)
Stu related some history on Zinc and Bloop; Bloop is actually similar to an earlier, CLI-based iteration of Zinc, which is now mostly forgotten. He also brought up the advent of LSP and multiple efforts (competing? complementary?) to support LSP for Scala. Martin suggested that Twitter, Lightbend, ENSIME, Dotty, Triplequote, and other interested parties should get together to discuss LSP. (This did end up happening, organized by Jon, on January 11; an account of that meeting will be published separately.)
Jon asked what engineers would be doing next quarter. Heather said that for the most part engineers would continue with the work they are already doing. The most uncertainty is around Martin (Duhem) and Guillaume (Massé).
Sam Halliday’s proposal on debugger information hasn’t been addressed yet. Lars had raised this concern with Heather before the meeting. The proposal accidentally fell between the cracks considered this quarter. (The cause was that the compiler debugging proposal, due to a procedural error during an earlier meeting, was taken to a new vote subsequent to that meeting, and was accepted extraordinarily, outside of the usual process.) Heather will revisit it next quarter (perhaps as a project for Guillaume).
Because there were no new proposals this time, there was lots of time for open discussion on topics of general concern. Jon hoped some future proposals might come out of these discussions.
Bill relayed some community concern about version migrations in the Scala world. There is some apprehension about (for example) the moves to Scala 2.13, Dotty, and Sbt 1. We should all be keeping migration pain in mind as a consideration when moving forward.
Jon asked if the concern is mainly about source compatibility or binary compatibility. Bill said it’s mainly binary compatibility; everything must be upgraded at once, nothing can move until every dependency is available for the new version. Stu expressed his ongoing interest in source-based dependencies as a way of avoiding binary compatibility issues; “inlining” or “vendoring” the source for dependencies can be a solution.
James mentioned migration difficulties around warnings. Making
warnings fatal in your build greatly aids keeping a codebase clean,
but the all-or-nothing nature of
-Xfatal-warnings, per-project, is
problematic. Improved tools for selective suppression of warnings
would be a big help. Adriaan acknowledged that this is a
long-standing need for many Scala users that hasn’t ever quite made it
onto Lightbend’s release roadmaps, only because more pressing work
keeps intervening; perhaps there is an opportunity here for a
proposed design to arise from the community.
Jon asked how advisory board members have found hiring Scala programmers lately, and whether there’s anything the Center could do to help. Ross described it (not at Verizon, but in his home city of Indianapolis) as a “chicken and egg” situation where companies are excited about Scala but think there aren’t Scala developers to hire, while developers are excited too but think the Scala jobs aren’t there. How does this cycle get broken? James says at Morgan Stanley they “take Java developers who are keen and convert them” and doesn’t consider it a significant issue from their perspective. Nobody offered a suggestion on something the Center could do in this area.
The discussion turned to factors affecting Scala adoption more broadly. Adriaan suggests that tooling quality could be the largest factor currently holding Scala back. Ross says some CTOs are concerned that multiple “dialects” of Scala exist (for example, pure-functional style vs others) and are apprehensive this could create division internally.
Jon asked about competition from Kotlin. (Raul from 47 Degrees is interested in Kotlin, but wasn’t present.) Bill attended a Kotlin speakers’ dinner as a guest and had the impression that people interested in Kotlin “never liked Scala anyway”, perhaps out of lack of a strong interest in functional programming. Lars asked if Kotlin appealing to a “better Java” audience might free up Scala to focus more on pure FP. Martin spoke up to say that he feels strongly that Scala should be considered neither a “better Java” nor a “Haskell on the JVM”, but a “third style” that is “unique and different” and “that’s what we should emphasize.” Bill points out that “better Java” might mean something modest or even trivial like “Java without semicolons”, but might also refer to Scala’s “third way”, whereas he felt Kotlin really is more firmly aiming to be a “better Java”, strictly speaking.
James mentioned that at Morgan Stanley, Scala’s compilation speed is still very much a concern impacting further adoption internally. Stu says that at Twitter, that while they are writing much more new Scala then Java, overall, there is still some perception that Scala is “complicated”. There was some also discussion about keeping codebases modular to reduce compile times, which helps but can also result in the need for more build machinery. There is a need for automated assistance with making codebases more modular; Lars mentioned Haoyi Li’s Acyclic as a worthy example.
Jon asked about board members’ experiences sponsoring Scala conferences. James said that from a recruitment perspective, which is their primary motivation for sponsoring, location matters strongly; Morgan Stanley is much likelier to sponsor an event in a city such as London where they already have a substantial presence. Thomas says sponsorship is also important for a company’s image, showing that the company is involved with new technologies. Frederick says IBM has multiple motivations for sponsorships: recruiting, corporate image, and generating sales leads. They are often willing to sponsor a conference once, but then evaluate that first experience carefully when deciding whether to repeat in subsequent years.
Several board members said that they didn’t submit proposals this time because they’re pleased with the work that is already in progress. Stu mentioned that LSP-related work seemed like a strong candidate for a future proposal.
The next meeting will be in approximately three months, as usual.