I understand the importance of modularizing Scala, but am not sure what role the Platform Process will play.
Is it simply the incorporation of very important, but non-core parts of Scala, like XML and ScalaJS?
Or is the Platform Process EPFL + Industry + the community’s way of rubber-stamping open source projects? And what should the scope of these libraries be? Would things like Json, web frameworks, and database access be included? On one hand, having “official” libraries for things like json would decrease the ecosystem’s fragmentation (there’s four or five competing json libraries now?). But I wonder if Scala’s library fragmentation is due not from lack of organization, but the many environments and paradigms Scala supports. Typelevel projects promote pure functional programming, Ligthtbend OSS is more imperative and targets enterprise java users, and ScalaJS projects have smaller footprints to work well in browsers.
I personally think it would be a bad idea to pick and choose libraries from the three camps to standardize. Including core building block (like XML, and the JSON AST mentioned previously) makes more sense, but no longer fits the “batteries included” definition. A Coursera student can’t simply paste a line into their build.sbt and get a web framework and json parser, for example.
Finally, a somewhat unrelated question (and one that has probably been answered before): will the Scala Center publish a single package (ie. “org.scala-lang” %% “package” % “XXX”), or additionally the individual packages themselves?
It’s a collection of libraries covering the most important needs of Scala developers (for instance, utilities like XML, JSON, IO, etc). ScalaJS, being a compiler and a complex piece of software, does not fall into this category but its inclusion is up to the community and the Scala Platform Committee.
The modules that will be included are to be decided by the Scala Platform committee, but those seem like good candidates. We’ll have our first meeting on Monday, 17th January 2017 and we will start reviewing proposals from the community.
We do not fight fragmentation, we welcome it. This is why we’re doing the Scala Core - Scala Platform split. I’m very much looking forward to see what other developers/organizations will create in the future.
The goal of the Scala Platform is not to compete against them. Different platforms will focus on different properties/features. The Scala Platform focuses on concrete use cases to make Scala easy to learn (for students and other developers) and easy to adopt in production systems by companies/organizations (more info). This helps us increase the number of Scala developers while creating a set of community-maintained libraries that are independent from big organizations/companies and yet have some maintenance and stability guarantees.
The Scala Platform is not a magical wand to rule out other alternatives. It’s a medium for the Scala community to experiment, design and ship production-ready software that works in a large majority of the cases. By letting the community give shape to the modules, we all agree on the most important features. The diversity that you mention is good: libraries focus on a concrete set of features and it might well be the case that some use cases are not supported in a Platform module but in a library. In my view, it’s important that these libraries continue to exist because supporting all the features of a concrete domain is tricky (and sometimes impossible). On the contrary, developers of libraries whose overlap is big have now the opportunity to gather and work together, while getting help and contributions from Scala developers.
Have a look at this comment. Those are just some ideas but let me know if you have better ones .
To add to @jvican’s answer: various docs of the Platform suggest that multiple platforms can exist, reusing the same toolkit. So, assuming different toolkits make sense for different situations as you suggest (maybe yes, maybe not*), people could build different platforms for that—but that’s entirely up to them. Whether they should is another question, not for me to decide (let’s first, dunno, wait to see what is included or not).
*Maybe the default should be, say, Scala.js-compatible to ensure portability. Or not.
If the Scala Platform is just a collection of libraries (for education, etc), one could just publish a jar and be done.
If the Scala platform is trying to standardize a suite of libraries, having a custom build process, stability requirements, C4, etc, makes sense, but I’d argue against it. What’s the difference between the “Scala Platform” and the “Lightbend Platform” or the “Typelevel Platform”, for example?
But I doubt further discussion holds much utility. You’ve already done a lot of work, so I’ll step back as a skeptic and let time decide.
Just a small comment on this. There is no value in a published jar that is not maintained. I would personally not like to depend on an artifact with no support and documentation whatsoever. Our goal is to have a maintained Scala Platform. This is the true challenge of this initiative! We cannot achieve it without giving some incentive to library authors: a custom build process, governance rules, stability requirements, and infrastructure in general, plus growing the community around the modules.
Our terminal goals, I would say. However, I also prefer to let time decide and see how the Scala Platform evolves with and by our Community members. I cannot speak for something that doesn’t exist yet!
I’m not sure I agree with this statement. I’m fine with using a simple library that “just works” so long as the author releases versions compiled for new versions of Scala. But I don’t necessarily care if the library isn’t getting new features monthly, for example.
In fact, I think that’s a rather toxic metric for determining whether to use a project. Just looking at how often people commit to it doesn’t mean it is or isn’t stable or that it’s even evolving.
Yes, it’s not good to have something completely abandoned in the platform. But I don’t think it’s required that the libraries that are in the platform are rapidly getting new features, etc.
Indeed, but releasing versions compiled for new Scala releases requires tweaks from time to time and a maintainer keeping an eye at the library. My definition of unmaintained is really abandoned, in which no maintainer will take care of updating the project. To make it clearer, I rephrase my previous statement as: “I would be careful to add an unmaintained library in a long-term project that I know I will need to maintain”.
Really, this is a fairly subtle question. While I agree with both Heather and Jorge here, there’s also the reality that the community and its expectations change over time. Libraries that seem to be “done” can turn out to be insufficient a couple of years later, once the state of the art has moved on. (Indeed, one of my libraries on the Scala.js side is precisely a replacement for one that looked “done”, but proved to need a revamp once we understood the problem better.)
I’m not terribly worried about it, but it does strike directly to the core of the question of who has the right to update a library. While I prefer that the original author of a library is at least a sort of first among equals regarding its evolution, issues like this show why we need ways for Platform libraries to be picked up by others if they are stagnating too much…
.