Pony 0.29
ponylang.io
ponylang.io
Pros:
- Checked exceptions are pretty awesome
- Built in object capability system means you are forced to be explicit about granting access to files, sockets, etc
- Supports both structural and nominal subtyping
- Generates very fast code as far as I can tell (it uses LLVM on the backend)
- Actor model combined with reference capabilities means you don't have to worry about a huge class of concurrency bugs that the type system just rules out.
- Very good C FFI support so if something isn't available you can easily create C bindings
- Very helpful community on Zulip. You are pretty much guaranteed someone will give you a high quality answer to any of your questions.
Cons:
- Steep learning curve for reference capabilities
- It can be tricky to find the right stdlib functions/types for what you want to do. It wasn't clear to me at first how some things worked, e.g. the relationship between Array and Iter. This is no fault of the API design, just a lack of tutorials on some things.
- Missing a lot of things you might expect to find in other languages like all kinds of built in libraries to do HTTP stuff, etc.
I loved the idea of a compiled, actor based language with safe concurrency primitives; somewhat like a high performance Erlang.
How has Pony faired after the company trying to monetize it failed?
Anyone using it for something serious?
I only know of one (there may be others) that constantly talk about how they're using Pony -- Wallaroo[1][2]. I think they're still actively working on it, based on their Github[3].
[1] https://news.ycombinator.com/item?id=15558051
Wallaroo Labs is the most vocal user of Pony. There are a few others who are playing around with Pony and we hear about from time to time, but we are still in the very early stages as a language. It's definitely a great time to get involved with Pony if you are interested in guiding the direction of the language.
Re "the company backing it". You would be referring to Causality. They shut down quite some time ago. The general belief with Causality was that they would be able to get folks in finance to pay for Pony development and support given that an early version of Pony started at a large bank in London and the open source version was a vast improvement. That didn't happen and so Causality had no path forward.
Sylvan Clebsch, the "inventor" of Pony, has since gone on to work at Microsoft Research. He's a member of the Pony core team that he, myself, and Darach Ennis formed as Causality was shutting down.
Since that time, we've added a couple people to the core team, lost some, and added a bunch of contributors and worked on making steady progress pushing Pony forward.
The Pony core team isn't a foundation but we are on Open Collective and are quite happy to take donations (that at this time, go towards paying for hosting costs and whatnot)
https://opencollective.com/ponyc
We also have a Zulip community that folks can stop by, chat, and learn more:
I know it's a small community, and there really is no official corporate backing, but right now I see the lack of good learning resources as the biggest obstacle, and we have to admit that Pony has a very steep learning curve. I really do love whatever little Pony that I have explored, and the compile times are superb compared to something like Rust, and the generated executables seem to be quite fast as well.
The most likely candidate would be me and it's 100% certain I do not have the time right now.
We've done several attempts at getting other folks to contribute more in that area and it's really hard to find people who are interested.
Finding folks to contribute to most open source projects is hard in general. Finding folks to contribute to documentation, learning resources and what not is really hard.
If anyone reads this and gets inspired to try and help, ping me on the Pony Zulip and I'd be happy to assist in a general "mentoring/guiding" capacity.
> It’s deadlock free. This one is easy, because Pony has no locks at all! So they definitely don’t deadlock, because they don’t exist.
It seems like it'd be possible to have a deadlock without actual locks, so I'm curious what exactly is meant by this, or how they achieve it.
Edit: Thanks for the explanations! That helps clear things ups.
In the sense that most people mean deadlock to mean multiple threads waiting for obtain a lock or otherwise having messed up locking and not being able to make progress, I think that is covered.
There's no concept of waiting for a thing and doing nothing else in Pony. And example would be "selective receive" in Erlang where you can match for a message of a certain type arriving.
In Pony, you give up selective receive. Every message has to be processed, in order, that an actor receives them. This forces a change in programming model and thinking to one that is purely asynchronous message passing.
It can take some getting used to. Lots of patterns that work in other languages don't in Pony because the pattern requires waiting or other synchronous coordination that isn't possible in Pony (unless you use C code via FFI then all bets are off).
The longer answer of how the possibility of a deadlock in user code in Pony is prevented:
* messages are handled FIFO so w/o selective receive or multiple channels, there is no way to skip or wait for a specific message w/o doing work (_progress must be made by receivers_)
* combined with the last one, the sender can't wait for a response as it has to be sent as a FIFO message back (which can come interleaved with other messages; _progress must be made by senders_)
* multiple actors cannot simultaneously modify anything (you can't create a lock out of shared memory + Lamport's bakery algorithm because memory can't be r+w on two threads and even then, your exclusion failure would require explicit looping, so the thread is technically livelocked/starved)
What this results in is a system that always makes progress when more than one actor is involved.
Now that doesn't stop hanging the system (imagine putting N actors in infinite loops, one for each scheduler thread in the pony runtime, which we should call a livelock rather than a deadlock) and of course you could call some kind of C code via the FFI that decides it wants to take a lock or similar exclusive operation. Or there could be a bug in the runtime [2] which is tightly integrated with the language design and its guarantees so it avoids using locks for common things and uses atomic operations which provide a wait-free properties.
[1]: Pony uses atomic operations exclusively last time I looked. Relatively clever and there is room for bugs but theoretically this allows for wait-free progress in the runtime (there's a lot more to say here about theory vs practice but generally lock-free properties are enough here anyway).
[2]: I believe there have been edge cases in Pony's GC which might fall into the bug category but it's been awhile since I've used Pony myself so I can't comment on the current status.
I also glossed over the I/O system and back pressure support which make the above discussion a bit more nuanced but my goal was to lay down some form of intuition around thinking in terms of progress in a system as a guarantee of the concurrency model.
Empirically speaking, there are real limits to what hardware will hide and plenty of room for leveraging knowledge of the system as a whole (esp. the memory model) rather than sticking to one set of abstractions. Pony is no exception here, though the co-design of various features might make that less necessary than it might be in other systems with similar properties as it matures.
Yes, but not in actor model even by formal definition of deadlocks.
Our goals when creating Pony are two make a high-performance, safe languages for writing highly concurrent applications. Pony is much more opinionated than D.
A really quick version of "what is Pony" would probably be:
"Like Erlang meets Rust"
Pony is more like just Rust and nothing like Erlang.