At Wallaroo Labs, where I'm the VP of engineering, we're are building a high-performance, distributed stream processor written in the Pony programming language. Most people haven't heard of Pony, but it has been an excellent choice for Wallaroo, and it might be an excellent choice for your next project, too.
"A programming language is just another tool. It's not about syntax. It's not about expressiveness. It's not about paradigms or models. It's about managing hard problems." —Sylvan Clebsch, creator of Pony
I'm a contributor to the Pony project, but here I'll touch on why Pony is a good choice for applications like Wallaroo and share ways I've used Pony. If you are interested in a more in-depth look at why we use Pony to write Wallaroo, we have a blog post about that.
What is Pony?
You can think of Pony as something like "Rust meets Erlang." Pony sports buzzworthy features. It is:
- Type-safe
- Memory-safe
- Exception-safe
- Data-race-free
- Deadlock-free
Additionally, it's compiled to efficient native code, and it's developed in the open and available under a two-clause BSD license.
That's a lot of features, but here I'll focus on the few that were key to my company adopting Pony.
Why Pony?
Writing fast, safe, efficient, highly concurrent programs is not easy with most of our existing tools. "Fast, efficient, and highly concurrent" is an achievable goal, but throw in "safe," and things get a lot harder. With Wallaroo, we wanted to accomplish all four, and Pony has made it easy to achieve.
Highly concurrent
Pony makes concurrency easy. Part of the way it does that is by providing an opinionated concurrency story. In Pony, all concurrency happens via the actor model.
The actor model is most famous via the implementations in Erlang and Akka. The actor model has been around since the 1970s, and details vary widely from implementation to implementation. What doesn't vary is that all computation is executed by actors that communicate via asynchronous messaging.
Think of the actor model this way: objects in object-oriented programming are state + synchronous methods and actors are state + asynchronous methods.
When an actor receives a message, it executes a corresponding method. That method might operate on a state that is accessible by only that actor. The actor model allows us to use a mutable state in a concurrency-safe manner. Every actor is single-threaded. Two methods within an actor are never run concurrently. This means that, within a given actor, data updates cannot cause data races or other problems commonly associated with threads and mutable states.
Fast and efficient
Pony actors are scheduled with an efficient work-stealing scheduler. There's a single Pony scheduler per available CPU. The thread-per-core concurrency model is part of Pony's attempt to work in concert with the CPU to operate as efficiently as possible. The Pony runtime attempts to be as CPU-cache friendly as possible. The less your code thrashes the cache, the better it will run. Pony aims to help your code play nice with CPU caches.
The Pony runtime also features per-actor heaps so that, during garbage collection, there's no "stop the world" garbage collection step. This means your program is always doing at least some work. As a result, Pony programs end up with very consistent performance and predictable latencies.
Safe
The Pony type system introduces a novel concept: reference capabilities, which make data safety part of the type system. The type of every variable in Pony includes information about how the data can be shared between actors. The Pony compiler uses the information to verify, at compile time, that your code is data-race- and deadlock-free.
If this sounds a bit like Rust, it's because it is. Pony's reference capabilities and Rust's borrow checker both provide data safety; they just approach it in different ways and have different tradeoffs.
Is Pony right for you?
Deciding whether to use a new programming language for a non-hobby project is hard. You must weigh the appropriateness of the tool against its immaturity compared to other solutions. So, what about Pony and you?
Pony might be the right solution if you have a hard concurrency problem to solve. Concurrent applications are Pony's raison d'être. If you can accomplish what you want in a single-threaded Python script, you probably don't need Pony. If you have a hard concurrency problem, you should consider Pony and its powerful data-race-free, concurrency-aware type system.
You'll get a compiler that will prevent you from introducing many concurrency-related bugs and a runtime that will give you excellent performance characteristics.
Getting started with Pony
If you're ready to get started with Pony, your first visit should be the Learn section of the Pony website. There you will find directions for installing the Pony compiler and resources for learning the language.
If you like to contribute to the language you are using, we have some beginner-friendly issues waiting for you on GitHub.
Also, I can't wait to start talking with you on our IRC channel and the Pony mailing list.
To learn more about Pony, attend Sean Allen's talk, Pony: How I learned to stop worrying and embrace an unproven technology, at the 20th OSCON, July 16-19, 2018, in Portland, Ore.
6 Comments