Discussion Around Scala Native 0.5 Upgrade

[djspiewak]

All topics related to Scala Native 0.5 upgrade. Relocating from Discord (reference anchor). Delegate issues can be collected here: https://github.com/orgs/typelevel/projects/2/views/1

[djspiewak]

One of the things we need to decide is whether we are going to just publish a bunch of snapshots first and get everything working before the very first release, or if we're comfortable releasing some very slow-moving upstream projects (such as ScalaCheck). The danger here is it's a one-way door. If we release a full ScalaCheck against 0.5, we can't go back again and release a new ScalaCheck against 0.4.x. This could be a problem if the downstream ecosystem (say, Cats Effect) takes a really long time to upgrade to 0.5 and ends up needing some new fix in ScalaCheck on an older stable lineage.

So the safe thing to do is just snapshot stuff, but ScalaCheck is very much the root of the Scala universe, so we would unblock more people by releasing at least it (and possibly also Discipline).

[JD557]

I think it's a reference to some of the implementations in https://github.com/scalameta/munit/blob/main/munit/native/src/main/scala/munit/internal/PlatformCompat.scala. At least waitAtMost and setTimeout are not that great, even when running in a single thread.

Having said that, while some of the implementations there are a bit broken, I think they mostly work, so having an early release to unblock the rest of the ecosystem might not have been that bad

[djspiewak]

Idk. Seems to be just my opinion at this point 🙂 I am also disappointed that MUnit released for SN 0.5 without fixing any of the single-threaded assumptions baked in. It all feels very haphazard.

I agree this feels pretty haphazard. People seem to be in the mode of "let's unblock everyone first", and once that's done I suspect everyone will reconsider the multi-threaded implications. Unfortunately, I think relatively few people have thought through the API breaking effects to any depth, which in turn means that we're implicitly signing up for a breaking change mid-cycle on SN 0.5.

I'm not entirely sure how we want to navigate that. Very likely it's just going to be done as a minor version rev across the board and we'll handwave about the guarantees, effectively foisting the problem on downstream users.

[etspaceman]

Just casting a +1 to supporting 0.5 to unblock updates. I'm not sure if that has been decided, but I'd really like to not have to hold off on updates to items like munit until we figure out multi-threading.

[keynmol]

and once that's done I suspect everyone will reconsider the multi-threaded implications

With the way our build tools work these days, it's just incredibly easier to work on your own library's broken tests once all the upstream is published. And most of the core dependencies have been pretty good with frequent publishing.

So at this point the goal is to solve the "my library is 10 levels deep with unreleased dependencies" problem. Solving fundamental blockers unblocks the maintainer parallelism in the ecosystem, and then the fun part starts with removing single-threaded assumptions from native-only code. Of which I can imagine there isn't actually a ton of in most libraries.

[ekrich]

After thinking about this for awhile I am also +1 here to unblock 0.5.x because multi-thread is new anyway. This way there can be time for a future multi-thread release. Changes may be needed in 0.5.x anyway to make things work properly.

[mpilquist]

We're not supporting native 0.5 on cats-effect 2, right?

[djspiewak]

Yeah definitely not. Unless you want to shave some yaks for absolutely no reason.

[hamnis]

Perhaps circe/circe should be added to the board?

circe/circe#2254