I'm looking into combining Arrow (possibly Fx?) wi...

# arrow

[mattmoore]

I'm looking into combining Arrow (possibly Fx?) with JetBrains Exposed library. Any resources or best practices/recommendations around this?
I've found this, but not sure what state it's currently in: https://github.com/codebandits/beak

[raulraja]

the issue with that lib is that it’s not treating those as effects

[raulraja]

Since this follows JDBC style and it’s blocking you probably want an IO like dispatcher for blocking style ops. Then all those ops would need to be suspend or in IO

[raulraja]

The upcoming IO has also E so you don’t need Either.

[raulraja]

beak should probably be designed around IO and be offered in the Arrow integrations or similar so we can advance it together as Arrow and IO become stable. /cc @leonhardt

[mattmoore]

Curious...what's E in the upcoming IO? I was able to use Either with IO via .attempt() which seems to work quite nicely, similar to Scala/Haskell.

[Jannis]

It is a separate typed error channel. IO<A> in relation to errors has two states A or Throwable . With IO<E, A> you get control over the error type which means you can raise and handle custom exceptions easier (they don't have to be Throwable . It also tells a caller what errors to expect and in case of IO<Nothing, A> to not expect any errors. The possible states (in regards to errors) for IO<E, A> are E , A or Throwable . Throwable here explicitly marks unexpected errors, whereas E marks expected errors. (expected as in the caller should in some way handle those errors consciously, whereas a Throwable is probably only handled by a catch-all like handler). If you are familiar with mtl IO<E, A> = EitherT<ForIO, E, A> = IO<Either<E, A>> , though the more you go down to the concrete type IO<Either<E, A>> the less nice interaction with that datatype is going to be. Using IO<E, A> will always be easier than the equivalent EitherT or IO<Either<E, A>> code.