Pony 0.29

https://www.ponylang.io/blog/2019/07/0.29.0-released/

by spooneybarger • 7 years ago

113 19 7 years ago

the_duke• 7 years ago

I was very interested in Pony a few years ago but haven't kept up with it.

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?

mahmoudimus• 7 years ago

I was also intrigued by Pony -- but lost interest when the company backing it shut down. I don't think it was due to monetization though, I think it formed a foundation, but do not quote me on that.

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

[2] https://www.wallaroolabs.com/

[3] https://github.com/WallarooLabs/wallaroo

spooneybarger5• 7 years ago

Hi Pony core team member here and also, VP of Engineering at Wallaroo Labs.

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:

https://ponylang.zulipchat.com/

iddan• 7 years ago

How is it compared to the D language?

spooneybarger5• 7 years ago

Rather different.

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"

zzzcpan2• 7 years ago

"Like Erlang meets Rust"

Pony is more like just Rust and nothing like Erlang.

andromeduck• 7 years ago

Got this confused with FiM++ for a second, reading the comments was a bit surreal.

anaphor• 7 years ago

I've started learning Pony recently and I definitely recommend checking it out.

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.

swsieber• 7 years ago

Can someone elaborate on this point a little bit:

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.

spooneybarger5• 7 years ago

Short version:

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).

strmpnk2• 7 years ago

It would be possible to livelock the system but deadlocks are easier to avoid: don't use locks [1] at all in the runtime and don't expose them in the language.

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.

RantyDave• 7 years ago

Regarding [1], I think there's pain to be had with memory barriers and such like unless one is very careful. In short, they're expensive.

zzzcpan2• 7 years ago

It seems like it'd be possible to have a deadlock without actual locks

Yes, but not in actor model even by formal definition of deadlocks.

Pony 0.29

Related Stories