Should libraries used in open Lightbend projects be considered natural/initial candidates for the Scala Platform?

I’d love to see a well defined set of libraries that the community can look as being some kind of reference.

The page announcing the Scala Platform Process links to the proposal submission process where the first two steps depend on the community and the rest takes a formal committee path (sorry if it sounds like an oversimplification, but it is just to give a quick context for the idea here).

If we look at Lagom Framework for instance, it has a selection of libraries which cover a wide range of requirements on its scope and surely have been through discussions about different criteria to make their way into it.

Not necessarily whatever was selected there is sure to be THE library to be in the Scala Platform, but at least might be a seed to start the discussion and help us getting to a first platform version faster.

Given the current state of the discussions here after the platform was announced at the end of Nov/2016, I feel that it would be a helpful strategy to create one topic for each of the main requirements covered by the libraries in Lagom for instance, so we get start getting past through the first two steps of the process.

Not that we should create topics like “Add MacWire to the Scala Platform” with the content “Because Lagom uses it”, but “Define Dependency Injection for the Scala Platform” with a more elaborate content that might even mention that Lagom uses MacWire, but goes beyond and shows actual advantages like being itself written in Scala and how is that better than other popular solutions (like using guice) and so on.

What do you guys think? I believe it would work better than waiting for different individuals to post multiple lists of preferred libraries. Nothing against those, it is also valuable information about things known to work together, but I believe it adds overhead on those who will do the actual work of going from topic to topic and consolidating everything.

P.S.: I’m not a Lightbend employee nor a Lagom developer. Just an usually more silent community member trying to help with some ideas

What’s the general opinion on Lagom libraries? Is there some consensus? While Play or Akka are well-known, and pieces of Akka have even entered the standard library, I’ve only heard of Lagom because of the Lightbend announce. Parts of Akka are indeed likely good candidates for the platform.

Moreover, after some googling reminded me Lagom was a Java-first library/framework (https://github.com/lagom/lagom/issues/1, http://www.lagomframework.com/blog/lagom-scala-api-preview.html), I should ask: how much of Lagom (and dependencies) is written in Java? IIUC Java code doesn’t work currently on Scala.JS (or other Scala platforms), and supporting multiple platform is at least a concern to keep in mind.

All good observations. That is exactly why I wrote about the libraries used by it and not about setting itself as a platform library.

Coincidence or not, the two libraries/frameworks you mentioned, Akka and Play are both essential dependencies to Lagom and on a side note, Play 1.0 was also written in Java.

But again, my point here was not promoting Lagom or anything, but just to start a discussion about strategy using some publicly available project on the JVM ecosystem with a wide enough scope to use as the tip of the iceberg of features that one could expect to see covered in something to be called a platform.

The topic could be renamed to “Review the dependencies of a relevant project and check if or how much should be covered by the platform” and maybe that would still be a simplification of what I’m talking about.

I completely agree that we should not forget about Scala.js and maybe even Scala Native should count some points, but I would keep the options open about picking the best in class for each runtime, as some browser specific library might be the killer feature for Scala.js and at the same time irrelevant for a Scala server side.

You are right about not being possible to call Java from Scala.js, and even beyond that, due to some inherent differences in the underlying platforms AFAIK related especially to reflection and thread models, even pure Scala projects might have difficulties compiling to other runtimes, thus we might need to select an alternative library or a port (I haven’t used yet but I know there is an Akka.js project for instance).

About Akka and Play being part of the standard library, I believe scala actors where removed from the standard library as Akka became the de facto standard. Both are not standard library, but integral part of Lightbend Reactive Platform, which could actually be another target to the Idea I was trying to convey.

Another possible list to be checked is Awesome Scala, besides a couple of others I’ve seen in this discourse instance. At the end the main point is identifying what are the expected elements to be part of the platform and create separate topics to discuss them.

By the way, so people can easily find where they can contribute to discussions or suggest apparent missing things, is there some centralised list available somewhere showing the status for different modules of the scala platform (proposed, in review, etc)?

I think I agree with the general idea here, but I don’t see any reason to focus on Lightbend’s libraries. You can look at a number of popular Scala libraries/frameworks to find out what libraries they’re using, and use that as a starting point for additional discussion.

I agree with you on Macwire, or at least the general issue of having a standardized, simple way to do dependency injection. That of course is easy to see that it applies to pretty much every Scala application, not just the niche that Play or Lagom is meant to fill (server side web apps and services).

But there are other types of libraries where it’ll be harder to find consensus. Lagom and Play use play-json, but there are many other popular JSON libraries (json4s, argonaut, circe, etc.) used by non-Play users. To me it wouldn’t make sense to choose “Lightbend option” here without a specific technical reason.

3 Likes