F# Asynchronous Workflows - Experiences with Axum

Question

Hi,

Not sure if this has been asked, but I was just reading a blog spot on F# Asynchronous Workflows and became curious with the state of F# vs Axum for concurrent / parallel applications:

http://blogs.msdn.com/b/dsyme/archive/2007/10/11/introducing-f-asynchronous-workflows.aspx

I have no real question, just curious if anyone has had any experience with the two; any differences or similarities; is Axum going to head away from C#-ish to F#-ish language styles; will concepts in Axum be merged into F# etc.

Sorry for the ambiguity, I currently don't have the time to learn F# to then use it with Axum on my own :(

Cheers,

Adam

Answer 1

Adam,

I've actually spent quite a bit of time with F# async workflows and even played with a version of Axum that used ML syntax instead of C-style syntax. It's pretty sweet, and I actually like the ML syntax quite a bit. In particular, F# workflows used with F# mailboxes are similar to Axum agents (without mailboxes, they are more like asynchronous methods in Axum).

A couple of differences:

1. F# has no isolation concept -- mailboxes are like agents, but you can send them anything you want, including references to mutable objects. Thus, there is no protection against data races.

2. F# mailboxes are for in-process use only, so to go distributed you have to use a completely different methodology and different APIs.

3. There are no schema types in F#, so efficient in-process serialization is up to you.

4. No channels, no protocols. F# mailboxes follow the "single-inbox" style of actors, which I find very complex to program. Channels make messaging orchestration much easier. Protocols make things safer and catch errors close to the source.

There's a lot to like about F# and its asynchronous workflows, including the mailbox API. One of the biggest advantages it has over Axum is that it's already shipping and you can use it in your production software today.

Niklas Gustafsson