As an indication of the renewed interest in Actor-based concurrency, Microsoft recently started incubating an experimental language for working with Actors on the .NET runtime. Code-named Maestro, the language targets a wide variety of programming problems where process isolation and fault tolerance is important in concurrent processing.

In a recent blog post, Introducing Maestro – A DSL for Actor Based Concurrency, Matthew Podwysocki describes the motivation for Maestro:

Maestro is not just another general purpose object oriented language for .NET, but instead a subset of language features which allow for easier isolation and concurrency within that isolation. You could think of it more as an actor-oriented language instead with constructs for model coordination and message passing between components...

While other projects have already addressed Actor-like concurrency on the .NET runtime, Podwysocki believes that Maestro goes further in providing true process isolation:

The problem with some of the .NET solutions is that they don’t go far enough into memory isolation and channel contracts as to what can and cannot happen. In order to enforce such a behavior, we need some sort of static analysis... Of course with static analysis, it could be ignored and might not be as type rich as, say a DSL. And that’s where Maestro comes in...

According to Podwysocki, Maestro is based on the following core concepts:

• Process Isolation: Each component is an isolated machine that works in parallel and does not share resources. Any inter-component communication must be communicated through an explicit request and a narrow channel...
• Message Passing: (...) In order to communicate, typically we serialize the message contents and send to the subscriber. If light-weight, they can be a highly scalable approach to concurrency.
• Fault Tolerance: Typically, in shared-state applications, detecting and dealing with concurrency and failure is a complex task. However, if we work in isolated state, any potential failure can be limited to the component...
• Loose Coupling: When designing for reuse and maintainability, using shared state concurrent components can be difficult due to the exacting nature of knowing about locks, mutexes, semaphores and so on. Instead, with message passing and isolation, components can interact with each other through narrowly defined channel contracts.

What do you think of Maestro's approach to fault-tolerant distributed computing?