@mdedetrich you gave the example of FS2 which is undergoing a painful transition to Cats.
It’s not necessarily a good example for the necessity of having a
Task in the standard library, because that transition to Cats would have happened anyway and it would have been painful anyway, because the availability of a
Task isn’t the only problem that a library like FS2 has.
I think we have a problem of causality — if we have both Cats and Scalaz in the ecosystem with different implementations and community management, that’s because we cannot agree on how to best do things.
By including something in the standard library you’re basically forcing users to agree on one true solution. Sometimes that’s valuable, however that’s also the Microsoft-mentality of blessing implementations and of discouraging community-provided solutions.
Future is a success. The standard collections are a success. But this sampling is biased, because if we take a look at things like JSON / XML parsing, the landscape is filled with the corpses of failed implementations in standard libraries that nobody wants, but have to endure due to legacy code.
Speaking of which I don’t like the idea of the Scala Process that much — being basically about making the standard library more modular and expanding it with what are considered to be the needed batteries, which is good for adoption, but a SP project is stdlib nonetheless, with all the downsides that brings.
Personally I don’t believe in batteries included and pretty much ended up hating it in every language that was advertised as having batteries included, like Python or Java.