dotty-cps-async VS Scalafix

Now in scala we have direct mode transformers: dotty-cps-async [https://github.com/rssh/dotty-cps-async] with cps-async-connect [https://github.com/rssh/cps-async-connect ] supports all well-knowm monad stacks, for ZIO also exists ZIO-direct [https://github.com/zio/zio-direct ] , for IO - cats-effect-cps [https://github.com/typelevel/cats-effect-cps ], for kyo [https://github.com/fwbrasil/kyo ] - kyo-direct.

dotty-cps-async: https://github.com/rssh/dotty-cps-async

Hmm, you can write direct-style code with monad: https://github.com/rssh/dotty-cps-async allows this, exists support libraries exist for near all well-known effect systems: https://github.com/rssh/cps-async-connect, so you can use async/await with IO/ZIO the same as with Future. Although in IO style, any operation that mutates state is async, it's hard to write code where you should place `await` near each line. And it looks like automatic coloring is a too radical change of concepts for most functional programmers. The option to allow using <- in the direct style may be more popular, but this requires changes to the scala core. Another question - are we need effective systems to be present in each program in industrial-style development? Here I agree that mostly no.

This is a generic async/await transformer for scala3 which allows using effectful monads in the direct style. URL: (https://github.com/rssh/dotty-cps-async )

dotty-cps-async [rssh/dotty-cps-async ] with automatic coloring do something very similar in two steps. Automatic coloring defines implicit conversion F[A] => A as x => await(x)(m). The compiler inserts those awaits inside async blocks and then eliminates them later via cps-transform. Exists some limitations which we need to add for effect monads like IO (we don't want run effect twice and don't want to screw semantics of effects by extra memoizing). So, if your language has a possibility to implement effect monads, then you need a possibility to restrict using Flattenable.

I also recommend using Scalafix. It's a tool which can lint your codebase, checking for potentially problematic things, like

Scalafix

scala-fix seems relevant for the /= removal problem.

or `NonUnitStatements` without explicit annotation.

This effectively locks you into writing pure code (you can extend the linter to cover other things like not using `Future` or not using Java libs outside of `MonadError` from cats[4]). The linters operate on typed ASTs at compile time, and have plugins for the most popular scala build tools. Coupled with `-XFatalWarnings', you can guarantee that nothing unexpected happens unless you explicitly pop the escape hatch, for the most part.

You can still bring in external libraries that haven't been compiled with these safties in place, so you aren't completely safe, but if you use ZIO[5]/Typelevel[6] libraries you can be reasonably assured of referentially transparent code in practice.

There are three schools of thought, roughly, in the scala community towards the depth of using the type system and linters to provide guarantees and capabilities, currently:

1) Don't attempt to do this, it makes the barrier to entry to high for Scala juniors. I don't understand this argument - you want to allow runtime footguns you could easily prevent at compile time because the verifiable techniques take time to learn? Why did you even choose to use a typesafe language and pay the compilation time penalty that comes with it?

2) Abstract everything to the smallest possible dependency interface, including effects (code to an effect runtime, F[_] that implements the methods your code needs to run - if you handle errors, F implements MonadError, if you output do concurrent things, F implements Concurrent, etc.) and you extend the effect with your own services using tagless final or free.

3) You still use effect wrappers, but you bind the whole project always to use a concrete effect type, avoiding event abstraction, thus making it easier to code, and limiting footguns to a very particular subset (mainly threadpool providers and unsafeRun or equivalent being called eagerly in the internals of applications).

My opinion is that smallest interface with effect guarantees (#2) is best for very large, long maintenance window apps where thechoice of effect runtime might change(app), or is out of the devs' control (lib); and #3 is best for small apps.

TL/DR; You can go a really, really long way to guaranteeing effects don't run in user code in scala. Not all the way like Haskell, but far enough that it's painful to code without conforming to referential transparency.

1. https://github.com/scalacenter/scalafix

2. https://github.com/scalaz/scalazzi

3. http://www.wartremover.org/

4. https://typelevel.org/cats/api/cats/MonadError.html

5. https://zio.dev/

6. https://typelevel.org/

I actually still recommend using WartRemover, at least until there's an equivalent ScalaFix ruleset that's as effective.

Probably linting rules defined in Scalafix. See https://github.com/scalacenter/scalafix/blob/master/scalafix-rules/src/main/scala/scalafix/internal/rule/DisableSyntax.scala#L11 for an example.