Slashdot Mirror
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."
Now you know.
in your channel class then you can communicate with agent instances that implement that channel quite easily like:
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.
My work here is dung.
The windows version works great, but Axum on Linux isn't ready for prime time, yet. However, Axum is powerful enough that you should probably change your platform to permit its use, so if you have a new app being developed, I'd force your engineers to use Axum and develop it on windows.
And I know what I'm talking about because I'm an IT manager at a Fortune 500 company.
I see Microsoft is doing its best to help developers all over the world create race conditions. I wonder how many programmers there are who never really 'got' concurrency. Hopefully I'm not one of them. (And no, there is no programming language that can prevent you from screwing it up.)
Well, it does use the same concurrency model as Erlang, but Erlang has no concept of classes. Perhaps Scala, which I know little about except that it runs on the JVM and is supposedly better at concurrency.
-mkb
The "channel" technique makes me think of Occam.
Goddamn, PDFs for language specification and programmer's guide? Thanks guys, I'll probably never need to search this stuff, or link to a specific section. Also, what the hell do you call this bracket style:
public Program()
{
// Receive command line arguments from port CommandLine
String [] args = recieve(PrimaryChannel::CommandLine);
// Send a message to port ExitCode;
PrimaryChannel::ExitCode <-- 0; }
I can't help but think that their idea of "Channels" is really a message queue, which listeners pull messages from. This is easily implemented in around 30-40 lines of Python, Queues, Tasks and Listeners. And since Python supports these crazy things called CLASSES, it's really quite easy to implement new features or override base functionality.
In other words, this is an incredible waste of time. Put all these kids to work on IronPython and close this crap down.
> I haven't seen may apps that properly use OO
True, but it's very nice for program libraries - boost, wxWidgets, Qt, etc (yes I'm a C++ programmer) - where people who know what they're doing have already done the difficult stuff for the rest of us.
Adventure, Romance, MAD SCIENCE!
previously known as Maestro and based on the actor model
Somebody has their performance arts mixed up
Wanted:
Senior Software Engineer
Windows Platforms
MFC C++ - 10 Years
C# - 5 years
Axum - 5 years
You *know* it's going to happen.
I see Microsoft is doing its best to help developers all over the world create race conditions. I wonder how many programmers there are who never really 'got' concurrency. Hopefully I'm not one of them. (And no, there is no programming language that can prevent you from screwing it up.)
Concurrent programming is becoming increasingly important for any kind of high-performance project. This doesn't necessarily mean one needs a "concurrent programming language" to do it - but whatever the chosen mechanism, the goal is the same - write a program that uses all cores effectively. One way or another, professional programmers are going to need to 'get' concurrency in the coming years.
The benefit of a language that provides parallelization as a basic assumption is that the language itself can provide infrastructure (for message-passing, task-scheduling, and so on) useful to the task. Such a language encourages programmers to think about problems in terms of how they can be parallelized, but leaves the compiler or the runtime engine free to make decisions about how the parallelization is to occur.
Another benefit of such a language is that a language that takes certain ideas as base assumptions can help guide the programmer's approach to a solution. This can involve a significant learning curve for the programmer (see, for instance, Prolog or various functional languages...) but it can help programmers to achieve a new way of solving their problems: in this case, one that is rather well suited to the current needs of high-performance CPUs.
The challenge with synchronization in Axum, presumably, is that it's possible to write code that will run in the engine that won't conform to the rules for an "actor" - that it will perform some non-thread-safe access to a file, or that it will otherwise do something that won't be safe when run in parallel. From that perspective it's no different from (almost) any other language - as you say, it's still possible to screw up. What it does provide, however, are guidelines and framework to help keep you from screwing up.
Bow-ties are cool.
The thread control facilities available in the C# language are already quite extensive and include pretty much every known way to control concurrency presently used in software: mutexes, semaphores, locks, etc...they are all there. For example, the following paper (PDF link), written by Andrew Birrell of Microsoft Research, covers all the basics and explains the various options in C#. If they wanted more robust threading frameworks then why not simply add the relevant classes to the .NET Framework class library (i.e. in System.Threading)?
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.
"There is more worth loving than we have strength to love." - Brian Jay Stanley
You're making the mistake that concurrency is the same thing as parallelism. It is not. Concurrency is when a program is written in such a way that the order of execution of tasks is highly underspecified; parallelism is the use of multiple execution units to execute concurrent code.
Concurrency isn't just for performance; concurrency is just as much for writing software that can do many things at once. For example, one needs concurrency to have client applications that respond to the user with very low latency while doing some other work in the background. In this case, in fact, the software isn't trying to perform its heavy computations in the absolute minimum time; it's OK to slow down the heavy computation somewhat in order to reduce user interface latency. Have you ever used one of those applications where the whole UI hangs (e.g., won't even draw) while the application does some action, like connecting to a server? That's a failure to provide concurrency.
Contrary to common wisom, the introduction of multicore processors didn't increase our need for good tools for concurrent programming, because we've needed such tools since way before for user interaction. The tools that conventional languages provide for threading and synchronization are too hard to use, leading programmers to introduce far less concurrency into the software than they otherwise could. Also, conventional threads are much too heavyweight for an application to create thousands of them.
Are you adequate?
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.
Qu'on me donne six lignes écrites de la main du plus honnête homme, j'y trouverai de quoi le faire pendre.
I think most concurrent languages have been derived at least in part from CSP, so they'll probably all 'feel' like occam; it's just occam got there first. Incidentally, if you already knew about occam, you might want to check out David May's (the guy behind Occam) new startup XMOS. :-)
I'm not affiliated, but I do own their dev kit