“The rumors of my death have been greatly exaggerated!”

Thus quipped the great writer Mark Twain after a newspaper supposedly prematurely published his obituary, and it seems oddly relevant to Axum right now. In this post on the Axum Forum, an Axum fan asks whether the language effort is dead or not. Let me say that it is more a question of hibernation than death.

Axum was, and still is, an incubation effort. What incubation means at Microsoft is something between research and product development: the aim is not to advance the state of the art, as we do with basic research, nor is it to ship a product in a timely manner. Rather, the purpose of doing an incubation is to assess the feasibility and viability of a technology when market research methodologies aren’t likely to be sufficient: there is no commitment to productize, but there is more to it than just throwing ideas over the wall.

Thus, we developed Axum and got the technology out there in the DevLabs release last year, updated it once, and you haven’t seen anything since.

Shipping a new programming language means committing to many years of maintaining it, so it’s something we would want to make sure we’re doing the right way. The question of what to do with it is on our minds: do we ship it in Visual Studio, should it be a separate release, should we just steal from it and integrate ideas into other languages? Should we find a narrower field that it addresses particularly well (discrete-event simulation, for example) and tailor it for that domain, or is this a more broadly applicable model? (I think it is, but that’s not the point: what our customers think is what matters here.)

Since June last year, we haven’t been idle: there was only three of us on the project to begin with, and now there are two, but both Artur and I are also working on other projects. We have been prototyping integrating Axum concepts into other languages, and we’ve been speaking about Axum, both within Microsoft and externally.

There hasn’t been much in terms of updates to the model, but we have some clear ideas on what we would need to take a closer look at if we productize it:

1. The language runtime needs a complete revamp – it is much too large and complex. We’d probably take a dependency on .NET 4 and give up backward compatibility in the interest of simplicity.
2. The parser has pretty awful, often misleading, error messages. We would have to rewrite it.
3. I would remove the declared network construct as well as the syntactic support for ‘sync,’ ‘async’ and ‘const’ variables – the semantics would still be there, but in the form of classes only.
4. Network expressions – the current set of infix network operators isn’t very extensible. We would revamp this area of the language.
5. Syntax for constructing and deconstructing tuple values – one thing I have appreciated in both C++ and F# is how easy it is to use structural types in the form of tuples. This is particularly useful for messaging where ports only take one payload type – make the payload a tuple and, voila! .NET 4 has Tuple as a built-in type: all we need is some syntactic support and we’re off…
6. Discriminated unions – we’ve experimented with what Axum would look like if ML were the syntactic basis instead of C. One concrete learning is that discriminated unions make channel declarations so much simpler and we should definitely add them to Axum.
7. Schema instances would be immutable. Coercing to other types give you mutability on a pay-for-play basis.
8. We would take a closer look at whether the domain and agent concepts can somehow be merged into a single concept without loss of expressiveness.

There are probably more things that need attention, but those are the ones that come to mind right now.

At PDC 2009, I did a breakout session on Axum, which was attended by about 250 people and received very well. For those of you who understand Swedish, I did a podcast with MSDN Radio in Sweden (which made me painfully aware of how hard it is for me to speak about technology in my native tongue. Ouch!).

Three weeks ago, I spoke about Axum at three universities in Denmark: Aarhus, Aalborg, and Copenhagen, and was pleasantly surprised when a customer I visited in Copenhagen wanted to talk about Axum. I had come prepared to talk about other parallel technologies, but they wanted me to do the Axum presentation, too, and they wanted to know what was going to happen to the language. They felt it was a perfect fit for their problems.

I also did an interview with a Danish IT journalist while in Copenhagen, and what she wanted to talk about was Axum.

Next week, I have a session on Axum at TechDays 2010 in Örebro, Sweden. This is a IT-centric show, so it’ll be interesting to see how Axum is received in comparison with PDC, which has a slightly different audience, more ISV-centric. It could go either way, I guess. There, too, I’ll be doing a couple of press interviews on Axum.

Anyway, I have promised to make a renewed effort to the DevLabs Forum for Axum and we will take a look at whether producing a release of Axum that is compatible with the final release of VS 2010 makes sense.

Thanks,

Niklas Gustafsson

Comments

• Anonymous
  March 19, 2010
  The comment has been removed

• Anonymous
  March 19, 2010
  The comment has been removed

• Anonymous
  March 23, 2010
  Adam, Could you elaborate on what you mean by using serialization to offer immutability? We already do use serialization to enable custom payload types, but it achieves copying, not immutability. Since serialization vs. immutability is such a core aspect of the programming model, I'm keen on understanding exactly what you mean so I don't misunderstand anything.

• Anonymous
  March 24, 2010
  Hi Niklas, Sorry, I used the term 'immutable' in the sense that you are getting pseudo-immutability across agents through the fact that an agent receives a copy, so the senders copy is still unchanged.  It is not immutability in the strict sense like strings, where the type itself enforces this. I tried once to send a custom class in a channel and if memory serves I couldn't get it to work; though to be honest, memory usually doesn't serve so I'd like to confirm this again. Whether its actual immutability or perceived, that's by-the-by; the purpose being that an agent will not modify anything outside of its scope. This was just a thought to negate the need to have channels/schemas that are basically structural copies of existing classes.  I suppose a better solution would be a custom serialization mechanism specific to Axum that can decorate a class to use it like its a channel - [AxumSerializable]. Hopefully that clears it up - I was just simplifying the situation :)

• Anonymous
  March 25, 2010
  Adam, The scenario you describe is exactly what Axum schema is for -- assure serializability. To send your own types through, they have to be serializable and (correctly) implement ICloneable, or be value types. Niklas

• Anonymous
  March 25, 2010
  Hi Niklas, Thanks for clarifying that, its quite possible that I wasn't implementing ICloneable last time I tried. I'll make sure to give it another go! Cheers, Adam