A .NET language with asynchronous, message-passing concurrency based on actors. Neither the website nor the programmer's guide mentions Erlang at all. Interesting.

From the programmer's guide, it looks like it has a loosely C++-like syntax, rather than the Prolog-descended syntax that Erlang uses; while I can't say I'm a fan of Erlang's syntax, I don't see any syntax for pattern matching. That would be a big loss.

I don't use .NET myself, but what I like about it is the availability of multiple languages for the CLR. I find very alluring the possibility of mixing and matching languages according to the task at hand without having to deal with IPC.

I could really find usages for actor-based concurrency, but using Erlang seems to me like throwing the baby out with the bathwater.

I like the way it allows you to specify protocols directly as state machines...

Having a own language only for COP (Concurrency Orientated Programming) is fine. Heck I'm a polyglot fan. Though I wonder if the way of STM (State Transactional Memory) wouldn't have been a better choice to boost the already existing languages for the Multi-Core problem. (See e.g. Haskell)

As far as I know all STM implementation on .NET are experimental, right?

Erlang as a true COP language has its advantages, and so will "Axum" but Erlang is already quite a long time around. Wonder if they can catch up. Especially due to OTP and CEAN.

what do you think about this project? (extend and embrace all over again?)

why would someone use axum over hypertable and thrift?

what is the performance trade off between axum, hypertable, and hadoop(hbase).

Given how Axum looks very much like C# with added keywords and constructs, and how most of the functional aspects of F# either got into or is getting into C#, my guess would be C# is getting some neat concurrency-addons in upcoming revisions.

Either that, or it will simply get dumped. I can't see how it would make sense to maintain these two branches separately.