Best .NET language for Concurrent programming

Question

This may be a question that others have seen, but I am trying to find the best language for concurrent programming that can run on the .net platform.

I have been doing side development in erlang to get a feel for the language and have loved how easy it is to get a stable concurrent or even distributed system up. It led me to scala which also had a nice system using actors, however scala.net does not seem to have this functionality currently (Granted this is a concurrent system vs a distributed system). The two .net languages I was looking at are Axum and F#.

My question is if there is anyone that has done extensive development in Axum and what their feeling about it are, and if there is anyone that has done any F# concurrent & distributed programming?

(To Clarify I mean the best language, that runs on the .net framework, to write concurrent applications)

Answer 1

Axum is a research project. A real research project, where only ideas from it will end up in products. (Unlike F#, which was productized as a whole.) I'm not even sure the license allows using it to develop production applications.

F# is a fine choice.

Clojure also runs on the CLI, and is a good choice, too.

The CLI port of Scala is currently in the process of being resurrected (with officiall funding from Microsoft, actually), and Scala's Actor libraries (both the built-in one, as well as Akka) are pretty good.

Regarding @wmeyer's comment above: Scala itself doesn't have any provisions for distributed programming. (Neither does Clojure.) Both generally rely on the myriad of Java frameworks that exist for that purpose, such as Terracotta. However, Akka does have Remote Actors for distributed programming, and Akka is largely API-compatible with the built-in Scala Actor library, which allows for a smooth transition.

Erlang would be kind of cool. Kresten Krab Thorup is currently working on Erjang, an Erlang implementation on the JVM, and he has some pretty impressive results: running on HotSpot, Erjang scales comparably to BEAM, sometimes even better. For example, in the (in)famous process-ring benchmark with 10000 processes, Erjang starts up only minimally slower than BEAM, but when you repeat the run several times and the JIT kicks in, it overtakes BEAM after about 3 runs (and curiously, BEAM starts slowing down after 4 runs).

I'm pretty sure you could build an "#rlang" on the DLR and the TPL that performs equally well.

Answer 2

I am actually using F# to do both concurrent and distributed programming right now. I think it is working very well. Union types make it easy to define statically-typed messages. .NET serialization is too slow for us but replacing it using custom parser and unparser combinators was easy and performance is now good enough. Asynchronous workflows and mailbox processors make it easy to pass messages around easily. Type inference means my entire code base is tiny and easily maintainable.

Answer 3

I think that Jörg already answered your question about Axum (and I don't know much about it), so I'll just add a couple of things about F# - one thing to note is that F# isn't really a concurrent language. It just has good libraries for doing parallel development. The most notable options are:

• Task Parallel Library and PLINQ which are available in C# too, but may look a bit nicer in F#, especially if you use immutable data types. There are some nice F# examples of using these two in Parallel Programming with .NET and I wrote a blog post about the F# version.

• Asynchronous workflows are not essentially designed for concurrent programming - they allow you to write non-blocking code in general (which is quite useful in concurrent programming) and they allow you to write computations that can be started and managed. You can use them for:

  • Task-based parallelism (a bit like Task Parallel Library) using StartChild method
  • Data-parallel computations using Async.Parallel
    _
• Agent-based programming using the MailboxProcessor type from F# allows you to use message-passing concurrency that is quite similar to Erlang. It is based on asynchronous workflows, which gives you some benefits (e.g. waiting for a message is non-blocking).

In summary, I think it is more important to choose the right parallel programming model for your task than the language used to encode it - as long as the language gives you enough power to encode the programming model. In this case, the programming model shapes your mind more than the language. Axum is based on the actor (message-passing) model, so I think that with some effort, you could wrap F# agents to look quite similar to the Axum API.