Here, Axum PM Josh Phillips walks us through building a simple Axum application in just over 5 minutes. Josh builds a simple “math library” on agents and shows how easy it is with Axum to focus on your code and get parallelism and safety implicitly.

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.

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.

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

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.

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.

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.

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.

Remove this comment

Remove this thread

Comments Closed

Comments have been closed since this content was published more than 30 days ago, but if you'd like to continue the conversation,
please create a new thread in our Forums, or
Contact Us and let us know.