Seeing how there's raise in actor-based solutions, I'm a bit confused about the lack of F# libs that use something like the stock MailboxProcessor as the API.
What's the downside?
Why deal with constrained capabilities and the overhead of wrappers?
Are there any F# APIs that use an agent as the first-class API instead of implementation detail?
I'm talking about non-blocking concurrency with desired side effects scenarios. Especially the cases when a lib already uses something like MailboxProcessor under the hood, but defines wrappers around the communication protocol (which could be nicely defined with DUs).
I guess the message passing upsides are in the eye of beholder, but I think Erlang and Scala show that functional goes together with Actors rather nicely. There are even Haskell implementations, so it's not a question purity, but rather of style.
When I say the wrappers are constrained, I mean:
protocol duplication (wrapper + underlying messaging). It's ok if all you expose is one method, but often times it's not.
explicit capabilities duplication (fire-and-forget, async with result, sync, etc). Covering every possibility with a wrapper would result in unnecessarily bloated API, while not covering it - actually remove the capability.
non-standard set of verbs, reducing ability to compose.
Assuming you are not against actors on principle, what are the downsides of using MailboxProcessor as the standard API for implementations involving non-blocking concurrency?