Consider moving async/await DSL to a microlib until stabilized?

[djspiewak]

The advantage to having it in core is it's very discoverable. However, if people actually discover it and start using it (which is what we want!) then it becomes pretty painful to change, even with our "Experimental!" label. This reminds me a lot of the situation with Future, which incubated in Akka for a long time before it was moved into the Scala standard library. Doing something similar with async/await feels like a better choice, since then downstream users can adopt it without fear of it randomly changing out from under their feet in a minor point release of CE.

Concrete proposal:

• Keep the documentation you wrote and add a little header for a copy/paste dependency (kept up to date with new versions!) on the microlib
• Microlib under the typelevel org so people trust it (cats-effect-cps? dunno)
• Make it clear in the microlib readme and in the main CE docs that when the microlib is ready to go 1.0, it'll be pulled into the CE core
• Success criteria on microlib is that people adopt it (I don't expect any problems there; people seemed very jazzed about this on twitter), we ideally find a way to make it work on Scala 3 as well as Scala 2, and we're confident the API is stable

So the goal will always be to have it in the core, but while we're futzing with it (and also sorting out the Scala 3 story), having it on the side allows us to break things fearlessly without impeding adoption of the syntax.

[Baccata]

The plan makes sense to me. As long as I don't have to worry about setting up build/CI, I'm happy to move my relevant contributions over to a microlib.

[rossabaker]

What is the advantage of a microlib over dropping the module from MiMa enforcement and putting a <marquee><blink><font size="+7">No bincompat guarantee</font></blink></marquee> in the docs? Seems like a pain, unless you're planning independent release cycles until it stabilizes, in which case this makes sense.

[Baccata]

What is the advantage of a microlib over dropping the module from MiMa enforcement and putting a No bincompat guarantee in the docs

1. People don't necessarily read the docs. I'm certainly guilty of this (whilst being reasonably proficient with CE/fs2) Maybe one person will read the docs, use it at $work, then other coworkers will start copy it.
2. In terms of user trust, I kinda agree with keeping the foundational library as stable as possible. The mental association of "everything from the typelevel/cats-effect repo is uber stable" is desirable.

Seems like a pain, unless you're planning independent release cycles until it stabilizes, in which case this makes sense.

My understanding is that the release cycles would be independent, and that the CE docs would retrieve the latest "ce-async-await" version via coursier magic (either at build-time or within the browser's runtime).

[djspiewak]

I would expect we're going to want independent release cycles. Also think about Scala 2 macros as an example. They were folded into the core as an "experimental" feature, but they still represent a PITA on upgrading between major (and sometimes minor) versions because people have adopted them as if they were as stable as the primary core.

I want to give downstream users the ability to update CE versions without having to take on a breaking async/await change, and also for async/await to release new changes quickly and easily.

And no one reads the docs. :-)