00:36 <achambers> In practice, what are the implications of crash and deadlock free? Are system failures shifted to things like resource leaks and overloading at bottlenecks? Is there evidence of increased reliability?

00:40 <achambers> I suppose the user pool is quite small, but I am super curious about case studies if anyone has migrated existing systems.

01:01 <achambers> hmm, reliability is probably not precise enough of a term.

11:03 <doublec> achambers: overloading is an issue with no backpressure

11:04 <doublec> achambers: so a caller of behaviours can outrun an actors ability to process them and eventually OOM

11:05 <doublec> achambers: but in general one would hope for no data race conditions giving increased reliability

23:29 <coopernurse> hello! silly newb question here: in the 'else' block of a 'try' is there any way to get info about the error? the docs say "Pony exceptions do not have a type or instance associated with them", so I'm unsure how to do something smart when an error happens.

23:30 <coopernurse> is the recommended approach to use some sort of 'Either' type for things that can fail?

23:43 <SeanTAllen> coopernurse: i intend to remove "exception" from the tutorial and replace with "error"

23:43 <SeanTAllen> because it is confusing to folks

23:43 <SeanTAllen> the idea is, if you really need to know what specific error you should

23:43 <SeanTAllen> 1. have different try/else blocks

23:43 <SeanTAllen> or use union types

23:44 <SeanTAllen> like (U64 | UnableToDoThingBecauseX | UnableToDoThingBecauseY)

23:44 <SeanTAllen> which is like an Either

23:45 <coopernurse> SeanTAllen: excellent, thanks. are there any examples of errors that work like this in the stdlib?

23:45 <coopernurse> That is, any errors in the stdlib that are expressed via unions?

23:45 <coopernurse> (I'll peruse myself, but if you know one off the top of your head..)

23:48 <SeanTAllen> off the top of my head, no. at some point file needs to be switched to use them. the standard library was mostly written in a way that `error` works for expressing "problem"

23:49 <coopernurse> ok thanks - I'm looking at the json parser - it looks like it has a slightly different approach

23:50 <SeanTAllen> the json parser is pretty nasty

23:50 <SeanTAllen> i dont think any of us are happy with it

23:50 <SeanTAllen> if you check the channel history, you'll find more than one conversation about replacing the JSON code

23:50 <coopernurse> ah, ok - I was looking at this: https://github.com/ponylang/ponyc/blob/master/packages/json/json_doc.pony#L57

23:50 <SeanTAllen> ha

23:50 <SeanTAllen> that one

23:50 <coopernurse> where parse() could raise an error, and then you could ask it why

23:52 <coopernurse> that doesn't seem too bad, but maybe a response union type from parse() would be better?

23:53 <theodus> the process package handles errors using union types: https://github.com/ponylang/ponyc/blob/master/packages/process/process_monitor.pony#L148

23:54 <coopernurse> bingo. thanks, that's what I'm after

23:54 <SeanTAllen> ah yes, i forgot about that

23:56 <coopernurse> another dumb question - does the compiler have a way to check non-exhaustive matches? failed() has this "else _env.out.print("Unknown ProcessError!")"

23:56 <coopernurse> curious if the compiler could eliminate the need for that

23:58 <SeanTAllen> coopernurse: we didnt used to but we do now

23:58 <SeanTAllen> so there's still code from the pre-exhaustive match days around

23:59 <coopernurse> ah, that's cool it's supported

23:59 <SeanTAllen> when you find code like that, we'd love PRs