locked
Targeted feedback we're looking for... RRS feed

  • General discussion

  • Want to start playing around with Axum but not sure where to start?  Here's a sample of some targeted feedback we're looking for:

    - Learning curve:  How complex do you find it to do simple things in Axum?  Do you think the value it provides is worth the investment in learning and understanding the language?

    - Form: Do you think that Axum is better off as a language or would you be just as happy with a library-based solution? 

    - Interop: How hard was it to consume objects that were created in other .NET languages?  Was it easy to place isolation guarantees on these objects?  If not, how would you change the process?

    - Async pattern:  What do you think of asynchronous methods?  Do they make the APM pattern easier?

    - Legacy:  What issues are there with porting legacy applications?  Any blockers or things we could do to make it easier?

    - Platform fit: How does Axum fit in with the rest of .NET?  For graphical applications, did you face any challenges with the UI? 

    - Scalability:  Were you able to easily write applications that scale from cores to the cluster to the cloud?  Is the unified model all it's cracked up to be?

    - Tools:  What kind of tools (compile-time, run-time, post-run) would make you a more productive Axum programmer? 

    - Love/Hate:  What's the one thing about Axum that frustrates you to no end?  What's the thing you love most about it?

    Remember whether it's a complaint about the way something works or kudos for a feature you love, your feedback will help make or break Axum and ultimately lead to a tool that makes you more productive!

    Thanks!

    Monday, May 4, 2009 10:21 PM

