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

Just In Time!

[Anonymous Coward]

How timely! Firefox just decided to rip off IE8 by supporting multi-processing. Maybe they can start programming it in Axum, and save themselves a lot of pain.

Typical Microsoft

[JustNiz]

>> Axum does not have capabilities to define classes, but as it runs on the .NET platform, Axum can use classes made with C#.

Why is it that Microsoft persist in vomiting up quick/crappy/hacky workarounds rather than solid solutions? and how is it that the people with the biggest blind-spot about technology and how bad Microsoft products are, are always in senior management of tech companies?

Re:WTF is a "Concurrent Programming Language"?

[Locutus]

it's a programming language which splits up multiple threads of execution into different processes instead of threads. Microsoft OS's have sucked at multi-threading since NT v3.1 and Microsoft's own developers are really bad or totally ignorant of the concept of multi-threading. Anyone remember how bad Windows Explorer worked when they tried to multi-thread it in a Chicago beta? OS/2 ran circles around everything MS tried and most all OS ISV's knew and wrote multi-threaded applications.

Because of these "features" of Microsofts OS's and developer skills, or lack thereof, the crutch is to help Windows own developers and ISV's create applications with many processes instead of threads. If that happens, Windows applications can step into the 1990s and take advantage of hardware having more than one CPU.

Microsofts love affair with "function" based programming and API's dates to the Windows NT 3.1 days up to the Windows 95 era. This was when IBM was doing magic with CORBA on OS/2 and C++/OOP cross platform frameworks were all the buzz. Nothing pissed off Microsoft more then having someone else defining what application framework developers were to use and hiding details of the Windows API's was not going to happen on Bill G's watch. Microsoft then became a fan of Functional Programming. They based their messaging on RPC, and their Object-like COM and MFC didn't let the Windows API's get out of developers sight. One by one Microsoft went after the cross-platform framework vendors until there were none left. The Windows Object-like API's and nonstandard C and C++ compilers also made it very difficult to port to any other OS. Some developers called it Microsoft C-- because of its lack of standards following.

So now it's over 15 years later and multi-core CPUs are the norm but Windows, Windows utilities and Windows applications are still mostly single-threaded. You've to 4 CPUs but click on a Windows app and you still get the hourglass waiting for a page, graphic, etc to finish processing on one CPU while the other 3 mostly idle. So it's time to now patch the damage done in the early 90s and come up with a language built on Windows, for Windows, because of Windows, and....wait for it.... tied to Windows. Yeah, that's a great idea. Not, IMO.

LoB