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.

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

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

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.