Microsoft Releases New Concurrent Programming Language

zokier writes "Microsoft has released a new programming language called Axum, previously known as Maestro and based on the actor model. It's meant to ease development of concurrent applications and thus making better use of multi-core processors. Axum does not have capabilities to define classes, but as it runs on the .NET platform, Axum can use classes made with C#. Microsoft has not committed to shipping Axum since it is still in an incubation phase of development so feedback from developers is certainly welcome."

Comments

WTF is a "Concurrent Programming Language"?

[Alethes]

Now you know.

Re:WTF is a "Concurrent Programming Language"?

[davester666]

"It's meant to ease development of concurrent applications and thus making better use of multi-core processors."

should really be

"It's meant to get developers to continue to use Microsoft-only technology, so IT departments will have to keep buying Microsoft client and server OS licenses."

Focuses on Interfaces to Ease the Pain

[eldavojohn]

Much like web services, the importance seems to be in the interfaces. After scanning the developer's guide, the most important aspect of this language seems to be that it's a C# plus Axum libraries that allow you to describe "channels" with input/output keywords. Your Primary Channel is your main program or main 'thread.' If you define an input like:

input int foo;

in your channel class then you can communicate with agent instances that implement that channel quite easily like:

bar_agent::foo <-- 134;

If the data can't be sent over a channel you use (and this word should sound familiar to you web guys) a schema.

From there on out it gets a lot more complicated with state and domain communications/sharing. It looks better thought out than most of Microsoft's libraries I've been forced to use but--as always--new languages need many releases before they are production worthy. A noble effort to simplify concurrency. With some really slick operator coding and overloading, you could probably get a similar thing going in Java or C++.

One last thing I'd like to bitch about is that this download is an MSI. Really? You really need to do that? For the love of christ, I'm a developer. Could you please just give me a standalone zipped up SDK directory that I could add to my path if I want to? I'm not even going to install this because it's going to get all up in my registry n' shit.

Re:Focuses on Interfaces to Ease the Pain

[ipoverscsi]

Off topic, but here goes.

The package must be shipped as a Windows Installer simply because it's got .NET objects in it. These objects must be installed in the Global Assembly Cache (GAC), which means they must be versioned and reference counted. It is possible (though unlikely) that the installer doesn't even create any registry entries.

Now, .NET was supposed to give us "xcopy installs", so it's possible that MS could ship a ZIP SDK pacakge; but then you'd be responsible for lugging around all of your dependencies from install to install of your own software. Plus, then MS would have to manage two different installation packages, and we all know how easy it is to keep different versions of the same thing in sync.

Re:Focuses on Interfaces to Ease the Pain

[owlstead]

With some really slick operator coding and overloading, you could probably get a similar thing going in Java or C++.

Except, of course, that Java does not do operator coding/overloading, or you'd have to tinker with the language itself (which is frowned upon by the Java community).

Re:Focuses on Interfaces to Ease the Pain

[BitZtream]

As a developer you should be fully aware of the fact that you can extract the files from the MSI if you really want to. I'll help though. For most MSI files a simple:

msiexec /a filename.msi /qb TARGETDIR=C:\tmpdir

Will do what you want.

There is also the Less MSIerables app from the WiX project: http://sourceforge.net/projects/wix/ that will let you extract the files directly. Plenty of tools to accomplish what you want if you'd take the 2 seconds to Google for it.

You should also be aware of the fact that the MSI probably goes ahead and integrates the SDK with Visual Studio so the libraries, binaries and help are in path and available without a bunch of extra crap to do on your part, which for me personally, I'd rather have it do than wasting my time trying to figure out what needs to be done even if they did bother to document everything.

I realize that most of the slashdot crowd thinks having to do everything from the command line based on a man page is a good thing, but for the rest of us it stopped being cool when we got out of school and had to get a job where they expected us to actually get shit done and not sit around all day with our thumbs up our asses playing with Linux.

Re:Focuses on Interfaces to Ease the Pain

[shutdown -p now]

After scanning the guide as well, it reads a lot like Erlang as "improved" by a Java/C# lover.

It's probably just your perspective :) I'd say it's more like C# improved by an Erlang lover, and it's probably closer to the truth.

For example: Axum seems to have a pretty strict type system, which gives you the ability to catch compile-time errors more cleanly, but on the other hand, there doesn't seem to be a simple way of creating a Tuple or Array literal without using a function.

Actually, they have one example of an array literal in the paper - apparently, it's just curly braces:

For example, the following expression combines output from two interaction points ip1 and ip2 and passes the result on to an interaction point twoNumbers:

receive( { ip1, ip2 } &>- twoNumbers );

The expression above uses curly braces for array creation. In Axum, implicit array creation is a convenient syntactic construct that is used often when building network expressions ...

I don't know about tuple literals though. If they use the stock tuples from .NET 4.0 (as they probably should later on), which is System.Tuple generic class "overloaded" for varying number of type parameters, then tuples can be created with Tuple.Create(n1, n2, ...) call - which, of course, is still just a library function, but I wouldn't call it overly verbose. In practice, tuple literals are only really required when you want to have pattern matching in the language, which they don't seem to have.

Re:My feedback

[Divebus]

Exactly. More proprietary digital glop from Microsoft.

Not "Insightful", "Clueless"

[SuperKendall]

Because you would whine and bitch about them "stealing" the language if they were to co-opt another concurrent programming language to run in their .NET environment.

Come on, who ever complained about Microsoft "stealing" any of the existing languages supportted by .Net? That was not true for Eiffel or managed C++ or IronPython, or... you get the point.

Now it is true that C# was taken lock, stock and barrel from Java when the Microsoft embrace and extend strategy was slapped down there (read the memos), but no-one ever complained about other languages being added in just as no-one accuses Java of "stealing" all the languages that VM supports now. So using an existing concurrent language would make a lot of sense and annoy no-one.

Re:Was C# Not Enough?

[Bill, Shooter of Bul]

Its not a threading language, its a distributed concurrency language like erlang. So its designed to send messages locally or across a cluster, in a fast, safe,and easy manner. Yes, you could do everything in c# that it does, but not easily. Look over the documentation and you'll find some things that would be odd to you as a c# developer. Some sections that won't let you modify a variable's contents, to keep certain sections free of side affects.

Basically its a different way of doing things that should help create easy,bug free, high performance, concurrent software.

Re:So, where did they steal this idea from?

[dido]

From the looks of things, C.A.R. Hoare's Communicating Sequential Processes (yes, the same guy who invented Quicksort). Well, Professor Hoare presently works at Microsoft Research, so I guess he may have more than passing involvement in the project. It's the basis for many other concurrent programming languages such as Occam, Erlang, and Limbo to name a few.

Re:The good points of a concurrent language

[Tetsujin]

Your understanding is...flawed to put it nicely.

Feel free to provide more detail. Bear in mind there are people here who may not know all the details about .NET - and may not love it, either - but who would still be interested in learning more about it.

Re:R&D

[shutdown -p now]

Frankly, #pragmas are ugly, and what if you want to parallelize operations on STL containers? How about a library solution using C++0x lambdas instead:

#include <ppl.h>
using namespace Concurrency;
 
std::list<int> xs = ...;
parallel_for_each(
  xs.begin(), xs.end(),
  [&](int x) { /* do whatever you want the item here */ });

But, of course, it would require you to embrace "MS-Java++", and therefore automatically evil, right?