3 ms·
I haven't touched Pony in a while but it holds a lot of promise. My paper cuts with Pony were: a) No assertions/ unhandled exceptions. I believe things like d
by staticassertion 8y ago
I haven't touched Pony in a while but it holds a lot of promise.
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.
- spooneybarger 8y agoAll exceptions have to be handled, but they don't have to be handled at the call site, you can have them propogate back up if you want. 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/ https://github.com/ponylang/rfcs/ And there are several examples from Wallaroo of that here: https://github.com/WallarooLabs/wallaroo/tree/master/lib/wallaroo_labs/mort https://github.com/WallarooLabs/wallaroo/tree/master/lib/wal...
- staticassertion 8y ago> All exceptions have to be handled, but they don't have to be handled at the call site, you can have them propogate back up if you want. 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.
- spooneybarger 8y ago- Re: exceptions and implicity? 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"