Microsoft Incubation Project: Axum (Formerly Called "Maestro")¹

Axum is a new programming language that builds upon the architecture of the Web and principles of isolation, actors, and message-passing to increase application safety, responsiveness, scalability, and developer productivity. Other advanced concepts the Axum team are exploring are data flow networks, asynchronous methods, and type annotations for taming side-effects. Axum shares syntax similarities with C#, C++, and C; but most closely C#. Axum can be used with other .NET languages, and it can call methods, use types, do processes, etcetera with your own .NET Framework projects. Axum' foundation is the .NET framework and the CLR.

Why Axum?²

Writing a parallel program typically requires partitioning the solution into a number of parallel tasks. Some problems are easily amenable to parallelization because the tasks can run independently of each other. In other problems the tasks have interdependencies and require coordination.
For example, ray tracing, a method of generating an image by tracing light’s path yields itself to a parallel solution because each ray can be implemented as an independent task – processing of one ray has no effect on the processing of another ray.

On the other hand, in a game-play simulation, the game is modeled using parallel but interacting objects. The state and behavior of an object have impact on the objects around it.

Axum offers a language that allows programmers to arrange coordination between components in a way that is close to their natural conception of the solution. In other words, if you can model your solution in terms of interactive components, encoding it in Axum will be straightforward, and you will likely avoid many common concurrency-related bugs.

An obvious motivation for writing a parallel program is to make it run faster. Closely related to that is a desire to make the program do more while it’s running. This is especially important for interactive applications that must process user input while performing a background task.

Very often, responsiveness of interactive applications is hindered by long-latency components such as I/O or user input. For example, an email client must wait for the data from the server, which might be behind a slow network. It is desirable that such an application remains responsive while requesting data from the server.

One of the goals of Axum is to let you program without worrying about concurrency – your program becomes fast and responsive by default, not as a result of an afterthought or a retrofit. In addition to enabling the new capabilities for working with concurrency, Axum takes away one capability that historically has proven to cause problems – that is unrestricted ability to share and mutate state from different threads. Axum isolation model ensures "disciplined" access to shared state that prevents many common programming errors.

Finally, remember that Axum is an experiment. The Axum team wants to make it better and they need to know what you think. Comments about the language, and how you think you can use it for building your own software are desired by them. Please share your thoughts, comments, and suggestions with them and your fellow Axum users at the Axum Forums.

Links & Downloads

Axum at DevLabs
Axum Team's blog
Axum Programmer's Guide
Axum Language Specification
Axum Lite (Command Line)

State of Axum and its Direction³

Currently, there are no paid developers working on the Axum incubation project, but feedback is still welcome. Microsoft might release it under a license. See more here.

Update

See this page.

Footnotes

¹ Content derived from http://msdn.microsoft.com/en-us/devlabs/dd795202.
² Content is from the Axum Programmer's Guide.
³ Info from the most recent blog post from the Axum Team's blog.