

Axum - A new parallel programming language from Microsoft - chadaustin
http://msdn.microsoft.com/en-us/devlabs/dd795202.aspx

======
silentbicycle
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.

~~~
rmaccloy
I'd bet this originated from MS Research, who have plenty of people who have
worked on/invented actor systems predating Erlang.

~~~
silentbicycle
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.

~~~
rmaccloy
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.

------
bad_user
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.

~~~
Confusion
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.

~~~
bad_user
Yes. That's true.

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.

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

------
Bjoern
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.

------
jdavid
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).

~~~
daeken
Err, Axum has nothing to do with anything you mentioned. Axum is a programming
language for parallel processing.

------
trezor
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.

