What I offer
One idea runs through all of it. What code does to the world (a call, a read, a write, a payment, a model query) becomes an explicit operation, and a handler carries it out. That gives each action a place where it can be seen, tested, controlled and recorded, and the logic around it stays as it is.
1. A way out of tangled code, one step at a time
Wrap the code's dependencies as effects at its existing seams. The logic keeps its shape and becomes testable with handlers instead of mocks and containers. Then improve it piece by piece, and split it into services along the same boundaries when that pays. okay-simple is one interface for Scala 2.13 and Scala 3, from 3.3 LTS on. One application can mix code compiled by both, so an upgrade happens module by module, not in one big step.
2. One interface over ZIO, Cats, kyo, fs2 and monix
Teams keep their libraries, and their code meets in one program. Below, a value comes from a ZIO service, goes to a cats-effect service, and its answer goes back to ZIO. ZIO's tasks and Cats' IO are two effects of one row.
One handler runs each IO as a ZIO task, so the whole program becomes one ZIO, run by ZIO's runtime. The same program could become an IO instead: only the handler would change.
import zio.{Runtime, Task, Unsafe, ZIO}
import cats.effect.IO
import cats.effect.unsafe.implicits.global
import okay.effects.*
import okay.effects.std.*
import okay.effects.ziointerop.*
// ZIO's tasks and cats-effect's IO, in one row
type IOs[X] = Lift[IO, X]
type Both[X] = (Tasks + IOs)[X]
def loadUser(id: Int): Task[String] = ZIO.succeed(s"user-$id") // a ZIO service
def riskScore(user: String, amount: Int): IO[Int] = IO(amount / 100) // a cats-effect service
def decide(user: String, score: Int): Task[String] = // a ZIO service again
ZIO.succeed(if score > 50 then s"$user: review" else s"$user: approve")
// one program: from ZIO, into Cats, its answer back into ZIO
def check(id: Int, amount: Int): String ! Both =
for
user <- fromZIOTask[String, Both](loadUser(id))
score <- lift[IO, Int, Both](riskScore(user, amount))
decision <- fromZIOTask[String, Both](decide(user, score))
yield decision
// one handler: each IO run as a ZIO task, so the whole program is one ZIO
def ioAsZio[A](p: A ! Both): A ! Tasks =
handleLast[IOs, Tasks, A, A](p, new Handler[IOs, Tasks, A, A]:
def ret(a: A) = pure(a)
def op[X](op: IOs[X], k: X => A ! Tasks) = op match
case Lift.Of(io) => fromZIOTask[X, Tasks](ZIO.fromFuture(_ => io.unsafeToFuture())).flatMap(k))
// the result: a ZIO, run by ZIO's runtime
val zio: Task[List[String]] = toZIOTask(ioAsZio(for a <- check(7, 2500); b <- check(8, 9000) yield List(a, b)))
Unsafe.unsafe { implicit u => Runtime.default.unsafe.run(zio).getOrThrow() }
// List(user-7: approve, user-8: review)
Compiled and run against the released 0.1.0 (okay-effects-zio, with cats-effect) on Scala 3.3 and 3.9.
More is available: a ZIO's environment, typed error and run as standard effects, with its layers and cancellation in both directions; ZIO's own types as effects; cats' Monad for any program; kyo, and fs2, ZIO and monix streams both ways. See interop.
3. Scala 3 and algebraic effects on Spark
Spark jobs in Scala 3, today: Scala 3 types, enums and sums included, become DataFrames, where Spark's own encoders do not compile in Scala 3 (how). Business rules written with effects run inside Spark's tasks (how). A Spark job written against Bulk runs on a cluster or in one JVM with the same answer, so its logic is tested without Spark. Scala 3 types become DataFrames through SparkSchema. Every output can come with evidence: per partition, a count and a SHA-256 digest, committed only after the sink acknowledges it. The details are below.
4. Monitoring, control and audit as part of the code
An interceptor sees each operation of an effect and can record, change or refuse it. An observer sees every operation of every effect. A sensitive effect, such as payments, cannot run outside its audit, and the compiler checks that. okay-audit checks in the bytecode, at every build, that business code reaches the outside world only through declared effects.
A policy is changed in one handler, not across the codebase. See what this means for compliance.
5. One transparent system across platforms and languages
The same design exists for Java, Go, Rust, Python and TypeScript. okay-kernel is a protocol between them: a program written in one language runs under handlers written in another, in one process or over a wire. In the demo, a shop written in Go has its inventory, payments and mail answered by Scala handlers. Every operation that crosses has a name and a type, so the controls above apply to it wherever it came from. The whole company's software can be watched, limited and audited at one point.
