Hi. I am in the process of moving from Try to IO i...

# arrow

[Satyam Agarwal]

Hi. I am in the process of moving from Try to IO in my web app. but the whole stack is built upon that. Basically Try wraps my network requests. Since its a big project moving to IO will not be easy. So I want to do it in steps, And thinking this is how I will do the migration.
1. Replace Try { … }.toEither() with IO { … }.attempt().unsafeRunSync() in the clients/repositories
2. Start Replacing Either from services with IO and remove unsafeRunSync() and bring it to services.
3. Eventually remove unsafeRunSync() and bring them finally to controllers.
4. And finally get rid of springboot ❤️
I have worked with unsafeRunSync before in production for very small things (mostly one time things like migrations, imports/exports where I couldn’t do without springboot 💢), so I am comfortable and have not seen any problems, but with above, my apis can get affected, consequently my user-base.
I am basically wondering about this line from doc

**NOTE** this function is intended for testing, it should never appear in your mainline production code!

Can you guys help me with deciding if this makes sense and is sane thing to do, and what kind of problems I can see with this approach.

[simon.vergauwen]

Hey Satyam Agarwal,
The reason that line is there is you should never block threads in an application. Instead you should always prefer to semantically block which in Kotlin is possible through suspend().

If you require blocking the Thread to await the result unsafeRunSync is fine, but like you already mention in your migration plan you will always prefer to avoid that.

[simon.vergauwen]

That being said suspend fun controllerEdge(): A = ioOfA.suspended() that would also work on the edge of your controllers.

[simon.vergauwen]

We’re also working on including E into IO so in the future you’ll also be able to do suspend fun controllerEdge(): Either<DomainError, A> = ioOfA.suspended()

[simon.vergauwen]

Or in other words.

suspend () -> A == IO<A>
suspend () -> Either<E, A> == IO<E, A>

[simon.vergauwen]

So that way you’ll be able to describe programs in an exception safe way, while keeping your error domain seperate from your exception domain while guaranteeing automatic resource safety, exception and cancelation handling 🙂

[Satyam Agarwal]

yes. I’ve following up on your plans very very closely so I am already catched up on this. Thanks a lot for helping me out.
I cannot avoid blocking threads, because the moment I do unsafeRunSync() , its blocked.
However, since the whole application is synchronous, and eagerly evaluated, it shouldn’t matter right ?
I am not so good at threads handling.

[simon.vergauwen]

Yes, then it will not be a problem.

[Satyam Agarwal]

Awesome. Thanks a ton again 🙂