Go through this concurrent world in the company of a Pony
Concurrency is one of those concepts that I think every seasoned programmer knows quite well. The thing is, I’m pretty far away from being a seasoned programmer and, even though I’ve been coding for about a year now, yesterday was the first time ever I encountered myself with a data-race when I tried to implement a simple chat room service using channels in Go. Pretty insane, huh?
However, in spite of that, yesterday was not the first time that I attempted to create a concurrent application, in fact, for the very first time I had to build a piece of software that was concurrent, I did not have to think about concurrency, data-races, race conditions or any of that, and yet, I got it to work in a concurrent way.
After reading that last paragraph you are most certainly thinking: “Now, that’s insane!” And yes, I suppose that if someone came to me with that same story I would believe that person to be insane as well. But the truth is that I didn’t need to worry about any of that. Why was that? Well, because of a very special programming language called Pony.
As described in its own website: Pony is an object-oriented, actor-model, capabilities-secure, high-performance programming language. It’s also a data-race and deadlock free language because it doesn’t have locks or atomic operations or anything like that. Instead, its type system ensures at compile time that your concurrent program can never have data races. So you can write highly concurrent code and never get it wrong. In summary, when you use Pony, you are forced to write your program in a concurrent fashion without actually thinking about it, and it works that way because the compiler will take care of yelling at you every time you do something wrong, so you end up being concerned about getting your code to compile and not about the implementation details surrounding concurrency. And perhaps the most amazing thing is that you do that without even realizing it!
It all just came to me when I tried to do the same thing, but this time using Go (and channels and goroutines). When I started structuring my program, I found myself over and over again confused about where to put my channels, which parts of the application were supposed to communicate, how was I going to make my entities listen and receive messages. And don’t even let me get started with the data-races! They were coming from everywhere! It was a hot mess… Don’t get me wrong, I like Go a lot and I’m also 100% aware that all of the issues I was having were the result of my poor understanding of how to design a program in a concurrent way rather than because of Go itself.
However, it’s also true that my level of knowledge in regards to concurrency was exactly the same (or even a tad less) when I did the same thing on Pony and it worked. Concurrently. With no data-races whatsoever. And it was beautiful! I mean, shouldn’t something that is as critical and necessary as it is to do concurrent software also be as transparent and straightforward for someone to accomplish as it is in Pony? Even for someone like me who had almost zero knowledge about how to build a program concurrently and had never seen a data-race before? I surely think “hell yeah, it should!” and not because I don’t care about concurrency, quite the opposite, if I can have a language like Pony making me avoid data-races and getting me to do concurrency right just by using it, then I’ll welcome it with my arms wide open.
So the bottom line would be that, if you are going to travel through this concurrent world on your own, you might want to consider to take a Pony with you. It’s dangerous to go alone.
