Pony 0.25.0 released
ponylang.io
ponylang.io
My one hang up right now is the other half of the elixir magic: OTP. In particular supervision trees and genservers.
While Pony has an actor model and message passing for concurrency, I wasn't able to find anything OTP-like. What's more, I read some things that it was even impossible to express in the language since there's no mechanism to block and wait for a message. Is this true? Are there any plans down the line for support of this?
This book is imho a fantastic read that helped me understand Erlang a lot.
Expand the concept to trees of dependencies and several possible after-crash strategies and you get very resillient apps.
But to fully appreciate it, you have to try it. It sounds pretty generic when advocated for but when you code a bit around that, it gets pretty amazing.
[0] http://jlouisramblings.blogspot.com/2010/11/on-erlang-state-...
There is Sebastian's thesis which has an approach idea... https://www.ponylang.io/media/papers/a_string_of_ponies.pdf
And Sylvan and I spent a good amount of time discussing how to implement. Then a lot was learned while building Wallaroo over at Wallaroo Labs, we'd certainly lean on stuff from there as well.
If anyone is interesting in working on distributed Pony, we'd be happy to help support you. Come by the IRC or developer mailing list. Let's chat.
But, its not something that anyone is working on right now.
There are no block and wait patterns. That is true.
You need to structure you app as an async one. All communication between actors is async. This has the nice side-effect of making it really hard to write in a deadlock.
There are no plans to and wait at this time. It's not something that folks who are using Pony call for. It is something that folks coming from Erlang/Elixir want to see.
Perhaps they end up dropping off and we end up with confirmation bias that our approach is right. Perhaps we are on to something.
OTP wise, more patterns built into a library would be awesome and anyone who wants to take that one, we'd be happy to help support their effort.
#ponylang on Freenode
While I have your attention:
Pony is an all volunteer project. We could really use your support. We'd love to get more contributors of all stripes. Code, documentation, design work. All of it! Come by the developer mailing list (https://pony.groups.io/g/dev) or #ponylang channel on Freenode and we'll get you started.
And if you can't contribute time, we are now taking donations to help pay for expenses: https://opencollective.com/ponyc
O also, if you are in London in early November. Sylvan and I are doing a Pony tutorial at Code Sync. Tickets are still available. If you click on the tutorial title on this page: https://codesync.global/conferences/code-mesh-2018/tutorial/
Tickets are still available.
_edited to fix broken links_
I've been dreaming of ways to help bootstrap the Pony lang/lib interop story and build toward a numerical interactive programming environment, being able to combine Pony's native async Actor model and runtime safety guarantees, while also safely being able to hook into to an external ecosystems existing numerical computing, data structure, and GPU/TPU accelerator libs.
I seem to remember someone giving a lang talk a while back where in the Q&A the speaker said integrating with Pony might be a good fit. I was looking into dependent types at the time...it may have been Idris or OCaml, and hooking into the Julia ecosystem would be most interesting, with maybe even Zig acting like low-level LLVM glue code binding all the external C libs together.
In my dream I have it all and the Pony too! All the lang libs are hooked together in a typed-provable way, and when fully connected they combine to form a high-performance, interactive parallel distributed programming environment, and it runs in the browser too. What do you think, is that too much of a DeepDream?
Hooking up Python and Pony is fairly straightforward for example. We've done it at Wallaroo Labs. That's very much "embedded a Python interpreter inside a Pony process" approach. Perhaps you are thinking of something different?
I'm not really sure what you are thinking of. If you sent your ideas to the user mailing list, someone might have some ideas. Something a bit more concrete might help on that front.
My paper cuts with Pony were:
a) No assertions/ unhandled exceptions. I believe things like divide by zero or any other case where you want an assertion should exist.
The actor model makes this easy, in theory. Actors are boundaries so just unwind to the actor boundary on exception and have your actor handle the failure from there. Sort of a 'catch all'.
My expectation is this is already how a ton of errors get handled in pony - bubble up to actor, handle. A pony dev can correct me here if that's not the case.
b) The conversions between types needs sugar. I remember some 'recover' statements that were really boilerplatey.
Maybe this is also an issue of compiler errors, if they'd guided me. But sugar around this would be nice as well.
When you say assertion, do you mean, that you want to program to exit? If yes, that's fairly easy to do. We have several different variations of that in the Wallaroo code base.
Speaking as a Pony core member, I'd be open to adding a primitive to exit the program with an error message to the standard library. We have an RFC process for that: https://github.com/ponylang/rfcs/
And there are several examples from Wallaroo of that here:
https://github.com/WallarooLabs/wallaroo/tree/master/lib/wal...
Implicitly?
> When you say assertion, do you mean, that you want to program to exit?
No, I mean that in some cases I know better than the compiler. For example, in a case where something is T or None, but I know it's T. If T is None, it's a bug - but I don't want my whole program to crash. Ideally it would propagate up to some boundary where there's little enough shared state (the actor boundary) that I can restart my process without having to go through the whole program being restarted.
Otherwise my actor boundary becomes the entire process, and I feel like that sort of defeats the purpose of having extremely cheap, efficient actors.
So definitely not a 'kill the program' but a 'this feature has a bug, wind up the actor and restart it, but no other actors should blow up unless this is a direct dependency of theres'.
Basically the way Erlang does it afaik
I say this as an outsider. What you have may work for you, and maybe it's the right decision. That was just my impression as someone trying to use the language.
Also OOM killing my program.
I'm not sure how you define "implicitly"
You have to declare that your function can propagate an error but otherwise do not have to handle in the function for example
primitive Foo fun propagates_an_error(x: U32, y: U32): U32 ? => x/?y
Will propagate the error you can get from y being 0. The ? in the return signature is required to indicate that an error can happen.
- Re: assertions. We'll you can certainly do what you want when you know that haveing None from T or None is a bug. There is no "crash the actor" and start over in Pony. But it would be interesting to see what people came up with for patterns to "reset actor state"
The more languages the merrier, specially type safe ones for distributed computing.
If we had lots of paid folks working full time, we'd be further along.
What is the effort? A lot. Not trying to be pithy, but it really is a lot of work.
We'd love to have more volunteers to help out. And for folks who can't contribute time, we've started accepting donations so we can pay for hosting and other costs: https://opencollective.com/ponyc
Oh,no.
Additionally, one of the language designers, Sylvan Clebsch, now works at Microsoft Research, so in a way Microsoft is also sponsoring the work on Pony.
I'm the VP of Engineering at Wallaroo Labs. Pony existed prior to Wallaroo Labs using it, but we have been very instrumental in pushing the language and runtime forward. We've contributed a lot of code to Pony.
If you are interested in the early history of Pony you can learn more from Sylvan's post here:
https://www.ponylang.io/blog/2017/05/an-early-history-of-pon...
He definitely isn't churning out tons of code for Pony these days. He is still, however, actively involved. From time to time, big new things from him show up. The latest one has been cooking for several months now and probably won't show up for a few more.
Pony is very "roll your own libraries" or "wrap a c library" at this point in time. Still pre-1.0.
Lots of chance for folks to contribute and make there mark is the optimistic way I look at it. Pessimistic view is "not many libraries".