Hello everyone!
Last Tuesday we had our first Scala Platform meeting. Lots of topics were discussed and I’m happy to see the Scala Platform moving forward and getting closer to the community.
Thanks to all the Committee members that joined this collaborative effort. The present members were:
Other attendees:
Here’s a small summary of what happened:
Discussions on high-level issues of the Scala Platform and the Process
-
Discussion on library maintenance.
Alex asks some questions regarding library maintenance and what we do when libraries fall unmaintained. Jorge explains that they are removed in major releases of the Scala Platform (see related discussion). Lars explains how a similar situation in Typelevel was solved – eventually the project was moved under the Typelevel organization and maintained by its members. Eugene also remarks that this is the case with sbt plugins, where almost all the important plugins live under the sbt organization for anyone to pick them up and maintain it. Mathias highlights that we should not be really worried about libraries falling dormants since the proposal already has a focus on including projects backed up by a community and with a certain level of stability. Members agree that if this case happens and no maintainer is available, then the library should be removed. Mathias proposes to delay discussion until a library actually gets unmaintained.
-
C4 process.
Lars brings up the C4 process discussion and he asks whether there is a final decision on it. Jorge says that he preferred not to take any final decision until libraries are already in the Scala Platform and maintainers can “help us do the right thing”. In his view, these important issues require consensus from the Community and a clear opinion of the poeple involved in the process. Jorge asks Lars how he feels about C4. Lars replies that he’s fine with the process recommending it but he would personally not do it. He says that in his opinion C4 is not applicable to all projects, especifically for the ones that are not very big. Mathias agrees with this and suggests that the process recommends it but not requires it. Jorge confirms that it only recommends it.
-
Code of conduct.
Lars proposes that CoC and the C4 process are separated. Mathias agrees and Jorge says it can be done without any problem. Jorge highlights that the current required CoC is Scala Center’s, which has been recently announced and has been designed by several Community members from different Scala organizations.
Scala Platform proposals
Scala JSON AST
Matthew joins the meeting to talk about the JSON AST proposal of which he’s the author. The discussion follows from the arguments discussed in the SP proposal. Matthew explains the effort behind the Scala JSON AST: provide a unified AST that Scala projects can depend on and use it for long-term compatibility. Currently, both sbt and Lift are using it, and more high profile frameworks like Spray and Akka want to use it. However, Eugene explains, this is not possible yet because the only benefit of depending on this artifact is knowing that the dependency will never change (group id will be the same over time).
Eugene emphasizes that this is just a matter of time because these projects have already decided to use the unified AST. Pathikrit brings up a JEP for Java9 to also provide a JSON AST, though Matthew points out that the true benefit of this proposal is cross-platform (not only JVM, but also Scalajs and Scala Native). Lars suggests that Java 9 support will take ages to come so we shouldn’t hinge on it. Rex makes the point that another benefit of accepting the JSON AST library is to promote interdependencies among future Scala Platform modules. Otherwise, it would limit the self-compatibility and growth of the Scala Platform. Even though it’s a little bit unusual that this library does not have a wide community of users behind it, he highlights that it’s important to have it.
After Mathias voices support for this library, he asks Jorge what’s next. Jorge explains that if the library is accepted into the incubation period, then it will temporarily be into incubation until library authors feel they are ready to bring it to the final vote. The final vote is the last step to get it into the Platform and is specified in the Scala Platform process. The module will be released under an official Scala Platform group id. Jorge emphasizes that the fact that a project is going to be incubated does not necessarily mean that it will be included it the final Scala Platform. That’s something that will be discussed after the incubation period by the Committee – when the library authors are ready to go through the final step.
The Committee votes to incubate Scala JSON AST:
- In favor: Aleksandar, Bill, Eugene, Mathias, Pathikrit, Rex.
- Against: Lars Hupel.
Enumeratum
Jorge introduces the Enumeratum proposal. He says that the lack of enumerations for beginners coming from other languages is significant enough to consider the addition of this library into the Platform. Mathias says that he doesn’t see a lot of value in providing enumerations in Scala since they have not been required in the codebases he’s worked on. Usually, sealed traits and case objects are sufficient.
Rex takes the opposite view: the lack of enumerations in Scala indicate that it’s a big deficit in the facilities that we provide to programmers. He has suffered this need and thinks it’s a pain point. Matthew uses Enumeratum constantly at work and points out the issues with current Java and Scala enumerations. Pathikrit voices in favor of enumerations by saying that ADTs don’t capture ordering while enumerations do. Mathias and Matthew think that both lookup and ordering are the two important features of enumerations. Lars pitches in and says that Enumeratum doesn’t bring a lot to the table and argues that almost all of the use cases are already covered by Shapeless. He therefore doesn’t support the proposal.
Rex entertains the idea of adding Shapeless to the Platform and asks Lars which features Shapeless provides regarding enumerations and how easy they are to use. Lars says that ordering is not covered and describes some details of the Generic macro. Lars thinks this ordering not a real issue since some Java developers seem to use concrete indexes for enumerations. Rex says that considering Shapeless as an alternative would be too hypothetical since there is no real proposal to add it to the Scala Platform. Lars points out that he doesn’t know whether Miles is willing to make such a proposal (though he thinks he probably won’t) and he reformulates his argument. He thinks that Enumeratum provides is too narrow of a use case and it’s not useful enough to be in the SP.
Matthew specifies that in his company they use Enumeratum to cross-compile to Javascript (with Scalajs) and then use other libraries like Play or Circe to integrate with the enumerations code. Even though the extensions with other libraries are not part of the proposal, Matthew’s point is that having the core in it provides a great deal to developers that can selectively use which integration they want to use. Jorge says that adding Shapeless to the SP would be indeed a good idea to entertain. But even though if Miles does not propose it, future candidate libraries (such as enum) could theoretically depend on Shapeless if it is whitelisted as a transitive dependency (see this for more information). Mathias follows the discussion by highlighting that accepting this module touches on a core concept: should the SP focus on beginners or on seasoned Scala developers? Jorge replies that he advocates for a mixed approach in which we strike a tradeoff to attract both beginners and Scala developers that depend on libraries in production.
Mathias explains that the fact of accepting Enumeratum or, say, Shapeless could greatly bias how the Scala Platform is perceived. Mathew, who was the one that proposed to add Enumeratum in the first place, argues that Scala does not have that feature and it’s worthwhile to add it because other languages do. Lars interjects that enumerations are the only way of other languages to have types at all. In Scala, the situation is completely different because the use case for enumeration doesn’t crop up so often in Scala. Mathew adds to the discussion that he often wants to get an enumeration out of its string or integer value. Aleksandar counteracts Lars’ argument by saying that enumerations is not a language feature, it’s just a library. And as such, one could use it or not, but it would be good that other developers depend on it if they need it. Aleksandar also points out two things: Enumeratum depends on the old macro API and the way to define enumerations is a little bit verbose in comparison with other languages. Matthew explains that Enumeratum built upon the existing ADT approach and preferred not to change syntax.
Rex suggests that he’d like to consider sourcecode as a potential candidate–it seems that most of the enumerations use cases could be built on top of that. Lars argues that if that’s the case, then it would reinforce his argument that zero dependency libraries are not an advantage; it’s better to depend on well-established libraries in the ecosystem. As it seems this is not the view of the majority of the Committee, and then the library proposed by Rex wouldn’t make sense. Jorge points out that if sourcecode is accepted into the Platform, that library could depend on it, since inter-dependencies among Scala Platform modules are encouraged. That’s not the case for dependencies on third-parties.
Resolution: decision is postponed until the next meeting.
Better files
Lars is enthusiastic about the addition of this library to the Platform. Some members of Typelevel, as well as him, think that Better files is a good choice because it provides a thin wrapper around NIO and strikes a balance between building a Scala API and allowing pure IO abstractions to be built on top of it. Pathikrit emphasizes that the goal of Better Files is to be a lightweight wrapper around Java NIO and wasn’t built to be cross-platform (for more information, see this related discussion). Jorge makes the point that Scala Native would probably create a port of NIO, so it won’t pose any problem. The only issue is Scalajs support, which could be worked on during the incubation period by interested contributors.
Rex is generally in favor of it, though he complains about the API being too large and providing too many options for the same thing. He thinks that this is bad for beginners since they need to learn three or four things to read through examples of the library. Rex would be strongly in favor if the API is cleaned up, but overall he’s pretty positive. Pathikrit says that the API can be easily cleaned up by removing a file that defines all the implicits. Lars asks if Pathikrit would rename the library. Pathikrit is happy to do it, he agrees the name should be improved.
Matthew pitches in and says that he would like to have only one IO library that gets the job done, and better-files seems to be the one. He would prefer it to be cross-platform, though. Eugene likes the library, he’s been thinking about using it in sbt. He’s all for better-files to go into the incubation. His only complaint is the excessive amount of defined symbols, he’d like them to be optional/removed. Aleksandar also likes the library.
The Committee votes to incubate Better files into the Scala Platform:
- In favor: Lars, Rex, Pathikrit, Aleksandar, Eugene.
The meeting was also broadcasted. Check out the SIP and SLIP videos in our Youtube channel, that’s why we record them!
I’ll be working with @pathikrit and @mdedetrich in the following weeks to incubate and use Scala Platform’s infrastructure. There will be things to work on and we’re looking for contributors that help us improve the already high quality of these libraries. Have a look at the pertinent threads for Better files and the Scala JSON AST.
I would like to thank the whole Committee again, as well as each one of the Scala developers that is making the Scala Platform possible. This is what you can do to help us move forward:
- Create a Scala Platform proposal;
- Discuss and give feedback on current proposals in Scala Contributors;
- Contribute to our recently incubated Scala Platform modules by:
- Adding features;
- Fixing bugs; or
- Improving documentation.
I got it now, but not sure if mentioning it violates the code of conduct, though. Lars might have a point, may be a good idea to consider a name change.