Extract Schedulers into a separate deployable module

[jozic]

Motivation:
Looks like Schedulers can be extracted to a separate dependency-free module, that can be used without Observables, Tasks or various Effects. Just as a light Scala-friendly replacement of Java's ScheduledExecutorService which also has control over clock! and thus has proper test implementation (TestScheduler).

monix-execution has dependency on cats-effect and reactive-streams which while doesn't disqualify it from using in "only Scheduler" use cases, but makes it much less attractable.
I believe this can benefit Scala eco-system in general

[oleg-py]

It's probably more sensible to remove cats dependencies from monix-execution. Of which we currently have:

• Scheduler has methods for building Timer, ContextShift, etc. from cats-effect. We use these for tests, and twice in TaskApp to piggy-back on IOApp. I think these can be moved to monix.catnap.syntax, given we already have that import.
• Cancelable.fromIO. We use it two times in tests for itself and once in implementation of IterantToReactivePublisher. Could be inlined-ish here and forgotten.
• CancelableFuture cats instances. I haven't seen it used in wild (at least yet, because monix 3 is still RC). We can move this to catnap or just drop it and rely on polymorphic methods of CancelableFuture to preserve its cancelability plus standard instance for Future in cats.
• ParallelApplicative (internal) - used in monix.tail, can be moved to catnap
• Contravariant for callback types. We can probably just add contramap in case somebody wants it.
• UncaughtErrorException can use Show instance for customization purposes. In Monix it defaults to Show.fromToString in places where it's used (which is Callbacks, yeah) and it cannot be overriden by user, so we can drop it.

reactive-streams dependency is just four interfaces and no extra deps. I don't think that's a problem at all, compared to dependency on cats + cats-effect.

The rest of execution package are bits and pieces that are sort of "why not" kind of thing for people not using FP:

• Atomics with more Scala-esque API and padding support
• Cancelables. Not super useful, but it's part of Scheduler API anyway.
• Bunch of future utils: queue, MVar analog, semaphore, Local
• Various internal bits: Unsafe annotations, custom exceptions, platform-specific mutable collections, etc. These can be moved out, but it's probably not going to change a lot.

[jozic]

getting rid of cats-effect as a dependency can do the trick I guess

@oleg-py could you turn your list of things to achieve this to a list with checkboxes? Then we can take care of them one by one and probably in parallel

[alexandru]

Getting rid of Cats and Cats-Effect from monix-execution is the right thing, I never liked it, but getting rid of it isn't an easy task.

Scheduler has methods for building Timer, ContextShift, etc. from cats-effect. We use these for tests, and twice in TaskApp to piggy-back on IOApp. I think these can be moved to monix.catnap.syntax, given we already have that import.

I don't really like added syntax. I guess we could, but we need a bunch of simple functions. Lets have an object EffectEnv in monix.catnap to have these functions.

Cancelable.fromIO. We use it two times in tests for itself and once in implementation of IterantToReactivePublisher. Could be inlined-ish here and forgotten.

Indeed, not very valuable.

CancelableFuture cats instances. I haven't seen it used in wild (at least yet, because monix 3 is still RC). We can move this to catnap or just drop it and rely on polymorphic methods of CancelableFuture to preserve its cancelability plus standard instance for Future in cats.

This is a problem. The point of having instances for CancelableFuture is to preserve the type.

Suggestions welcome.

ParallelApplicative (internal) - used in monix.tail, can be moved to catnap

👍

Contravariant for callback types. We can probably just add contramap in case somebody wants it.

👍

reactive-streams dependency is just four interfaces and no extra deps. I don't think that's a problem at all, compared to dependency on cats + cats-effect.

This dependency is also extremely stable and will eventually vanish once everybody moves to Java 9, but that's probably another decade.

---

On what else the monix-execution project contains, I'm against moving anything out of it.

We can probably split it at some point, e.g. into monix-execution-atomic, monix-execution-scheduler, etc, but that's too much of an undertaking right now and I don't think it's worth it.