Presentation: Using Pony for Fintech



10:35am - 11:25am

Day of week:

Key Takeaways

  • Learn about design decisions and implementation details of Pony. 
  • Discuss data-race freedom, fast message queues, scalable work-stealing scheduling, no-stop-the-world garbage collection, and more with a Pony core contributor. 
  • Understand that to keep up with some of the incredible advances in hardware there needs to be a change in how we write software.


Pony is a new actor-model language that's statically typed and ahead-of-time compiled (using LLVM), with a fully concurrent garbage collector and a data-race free type system. But this talk isn't about language features - it's about using Pony in a fintech environment to build high-performance tools.

What are some good design patterns?

What's the worst thing you can do to the Pony garbage collector?

What's the real cost of a message send?

We'll cover the runtime in depth.


QCon: What are you working on these days?
Sylvan: I have been spending most of my time writing the Pony runtime and the type system. Now I am transitioning into the next step for Pony which is writing a production version of the distributed runtime.
Pony’s runtime and type system were built explicitly so that you can take the same program and run it on a Raspberry Pi or a 64-core Xeon or a 4000-core SGI. With the distributed runtime, a Pony program can run on a cluster as well.
QCon: What do you want to achieve with Pony?
Sylvan: The big advancement in tech right now isn’t software, it’s hardware. The hardware is amazing. The hardware guys are doing fabulous things, and there is sort of a funny sense of anger from the software people that we are getting more cores instead of faster cores. And it is our fault for having a bad programming model for dealing with these cores. They are building incredible hardware, and this is true across the board. Things like Raspberry Pi’s up to Xeon Phi’s. Really fun stuff is happening and will continue to happen. Persistent memory is coming. All kinds of interesting hardware is coming.
But what we have missed is integrating the last twenty years of computer science research into our programming models. We’ve spent a lot of time dealing with dynamic languages, which is great. I think that is a good thing but we haven’t spent a lot of time dealing with modern native languages. We are just now starting to get it. For example, Go. Go is brilliant. Go is astoundingly brilliant but their goal wasn’t actually highly fast, highly concurrent computation.
Their goal was an excellent software engineering ecosystem, and they built it. Compile times are fantastic. Tooling is fantastic. All that is fantastic. It has some concurrency stuff, but it has some of the problems as C (data races... that kind of stuff). Rust is great. I am a huge fan of Rust. I would love to re-write the Pony runtime, which is currently written in C, in Rust. But Rust’s focus is very different from Pony’s. Rust’s focus is on systems programming, no garbage collector, no dependencies. The absolute bottom of the stack. Great stuff. Brilliant stuff.
Pony’s focus is a bit different. Pony’s focus is a combination of a statically typed, type safe Erlang-like (in the sense of using actors) language with a much higher performance runtime. One that lets you do all of the fun stuff that you do with generics and parametric polymorphism and all the power that you get out of modern languages like Scala or Haskell. It is funny to call Haskell a modern language but it is. It is still innovative after all this time. Or Rust. Rust has a lot of these great features. The idea behind Pony was to co-design the type system and the runtime so that the type system gives enough guarantees that the runtime can be written for pure performance, that the runtime is lock free. With Pony, you know your entire program is guaranteed to be lock free, data race free and deadlock free by construction. That is pretty fun - but you can still have mutable data. We are not doing this with only immutable data.
You can do this and run without any translation problems when you move from a concurrent to a distributed environment. One of the things that is coming soon in the type system is the concept of machine specific data. The type checker will make sure that you are never trying to send an integer to another machine that is actually a file descriptor because that is not very useful. So doing all this has meant that the Pony runtime gets to cheat. I mean, cheat like crazy. We have a garbage collector that has no “Stop the world” phase. We have separate heaps for every actor.
Every actor can independently collect its heap without coordinating with any other actor and yet we can share data by pointer that was allocated by actor B with actor A. That is pretty fun. It works in a distributed environment and requires a lot less coordination than most distributed garbage collection systems. In fact, for collecting objects as opposed to actors, the nodes don’t have to coordinate in order to collect objects. They can all collect objects locally with no coordination in the same way that an actor collects its heap locally without coordination.
I keep saying no coordination because that is really what it is all about, right? You never do the slow part.
QCon: Where is the language from a maturity standpoint?
Sylvan: To be honest, it is hard for me to judge. Our standard library is not big but it is bigger than it used to be. We have regular expressions, networking, SSL, TLS. We’ve got an HTTP handler, JSON parsers, all sorts of good stuff. The usual collection of collections. Maps and sets and that kind of stuff. But there is a lot of work to do and people are doing it, which is fun. We are getting some people building packages for the standard library. In terms of stability, the runtime is a lot more stable than one would think because the runtime has actually been in production for longer than the language has been open source.
QCon: What does your talk look like?
Sylvan: My goal is to talk about the things that are hard in fintech. They boil down to correctness and performance. I am not going to be talking about distributed systems because I don’t want to sell vaporware. I am going to be talking about running on a concurrent environment. Why would one use Pony instead of Java and C++ ? If there is anyone writing fintech in Rust, God bless them. They should keep doing it. Don’t switch to Pony. Keep doing that awesome thing, but why would one use Pony instead of Java or C++?
I am going to talk a bit about stuff that is hard: data races, message queues, scheduling, things like that. Martin Thompson obviously does tons of cool stuff in this area. Then I want to get into some patterns that make it easier in Pony. Things like modeling orders as actors. I’ll talk about how simple data flow patterns are in Pony because you are sending messages.
Then I also want to talk about things that can kill Pony dead. Horrible things you can do. How can you allocate memory in such a way that Pony can barely free any of it? What kind of message sending patterns choke the runtime? What kind of back pressure patterns choke the runtime? Because I think that is important to talk about. You don’t want to be blowing air up everybody’s back side and telling them “Oh, it’s perfect. It solves all your problems.” Nothing solves all of your problems.
QCon: Who are you targeting with this talk, and what do you want them to get when they walk out?
Sylvan: I am targeting senior developers who understand Martin Thompson’s mechanical sympathy concept, and they know they can do better (and easier). I’m targeting those people who are looking for the right tools.
I want them to go away thinking Pony is something they can use right now. It might help them right now, this is not pie in the sky stuff.


Covering innovative topics

Monday, 7 March

Tuesday, 8 March

Wednesday, 9 March

Conference for Professional Software Developers