通过

The First Axum Bits Are Now Available

  • 项目

Dialog 

It gives me great pleasure to announce the availability of our Axum technology preview at the MSDN DevLabs site. I have been working on this project off and on for several years, and for the last 18 months or so, I’ve had good company from Artur Laksberg and Josh Phillips. It has been a long and winding road to this point, but we are here now and that is incredibly exciting, I think.

Download it, take it for a spin, and let us know what you think. Be sure to check out Josh’s introductory video on Channel 9. If the weather where you are is anything like it is here in Seattle right now, there's really no reason to do anything besides building Axum apps this upcoming weekend! :-)

It needs to be reiterated that Axum is an incubation effort, which means that we’re not committed to shipping it in any particular product release or in the form offered by this preview. A lot will depend on your response and involvement with us.

This language is not a finished product – we are quite certain that it is too big and we have some ideas on what to take out, but would like to hear from you about it. We welcome suggestions on syntax, but we are more concerned about getting the semantics right first – only where syntax stands in the way of comprehension is it really a big deal for the moment.

Here are some (leading :-)) questions to ponder and help us understand:

1. Is the number of concepts you have to learn in order to use the language (I count four: agents, channels, send, receive) too many? Is this a complex language? There will always be a learning curve with any new technology, but looking past that…

2. Is overcoming that learning curve worth it if what you get is a solution offering safe parallelism?

3. Are data-flow networks as general as what Axum offers useful, or would a more constrained form be sufficient? If generality is indeed valuable, are we missing any constructs that would make networks even more useful?

4. What aspects of the language aren’t we explaining properly? What didn’t you get after trying it out?

5. What kinds of projects is Axum best suited for, what are its sweet-spots in your opinion? What kinds of projects is it less ideally useful for?

6. How feasible is the idea of a special-purpose language in the first place? Would you see yourself developing parts of your application in Axum, parts in C#, VB, or F#?

7. One of the innovations in Axum is the availability of asynchronous methods, which offer great scalability. Tell us how you are using them and what your experiences with them are. Let us know about your 10,000-agent application!

Please direct all comments on issues that you may run into to the Axum MSDN Forum and make sure to actually read the README, it contains crucial information that will make things easier for you.

On behalf of the Axum team,

Niklas Gustafsson
Software Architect
Developer Division

