4

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?

4

The F# MailboxProcessor is essentially an in-memory queue in front of a single-threaded loop. While this definitely makes it easier to program 'concurrent' systems that need to manipulate state, it has the following disadvantages:

  • Runs only on a single thread
  • Overhead from synchronisation

The Actor model is a sane approach to stateful programming. When you need it, it's much preferable to approaches involving threads and locks.

F#, though, is a Functional First programming language, and most of the F# libraries I've come across take that seriously. They emphasise side-effect queries over stateful programming, which often make their APIs embarrassingly parallel. When you have something that's embarrassingly parallel, there's no reason to put it on a single thread.

| improve this answer | |

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.