Darach Ennis on the Pony Language, Actors, Concurrency

1. We are here at Code Mesh 2015 in London. I am sitting here with Darach Ennis. So Darach, who are you?

Hi, Werner. I am me and I guess I am a Dublin guy originally, living in London, mainly working in gambling and financial trading systems over the past 10 or 15 years and I am at the conference just like you.

2. I think you like languages like Erlang – we have talked about that before. Why?

Why? That is really simple. Erlang is an environment where you can quickly prototype and get working solutions that actually have the same meaning and interpretation when they are running in production. So, unlike most programs where you get a reasonably good rendition, if you are using the imperative style or languages like Java or C++, the code I actually write in Erlang is pretty much the code that ends up in production and once I found all the bugs and all the failure points I want to fix first. So being able to code let-it-crash style and then solve for the errors and compensate on a needs by needs basis is a much more effective use of my time.

3. Here, at the conference, you are co-presenting a talk on a language called Pony. What is that all about?

Erlang and Pony are based on the actor model. The actor model is just about 42-43 years old. Sylvan Clebsch, the reins behind Pony, is just one year older and I am one year younger. So, I think we arrived at the actor model about the same time. For us that is about of the philosophy of “observe – orient – decide – act”. So, you can actually build and conceive and compose parallel or distributed systems in a sensible, natural way. So the actor model is a win from that perspective. The really nice thing about Pony, however, is that it is taking a very different viewpoint over all of the existing actor-based implementations out there. So, for example, the fact that you do not have to kill actors, that they are actually killed by the runtime itself is unique to Pony and it does this through a fairly novel application of capabilities, because they actually track the lifecycle of actors, independent of the programmer. So the programmer no longer needs to worry about garbage collection. In the same way that a Java programmer ordinarily does not need to worry about memory management, a Pony programmer does not have to worry about the lifecycle of an actor. Which again is another way and another saving to get much closer to writing natural concurrent code.

4. You mentioned garbage collection. Is that just for objects or is that also applied to actors?

That is right. It is that simple.

5. Can you compare Pony to Erlang from a memory allocation point of view?

Pony has a very interesting selection of features from both the object-oriented paradigm, the actor paradigm and also the functional paradigm. It adds something fairly unique to this mix, which is exposed through the type system. So in a typed functional programming language we have functions and types. In Pony we have functions, we also have objects, but types have capabilities. So it is the unique properties of capabilities that allow us to track and trace objects as they move around the system or as they move around nodes in the system, as they move around cores so that we can effectively kill them, but hoist all of that logic and decision making from the programmer, right into the compiler. And the really interesting feature based on the proofs behind that, that Sylvan and his team at Imperial London have been working on is that most of this activity happens not at runtime, but at compile time. So what we are left with is code that is provably deadlock free, provably data-race free and also a combined with causal messaging between actors gives me something I can actually, reasonably reason about my code without having to think about second or third order effects just because the actor model does not actually support the notion that I naturally think about. So, if it is not causally message-ordered, then messages may arrive in an order other than the order I am thinking, whereas the same composition of events in Pony it actually arrives guaranteeably in the order I am thinking, which means it is much harder for me to get it wrong. So that is really the greatest aspect of Pony whether it is about memory management or it is about garbage collection or concurrency – that is going to be made safe, fast and cheap. This is the real beauty about how it brought object-oriented principles, functional principles and actor principles and blended it together into a language which basically just works.

Werner: Interesting. You already mentioned that the compiler and the type system helps a lot in ensuring safety.

That is true.

6. Is it a big change to come from a language like Erlang which is very dynamic?

It is certainly a change. We have the benefit of objects for composing things using nominal or structural typing. So Pony supports both flavors: if you want nominal typing, you got it and if you need structural typing, you have that too. It has an algebraic type system, so you can use that. It has types of capabilities which is where it becomes novel, interesting, weird and different. It is also wonderful in that that is what enables the garbage collection of actors which is fairly unique to Pony. But that is really not what makes it interesting. It is also a fast language and by that I mean computationally it is faster that C, which has been proven so that is a really nice result. So you are actually programming in a language where if you drop into C, your code runs slower, which is the opposite of the case of other languages which drop into C because it runs faster. In Pony, it actually runs slower so you want to think twice before going to native code. Of course, if the native code is already there and has a wealth of features in it, like LibreSSL or some other native library you are integrating with a device, it is very, very easy to integrate between native code and Pony and vice versa. As I will be working with a lot of hardware start ups who have weird and wonderful devices, ease of communication across the native barrier is a big advantage and as Pony essentially preserves the C ABI it adds no cost to actually converting between converting native code and Pony code. It just magically all works together. That is a lot of shim code that does not need to be written which is a massive productivity saving for anyone writing complex systems.