All replies

  • Suggestions for Axum:

    Integrate Axum into asp.net so the language can be used to build web applications.

    Make it work with quad core cpu's and higher core cpu's that will be made in the future.

    Can you pass on my suggestions?




    Monday, May 11, 2009 1:14 AM
  • 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…

       No.

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

       Yes.

    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?

      For me this is the most important feature.  The more generalized the better.
      I would tend to look at other systems for ideas.  The most general for dataflow that I have seen is this:
       
        http://ptolemy.eecs.berkeley.edu/index.html
         
        
        There is more than one execution model allowed.   

    For an overview:

       http://www.eecs.berkeley.edu/Pubs/TechRpts/2008/EECS-2008-28.pdf

     

      While Ptolemy is graphical, the concepts I believed should be studied and also the inherited methods(interface) on actors should be looked at for design ideas for Axum.  
       http://ptolemy.eecs.berkeley.edu/ptolemyII/ptIIlatest/ptII/doc/codeDoc/ptolemy/actor/Actor.html

    The VPL from MS Robotics is too slow to use for large problems.  The compile executed debug/test loop is too slow in VPL.  Axum is a good approach.

     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?
      Any reactive system project really.  I want Axum to be suitable (like the CCR) on simple PCs, not just quad core servers.

    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#?

      I would prefer these features be integrated into C# And 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!
      I am biased toward data flow, so I don't think I will be doing a 10,000 agent example.  Asynch methods are a must in any event.

    Monday, May 11, 2009 3:07 PM
  • SEVERAL SUGGESTIONS
    ----------------------------

    1. A Reference Guide most detailed would be great.

    2. To exprime the power of a parallelism would be good to consider not only work with CPU cores... also the GPU's... by the growing power of multiples cores that have.

    3. More posibilities of configuration... Not only Axum Class and Axum Console. A project which can use Windows Forms or WPF.

    Regards.
    XAV
    Monday, May 11, 2009 7:00 PM
  • I haven't been able to play with Axum as much as I'd have liked to of late, but here are some initial impressions:

    - Learning curve:  The simple samples have little to no learning curve, but as you step into flows it can be troublesome to keep on top of the flow of execution from a logical perspective without first understanding in detail what the flow should do.

    - Form: Much better as a language, creates a nice clean separation and encourages you to approach concurrency not from a "worker thread" perspective.

    - Interop: Not tried this yet.

    - Async pattern:  Useful, but so far have found few needs for parallelism on this scale.

    - Legacy:  N/A for me.

    - Platform fit: Haven't tried consuming .NET libraries yet or consuming Axum from a .NET app.

    - Scalability:  I played with some of the samples and increased their load and observed all four of my cores working evenly-ish, presumably if you can offer a service that can manage many clients via Axum this should transparently fit into a cluster or cloud setup - cluster/cloud in my opinion creates a little ambiguity as you are playing more with the hardware, not the perceived "environment" - clusters and clouds will have access to faster network interfaces and many more cores.

    - Tools: Some way to pause all message passing and perhaps trace one message trail (network, data flow, w/e) without worrying about any other concurrent executions.

    - Love/Hate:  Love that it is concurrent.  Love that it is .NET oriented as this brings three language styles, C# imperative, F# functional, and Axum concurrent.  I have always been a fan of Stackless Python, but have never had the Python experience to work with it heavily.  Hopefully with Axum I can create my .NET libraries to support a stronger Axum implementation.

    Would love to see this running on an Xbox.

    Dislike the current operators (==> --> -<& etc) as they make the code a little odd to read.  This may be perhaps a lack of experience with the code, but I would like to see alternatives explored - perhaps keywords ala LINQ:  

    to instead of -->
    forward instead of ==> (can forward be doubled for >>- and &>- if the left-hand is a collection and the right-hand is either a scalar or collection?)
    merge/join instead of &>- (if it cannot be doubled)
    split instead of -<< (can this can be doubled into --> or ==> if the right-hand specifies more than one end point?)
    queue instead of -<: (would assume this cannot be doubled due to ambiguity with doubling -<<?)

    filter can be perhaps bracketted where clause with the keyword  <data> to <function> (where a == b) to <function_print> (where result != null)

    I'm not sure about tuple as I don't fully understand them yet :) but I now think that inferring the meaning of the keyword could reduce the number of distinct actions and make flows more flexible.

    Love the work still - very interesting technology.

    Friday, May 15, 2009 8:02 PM
  • I haven't had time to experiment with Axum as much as I would like, but here are my thoughts so far.

    Learning Curve: I am pleased with the learning curve so far. Definitely worth it.
    Form: I like it being a separate language that integrates well wit the the other .NET languages.
    Interop:  So far I've tried adding the Isolation Attributes and also the Contract Assemblies(I don't particularly care for the idea of using the C# with additional keywords) So far it is working good except that I didn't see a mention in the Programmer's Guide that Contract Assemblies need to have the ContractAssembly attribute otherwise it doesn't work.  After I discovered that, it worked great.
    Async patern: No comment yet
    Legacy: No comment
    Platform fit: I haven't gotten far enough along to encounter any real challenges. I do like the fact that since it integrates with the other .NET languages that I can only use Axum for the parts I need it for.
    Scalability: No comment
    Tools: No comment.
    Love/Hate: Love the idea of writing software in such a way that tries-avoids concurency headaches.  Hate that when trying to create/"construct" a channel that is referenced from another assembly that I get a Constructor of external type... can cause side effects error. So at the moment I am forced to duplicate channels in multpiple assemblies. (I am experimenting with the WCF Hosting so I have multiple applicatiosn that need to use the same channel.)

    Overall I think it's an exciting technology and I am interesting in seeing where this goes.
    Monday, May 18, 2009 12:07 AM
  • Philip,

    Thanks a lot for the feedback! You're right about the need for the ContractAssembly attribute -- I neglected to mention it in the Programmer's Guide. We'll get it fixed.

    Channels are definitely supposed to work accross assemblies -- the error you're seeing is a defect, which we will fix.
    Artur Laksberg - MSFT
    Monday, May 18, 2009 2:07 PM
    Moderator
  • 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.

    So, to the some of your questions: (from Axum blog site. copied here as well)

    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)

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

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



    4. 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 ;))

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

    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#?

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

    7. 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)
    Monday, May 18, 2009 7:15 PM
  • Philip,

    I'm having difficulties reproducing your problem with the channel constructor: "Hate that when trying to create/"construct" a channel that is referenced from another assembly that I get a Constructor of external type... can cause side effects error. "

    Here is what I do:

    a.ax:

        public channel C
        {
            input int n;
            output int m;
        }

    b.ax (uses a.dll)

        agent A : channel C
        {
            public A(){}
        }

        private agent MainAgent : channel Microsoft.Axum.Application
        {
            public MainAgent()
            {
                C c = new C("foo"); // compiles fine
                PrimaryChannel::Done <-- Signal.Value;
            }
        }

    This works. What should I do to reproduce your problem?

    Thanks!


    Artur Laksberg - MSFT
    Tuesday, May 19, 2009 2:19 AM
    Moderator
  • Learning curve: for the current state of project it is very good
    Form: i thing that Axum is much better as a language. This is some concept behind it and it's worth be a  language, with appropriate keywords operators etc, rather than a set of dll. And we already have ParallelsExtensionsLibrary as a library-based solution

    Async pattern: i think it's a good idea, and it fits in the language philosophy
    Platform fit : maybe, support for graphical cards with multiple CPUs is a good idea. When creating XNA games it will be useful.
    Tools : a good debugger specially crafted for Axum will be a great support for me as developper
    Love: Schemas, protocols for channels
    Friday, May 22, 2009 10:40 AM
  • Hi, all I've done so far is read through the Guide, but I love the concepts in there and I think this is a terrific project.  I agree with those who believe this should stay its own language rather than be folded into, for example, C#.   I know Anders Hejlsberg is thinking a lot about concurrency (and 100 other things) but in my neophyte view one has to guard against a language becoming a "kitchen sink" language.  Of course Anders knows this better than anyone and is doubtlessly on the alert to guard against this.  I believe multi-.NET-language programing should be encouraged - why not use C# and F# (and Ruby? / Python?) with Axum.  Of course we would need a **LOT** of Microsoft guidance on how best to do that.  The more power I'm given, the likelier I am to shoot myself in the foot, and other places.  I need some major guidance here.  Also, please keep the web in mind as well as Windows in your use cases and feature design sessions.
    Wednesday, June 10, 2009 12:37 AM
  • Josh, I've just started playing with Axum, and I have to say I'm impressed - so much so that I just blogged about it at http://peteohanlon.wordpress.com/2009/06/28/im-leading-a-parallel-life/ So, my comments as a neophyte Axumer:

    Learning curve: Well, a couple of the pages in the programmers guide had to be read more than once, but overall I've found Axum to be well thought out and easy to get your head round.

    Form: Here I'm split. On one hand, I love the fact that you don't have the "baggage" of other languages to deal with, but on the other hand it would be too easy for Axum to be dropped or marginalised. As Azure develops, I'd like to see the features in Axum become first class features of .NET.

    Interop: Seems straightforward to me.

    Async pattern: Thank you, thank you, thank you. At first I was sceptical, but now I'm a fan. The pattern is actually very simple, and as long as there's guidance around the code and things don't get too large (i.e. you have something attempting to do too much), this is a very nice model.

    Legacy: I'll get back to you when I've tried this.

    Platform fit: That's going to be my next big challenge - integrating this into a WPF application. As a member of the WPF Disciples, I tend to base my praise on how well things fit into my ability to do WPF apps, so I'll be looking at this very seriously.

    Scalability: I haven't done anything large scale yet, but I have high hopes.

    Tools: Well, better Intellisense support would be a start. I'm running the latest version is VS2008 and Intellisense is patchy at best.

    Love/Hate: I haven't got a hate at the moment - as for love - take a look at the blog post; in 40 lines of code I've got a parallelized application that exposes a contract (the channel) and works in .NET. How cool is that?
    Deja View The feeling you've seen this post before.
    Sunday, June 28, 2009 10:31 PM
  • Eric and ohanlop,

    Thanks for the feedback,  this is really really great stuff!  We have a top class community!  *tear*

    Josh
    Tuesday, July 14, 2009 4:55 PM
  • Hi All. 

    I'm new to Axum so here's my initial feedback.

     

    I'm in a stage between the programmer's guide (very simple) and reading / understanding the samples (complex). It looks like this is a big step – what can be done to make it easier ?

    1. Have a readme file for each sample (I find one readme for the WebFetcher project). For example – which algorithm for the dining philosophers problem the project is solving. More “future options”, so I can try and make the sample more complex, using it as a starting point.

    2. Reference the samples in the programmer's guide – something like : “this feature is demonstrated in the sample project ABC (see def.ax)”

    3. Add some kind of a visual aid to the projects, simple illustration that will make the connections between the parts known to the reader (me) before I jump in the code – that way the code strengthen my mental picture of the project rather then creating it.

     

    • Please fix the intelisense – its a major tool when learning a new language.

     

    I have some questions that I'll post in a new thread later.

    Thanks

    I'm having fun.

    Sunday, October 18, 2009 12:09 AM
  • I feel like I'm running a few months behind on Axum as it appears to have peaked around May/June, but I'm hoping that the project has enough support for it to continue. The blog seems to have been really quiet in terms of Axum related posts.

    Anyway, here's my experience of Axum so far...

    - Learning curve:  Not very complex in my opinion and a piece of cake to pick up.

    - Form: I really would hate to learn yet another language. Every time a language comes out, it's supposed to solve X because of the issues we had in Y language. It seems to be doing really well as a C# variant/child, but I think the largest boon to it would be making an extension of the .NET framework like LINQ for use in VB, C#, and F# (and by extension to PowerShell as well?).

    - Interop: Not hard at all. Objects that are already serializable makes it much easier.

    - Async pattern:  I'm new to parallel/multi-threaded program, so not sure I have anything to add in this arena.

    - Legacy:  n/a

    - Platform fit: Seems pretty good so far. Still working on a project with a UI, so jury is still out.

    - Scalability:  Haven't messed with clustering or clouds yet.

    - Tools:  Axum only has simplistic integration with Visual Studio so far, but expanding it to be handled more like a first class language would be exceptionally helpful.

    - Love/Hate:  I love the simplicity of the language as I'm familiar with C# already, but absolutely hate the operators. It was suggested above in the thread to use LINQ's operators in their place and think thats a fantastic idea.

    Is there any new Axum related stuff coming up? I'm loving everything with it so far and would love to see this become a part of the .NET framework.
    Saturday, October 31, 2009 10:50 PM
  • Hi AllUsernamesAreTaken,

    Love the name. ;)  Thanks for the feedback on education -- we will certainly take this into account as we take you from high-level to deep. 

    We love to hear you're having fun!

    Josh
    Tuesday, November 3, 2009 8:22 PM
  • What is MSFT? can you put up a link looking for more information.
    Thanks,

    Gift Baskets
    Thursday, November 12, 2009 1:31 AM
  • My small list:

    - Learning curve :  Smooth enough

    - Form : Language. Many things can't be expressed at a library level.

    - Async pattern :  Async methods is a good idea, but the naming is not. In what sence are they async?  For us they look sync - executing one after another.

    - Love/Hate Please, don't hide the real nature of "three forms of ‘asynchronous’ storage" behind the modifiers. They are interaction points.
    I understood what they were  after reading this MSDN article . It was't a natural way of getting to know the language :)

    Saturday, November 14, 2009 2:56 PM
  • I personally think AXUM should be turned into a VS product, with an express edition to match it

    conncurrency is very important for all kinds of client- server apps so axum would be an invaluble tool for .net development!

     

     

     

    Monday, September 6, 2010 10:48 PM
  • I've been using Axum for a while now and so I feel ready to answer these questions:

     

    Learning curve:  'Simple' is not a word I would use to describe Axum. However, I don't think parallel programming is simple. We are living in a world where OOP is 'the norm' and so anything that departs from that, especially something as intricate as PP, is going to mean we all have to rethink our approaches, models and patterns. That said, Axum is far simpler than its predecessors, lets be honest - here's lookin' at you, Erlang! 


    Form: I think in an ideal world, smooth, unwavering integration into C# would be lovely, but the realism is that it needs more than that. It needs to enforce a new way of thinking and a new language is the best way to do that.


    Interop: This is something I'm yet to try, but it seems straightforward. I already have my Axum service being deployed from a WPF app so certainly deployment has been no problem.


    Platform fit: Very well. I've not used Axum to directly control another part of .NET but I've used it in parallel and it was relatively pain-free.


    Scalability:  Yes and yes. Scalability is the reason that I chose Axum and so far it's not let me down. My only criticism is that WCF is notorious for being 'slower than raw sockets'. I think Axum should implement its own approach, using sockets, to handle distribution.


    Tools:  Perhaps a topology designer would let programmers design domain, agent and channel relationships.


    Love/Hate:  The lack of intellisense annoys me no end! The pure power and potential in Axum just astounds me and I love it.

     

    PLEASE DON'T PULL THE PLUG!

    Monday, September 13, 2010 10:43 AM