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.
From the blog: "I don’t want to hand-wave and take credit for reaping the benefits of the web’s architecture on multi-core systems; none of these concepts are new – not even to Microsoft. Erlang is a language that has been around for years and has run many large incredibly scalable telco networks efficiently."
I don't want to be come across as knee-jerky anti-Microsoft (I haven't used .NET; I admit ignorance there), I'm just surprised that it didn't acknowledge the one example of an actor system that programmers are likely to have heard about. It seems like it would be useful for comparison.
Besides, Microsoft employs Simon Peyton-Jones, among others, and they fund serious programming language research in various ways. I'm not implying it's dishonest on their part, I just found it a bit odd.
Sure, having used (and appreciated) Erlang I agree it would be interesting (I'm not a .NET user either or likely to become one.) I'm not surprised they omitted it, though I won't speculate why.
I just think it's worth reinforcing that there are interesting actor systems other than Erlang, and that some of the people at MSR deserve some credit in the area.
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.
You are aware of the fact that there are also multiple languages for the JVM? For instance Scala has actors and can leverage any existing Java library.
Axum is different because it is designed for a specific domain by the same people that are designing .NET. This means changes to the CLR may be pushed forward to accommodate features in Axum. I don't know if the tail call instruction in the CLR was added because of F#, or because of the research they did while trying to compile Haskell on top of .NET, but it's there.
The problem with the JVM is that there isn't a centralized effort for those multiple languages. You can slap any interpreter on top of any other interpreter and then say that "multiple languages are available", but that won't make it useful.
Although new features are pushed in the OpenJDK to make dynamic invocation of methods lighter, more infrastructure is needed ... like a common MOP used for communication between these languages (like the DLR). There's a strong lack of leadership between the language implementors working with the JVM, because SUN couldn't care less about it and everybody is scared of new features in Java-land.
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.
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.
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.