Comments

  • Anonymous
    May 08, 2009
    As I relayed in an earlier post about the soon availability of Axum, well, today is the day .  I

  • Anonymous
    May 08, 2009
    As I relayed in an earlier post about the soon availability of Axum, well, today is the day . I noted

  • Anonymous
    May 08, 2009
    We’ve mentioned Axum (formerly known as Maestro) before and we have some very good news: it’s up for

  • Anonymous
    May 08, 2009
    Sweet! Congrats on shipping Axum - looks like a ton of fun!

  • Anonymous
    May 08, 2009
    Two bits of feedback after a first read of the Programming Guide: The concept of Hosting/Evicting an agent's type from a domain is introduced, but without enough context.  One more bit of sample code would be helpful there. Perhaps related, but having host addresses be objects of any type with equality comparision was the one thing that had an instinctively bad smell to it. All and all, looks extremely cool.  Thanks for the early bits. Rather than question 6 above, my first question was, does this need to be a separate language, or should these be additions to a future version of C# and the CLR?

  • Anonymous
    May 08, 2009
    Blake, thanks for you comments! Let me just elaborate briefly on the choice of allowing non-strings as addresses: we wanted the various objects that may be used by transport implementations to be usable with IHost, for example WCF EndpointAddress or System.URI. That's the only reason, and since the only common base class that can reasonably be expected is Object, well... That said, I've several times been this close to just making it 'string' everywhere.

  • Anonymous
    May 09, 2009
    Thank you for submitting this cool story - Trackback from DotNetShoutout

  • Anonymous
    May 11, 2009
    An interesting (and heated, wouldn't expect anything else) discussion has been started on Slashdot: http://developers.slashdot.org/article.pl?sid=09/05/11/1523209 And yes, we built you an MSI so that the integration with VS and MSBuild would be easy.

  • Anonymous
    May 11, 2009
    As it was announced last week , Axum, a .NET Domain Specific Language around safe, scalable parallel

  • Anonymous
    May 11, 2009
    As it was announced last week , Axum, a .NET Domain Specific Language around safe, scalable parallel

  • Anonymous
    May 12, 2009
    By the way, the language is named after the city in Ethiopia, a UNESCO World Heritage Site and a historical center of Ethiopian culture. Microsoft has an affinity for geographical code names, and we decided to pick something a little more obscure than most...

  • Anonymous
    May 15, 2009
    I definitely look forward to a native .NET language solution to concurrency and is what is required to really leverage the multi-core revoluton Key needs for the language are:

  • Safely scale. From one process on one machine to many processes on different machines
  • Leverage the lessons learned from Erlang
  • Enable TDD
  • Make the programming language as readable as possible
  • Anonymous
    May 18, 2009
    Hi Axum Team, First of all. Congrats about the extreamly great work you have done! Now, when samples and docs are available it's easier to place the Axum to the right place. And I even managed to have one day only for getting familar with Axum in practise. You can't image how happy I'm to see the langugage/environment like Axum to be invented and to see how closely it's relatited with the work we didi last ten years. And still, now whne the bits are out, I can see Axum as a great advance to really build the next generation of Bonumite. So pls pls, make it to the production so that this one can be the next big thing in mainstream programming. It's also nice to see you have possible catched something, Axumite, from previous contacts :) So, to the some of your questions:
  1. Is the number of concepts you have to learn in order to use the language (I count four: agents, channels, send, receive) too many?
  • I feel definitely that these concepts are pretty easy to adapt for. As Axum is natively compiled with the rest of .NET env it helps adaptation to new way af thinking as one doesn't need to change all design and thoughts once.
  • And still, there will be a huge resistance from many directions as I have felt it while trying to get programmers to understand truly async and distributed apps. (meaning async and dustributed from small scale up to large scale, like Axum is)
  1. Is overcoming that learning curve worth it if what you get is a solution offering safe parallelism?
  • For sure it is. I'm bit objective to say something to this one as my abstraction to the solutions goes automatically "Axumited" way. And it's worth of it even if takes a bit time really adapt to all the chances the Axum gives and espesially to new challenges caused by asynchronisty and small scale parallelism
  1. Are data-flow networks as general as what Axum offers useful,...
  • That is something I need to test more. I'm not 100% sure before test cases that the features enabled now would be generic enough. On the other hand, some level of generality need to be by Axum users.
  • What I found to be missing was incapability to miodify the network objects ones created. Especially for the broadcasts. This leads the programmer to use list and foreach to actually manage the pub/sub functionality (As seen in IM example.) when it would be great to see a kind of Dynamic Broadcast, where the targets are more likely read through callback/reference, not from the list given at the creation. May be something like this.. I'm sure you got the idea. List<IHost<myTarget>> myListeners; var myNet = source ==> myListeners; If giving the array of targets IHost<int>[] targets already works like this, then I missunderstood something (I admit, I didn't test this one.) and this needs to be raised up in the docs.
  1. What aspects of the language aren’t we explaining properly? What didn’t you get after trying it out?
  • Erm. without testing it enough, I would say that it looks beatufilly well designed and clear to use :)
  • May be there should be a little bit more explained about how and based on which rules the threads are created. Without a bit more exact understanding to this one I still get it on my mind that there might be a need, at least for more experienced programmers, to control Domains/Agents to be executed in specific Thread/ThreadPool. (Named similarry as Hosts for Agents).
  • Interprocess communication might need a bit more explanation.
  • Schemas with similar required data. When some schema with optional data would be handled by some Middle Point in the network and the original reference to the scema is returned to the next source, will the Axum remove the optional fields not known by this middle-handler. Let say we have a network/flow A->B->C With schema a1, a2, bot having required integer field, but a2 also having optional string on it. Now A and C knows the schema a2 with the string, but B only the schema with required ID. Once set up the network like above A ==> B ==> C, would the C receive the optional String as well? (Yes, easy to test but.. possiböe some short example would help to clarify this point too. I like more docs and concepts than coding ;))
  1. What kinds of projects is Axum best suited for, what are its sweet-spots in your opinion? What kinds of projects is it less ideally useful for?
  • My feelings are, that a large scale of programs nowadays programmed should use a concept like Axum has. Not necessary to Axum, but the similar concepts.
  1. How feasible is the idea of a special-purpose language in the first place? Would you see yourself developing parts of your application in Axum, parts in C#, VB, or F#?
  • Maximum feasible. I definitely would like to put the different parts of the code to the right language. And as I see it now, there is a great support to combine native .NET langs with Axum.
  1. Erm. Would the Axum be version 1.0 I would start my next projects with that one. Until getting the first release, I just have to wait and encourage you guys to continue with the fabulous work you have done. And then some comments from my notes: Schema, Rule.
  • First of all, I don't like attaching something like your "rule" natively to the schema itself. Rather having a concept to use "rule" against schema in common would be great to have. (this might need great changes to desing and I understand some of the difficulties doing so while Axum being language to be compiled, but still..)
  • why would'n you call schema as "data"? On the other hand, schema raises up the similarity to xlm-schema, so good naming after all.
  • Would it be possible allow receive to get Lists or Queues of payloads instead of gettings just one? Especially with transformers receiving messaged in joined manner this would be helpfull and efficient. This would make it also much easier to change your StockAgentProxy to send the Last update and skip the middle ones instead of skipping some last ones now ;) (Whick may make the traders grazy) - Implementation for "last tick" would be pretty easy now as well, but more complicated than 2 lines with queues :)
  • Should the schema have a language specified base/empty Schema which can be used generically in all the apps when generic zero fields schema is required? (At the end, this just remove the need for coerse and possible enables some optimisation for the compliers)
  • And finally one more time special thanks for getting asyncronisyt to so low level in the codes, that's great and that's I've been missing last couple of years working with other tools than Bonumite. I hope all the best for Axum project. Once I get more time to play around with Axum I will return the features possible irrating me or to the features required/nice to have etc. Anything that I will see possible to raise around here or other forums. Ville Varis Chief Architect, Bonum(ite)