
Pony 0.29 - spooneybarger
https://www.ponylang.io/blog/2019/07/0.29.0-released/
======
anaphor
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.

------
the_duke
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
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](https://news.ycombinator.com/item?id=15558051)

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

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

~~~
spooneybarger
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](https://opencollective.com/ponyc)

We also have a Zulip community that folks can stop by, chat, and learn more:

[https://ponylang.zulipchat.com/](https://ponylang.zulipchat.com/)

~~~
tzjmetron
I really wish someone from the Pony community would write a book. The official
tutorials are nice, but the parts on the various reference capabilities
onwards is extremely confusing (and sort of bare).

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.

~~~
spooneybarger
Re: a book.

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.

[https://ponylang.zulipchat.com/](https://ponylang.zulipchat.com/)

~~~
tzjmetron
Yes, that's what I feared as well. If I had had some solid experience with
Pony already, I'd volunteer in a heartbeat. Still, many thanks for helping
keep Pony alive, Sean!

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

~~~
strmpnk
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
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.

~~~
strmpnk
It's definitely true, though likewise, it's expensive to use locks in such
places too. The main idea with Pony's runtime is that contending for an actors
attention will certainly incur costs but independent pairs of actors should
not, even during GC.

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.

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

------
iddan
How is it compared to the D language?

~~~
spooneybarger
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"

~~~
zzzcpan
> "Like Erlang meets Rust"

Pony is more like just Rust and nothing like Erlang.

~~~
Mikeb85
Concurrency by using an actor model is the Erlang part...

~~~
spooneybarger
Scott Fritchie did an excellent talk on the similarities and differences
called "The wide world of almost-actors: comparing the Pony to BEAM languages"

[https://www.youtube.com/watch?v=_0m0_qtfzLs](https://www.youtube.com/watch?v=_0m0_qtfzLs)

