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."
Because the PHBs like a single vendor. Nothing confuses them more than saying, "We're getting the OS from Microsoft, the database from Oracle, the language from Sun and the hardware from Dell." The less companies in this list, the better, regardless of the merits of technology.
Synergy. "With our development suite you have tools that specialise in X Y Z allowing you to do A B C. Give us your money."
I thought the general consensus on this site especially with regards to open source software was that choice is a good thing? I'm sure if they used an existing language Microsoft would employ an embrace and extend strategy that would have developers/purists up in arms.
Man blir trött av att gå och göra ingenting.
I don't know about "devlopers", but real developers use whatever OS they need to get the job done.
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.