7. Interesting. Do you think that your experience with Erlang made it easier for you to adopt Pony or was it your work in messaging, your experience with that?

A background in messaging, a background in using the actor model, using it as a tool to verify protocols from a conceptual point of view to using it at an industrial tool to put systems into production, is not as important as you might think. The more important aspects, I think, is when it comes to converting from Erlang to Pony, as Pony at the moment is a very capable and uniquely beautiful language, but Erlang is a side effect of wanting to build an actual system. So Erlang the language is a side effect of the Erlang team with Ericsson wishing to build software that had systemic features and it is these features that really need still to transfer over to Pony, the language, So Pony the system really needs to become Pony OTP and take all of the goodness in Erlang and actually transfer these facilities into the Pony language. For example: an actor or a process in the Erlang world can be monitored, a monitor process can be linked so if one process dies, its linked process will die or if you want to just simply supervise and manage a set of processes, you can build a level of obstruction above these called supervisors. So this is not available in Pony today, but these discussions have been had so supervisors, monitors and links will be something that will be supported in Pony in the very near future, possibly even by the time this video gets out. That is pretty exciting by working with a language that is still very much in research, but it is gestating into commercial use just now. So as an early adopter looking at the code is still fairly simple, it is pretty clean, although in the case of the libraries there could always be more, there is a lot to get into it and get a feel for how the language works, which has validated my date. So I am going to be spending a lot more time with it. I think it is time well spent. I think it is a unique take on an actor-based programming system. I think for people wanting to write safe, secure, fast, cheap, scalable, easy to maintain code, it is a no-brainer. You throw away a lot of baggage because the compiler actually says “No” and this enables the runtime to say “Yes”. So this goes both for the code that you do not need to write anymore because Pony has more sensible guarantees baked into the system. Those guarantees are actually compile time checked so that the runtime can run fast. This is a fairly unique set of combinations I have been looking for for quite a number of years. My hope was that FoundationDB, the actor framework that they promised to open source before they were acquired by Apple would be something I to actually build on top of to do the kind of integration I would like in the Erlang style, was taken away. I was looking for something else. So clearly, if you want a secure environment, Rust is a very good candidate for solving that problem. There are a bunch of other languages in this space, but Pony just happened to have everything I wanted in a single package so that is clearly where I am going to spend my time. I think that when other people look and see what Pony is capable of - maybe they should have a look and see if that is where they want to spend some time too.

Werner: It is definitely really interesting.

It is a really compelling language and environment and hopefully Pony OTP will make it even better.

8. InfoQ tends to have a Java and .NET based audience. What do you think could be stumbling blocks for people trying to adopt Pony? Are there any ways they think that would be a stumbling block or could it be the way they think about threading? I think in Pony you have to share by message passing. Is that something you think may be difficult?

There is two difficulties for a typical .NET CLR, CLS or a JVM ecosystem programmer converting to an actor-based system and that is moving from explicit or implicit concurrency through frameworks as opposed to an imposed model which just works and allows for natural concurrency. It is difficult to convert from an environment where you need to understand about locks, you need to worry about deadlocks and data races, but even to an extent for most actor systems, you still need to worry about deadlocks and data-races. This has also been removed from the table in Pony. The more interesting languages are not giving us more tools, they are taking tools we never needed away. These tools are bugs so the more bugs we take away, the simpler and more natural programming languages become, the more we open it up to a diverse or a more diverse community. So languages like Pony are solving these problems today and possibly hinting at where we might move both programming languages and natural models for writing complex distributed systems seem to be converging on this model where the local and global models are moving towards a consistent set of guarantees. That is surprisingly reflected in Christopher Meiklejohn’s talk yesterday on lattice programming, it was reflected in Martin Kleppmann’s talk on transactions and we see similar reflections in the Pony talk in terms of its capability system and how the properties or guarantees seem to be aligning with older, functional principles that we have seen in the keynotes today and yesterday. So that whole view of the world is now kind of breaking into optimizations for the actor-model right the way through to better paradigms for distributed systems.

My hope and my bet is that this is converging on the actor model so I think that for the actor community and for the Erlang community and the Pony community, who are the 40 year old early adopters, plus or minus 40 years, I think they have a little something to offer folks from the .NET and Java communities. So please come and play and do not be worried – there are no locks, there is nothing to worry about. It is pretty easy to get up and running and so take a gamble, have a play and have some fun.

Werner: But they would have to throw away all that knowledge they gathered learning about deadlocks and ...

It is easy to throw away knowledge and fill it up with more garbage. We just need to wait for Code Mesh 2016 and we can have a little refresh.

Werner: OK. I think that is a good place to end on. I think we should all check out Pony. Thank you, Darach.

You are very welcome.