Axum Published! Tutorial: Building your first Axum application

Kamujin

This is completely disappointing.

public static int Add(int x, int y)
{
return x + y;
}

is as concurrency safe as this example.

Show me an example that's hard to do with current tools.

phillips.josh

Hey Kamujin,

Thanks for the feedback. This example was meant to be a five-minutes-or-less taste of what Axum looks like. It's pretty difficult to show any complex concurrency in 5 minutes. Keep your eyes peeled though. They'll be much more coming in the complex department. Networks in Axum will rock your world.

Josh
Axum Team

Kamujin

Please don't take me the wrong way. I am excited to see where this is going.

I am particularly curious about how chatty you can get with these agents before latency suffers. I am also curious to know how much memory allocation is going on behind the scenes to services the agents.

If I was overly critical in my first comment, it comes from prior experience where the examples made a language/tool look really simple. Then as soon as you apply it to a real world problem, the kludge, scaffolding, and other gotchas show their head. Haskell being my most recent disappointment.

I don't mean to suggest that this will be the case with Axum. I am simply curious to see something less trivial.

Charles
Welcome Change

In reply to Kamujin

#May 8th @ 2:06 PM

I'd recommend that you grab the bits and push Axum to the limit. Then, you accomplish two things:

1) You learn how well Axum can scale to complex concurrent problems (that are realistic in context)
2) You are equipped to provide the Axum team with excellent technical feedback that they can use in evolving the technology

It seems to me that you care, and that's awesome. Code on.

C

NiklasG

In reply to Kamujin

#May 8th @ 2:06 PM

Kamujin,

I suggest installing the bits and trying some of the samples, which are still meant to be educational rather than realistic.

The messaging overhead is comparable to Erlang, while the memory pressure per agent is close, but not yet close enough to make me happy. Compared threads, the cost per agent is about 0.001 of what a thread requires, as long as you place receives in asynchronous methods (see the WebFetcher sample).

And, unlike some other technoligies that may have disappointed you in the past, we're actively looking for your input. That's why we're getting Axum out there before it's completely baked.

tarlano

Thanks for the bits..

I must say your implementation of channels reminds me of Phil Winterbottom's channels from the old days of playing with Alef and Limbo. Were you guys influenced by either Limbo or Alef?

Regards,

Anthony

sylvan

This is pretty cool, but I think the semantics are overly complicated. I couldn't say that I know of a better way of doing it off hand, but I feel that there *must* be some way of making this simpler. As it stands writing agents still seems to be quite painful and clumsy, and something you would avoid doing up front, and instead do as an afterthought once you realise you need it. I think it's critical that writing agents should be as "light weight" as possible so that people write *all* their code using agents not because they necessarily believe they need them, but because they're the most convenient way of getting stuff done even when running on a single-threaded machine.

For example, there seems to be two main ways of interacting with an agent, either by just passing messages and reading from the channels, or by using request-reply ports if you want to be able to send off multiple requests and then get the reponse back while keeping track of which response belongs to which request. It seems to me that this duplication is unecessary. If you want to send multiple requests couldn't you just be required to use multiple agents, one for each "transaction" (associating a result with a given request is then trivial)? If they need to share state you could use a domain, right? I've only briefly looked at it but it does seem that the request-reply ports just complicate things and aren't actually necessary.

Also, I think first-class tuples will be very important for this, as you tend to want to make quick ad-hoc groupings of data all the time when sending and receiving messages.

The semantics and syntax of this needs to be simplified a lot to make it easier to use, it still seems that you spend far too much time and screen real-estate dealing with the details of coordination, rather than your algorithm.

NiklasG

In reply to sylvan

#May 9th @ 4:28 AM

Sylvan,

This is such a great and insightful piece of feedback that I now feel inspired to write something up on the Axum blog to elaborate on our thoughts on these topics. I was hoping to not work this weekend, but it will be hard to keep myself from writing something. Please look for something later, possibly before Monday morning.

Niklas Gustafsson

Mott

Axum seems really cool. I've downloaded the CTP and plan to play with it. It reminds me of a model I use often where I create a C# class, create an object from it and pass it all of the important information, and then call a Start method on it to tell it to do its work in a BackgroundWorker. Then it fires an event when it's done. At first glance, the Axum concepts seem pretty similar, but it removes some of the boilerplate coding I do as far as managing a BackgroundWorker and creating and handling events. It would be nice if it can reduce the headache of marshalling events to the UI thread as well.

-->Get Axum<--