(pulling you away from monads and towards another kind of framework) you may be interested in missionary: https://github.com/leonoel/missionary

Have you read this post? https://grishaev.me/en/no-monads/

@U8ZE1VBSS I am, thank you! I'm still going through the video & repo to check for reliability, but it seems to be a good default for organizing asynchronous code (and presumably can wrap code with go/thread blocks if you need to violate its thread-interaction assumptions).

@UK0810AQ2 Yes, that was one of the articles motivating me to ask for alternatives rather than just ways monads might be useful. Granted, I don't agree with his dislike of integrating ideas from other languages/paradigms, as if your language is flexible enough and gives you the power to isolate their scale there should be little-to-no cost and at least moderate benefit from doing so. And wrapping your code in exception-handlers is essential, but will always be an approximation unless you know exactly what kinds of issues you will run into, in which case you could just fix them and there wouldn't be any point to the exception handlers either. But the article makes good points regarding the rigidity of monads and their partial dependence on non-dynamic typing (which seem to be the reasons for their being too complex to be maintainable by a moderate-sized team, another important point he made).

I think one general alternative could be protocols and extending them to types. The types provide the context and protocols provide the behavior