<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?
<achambers>
I suppose the user pool is quite small, but I am super curious about case studies if anyone has migrated existing systems.
<achambers>
hmm, reliability is probably not precise enough of a term.
jemc has quit [Ping timeout: 240 seconds]
jemc has joined #ponylang
jemc has quit [Ping timeout: 240 seconds]
jemc has joined #ponylang
_whitelogger has joined #ponylang
_whitelogger has joined #ponylang
jemc has quit [Ping timeout: 240 seconds]
endformationage has quit [Quit: WeeChat 1.9]
samuell has joined #ponylang
Matthias247 has joined #ponylang
<doublec>
achambers: overloading is an issue with no backpressure
<doublec>
achambers: so a caller of behaviours can outrun an actors ability to process them and eventually OOM
<doublec>
achambers: but in general one would hope for no data race conditions giving increased reliability
<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.
<coopernurse>
is the recommended approach to use some sort of 'Either' type for things that can fail?
<SeanTAllen>
coopernurse: i intend to remove "exception" from the tutorial and replace with "error"
<SeanTAllen>
because it is confusing to folks
<SeanTAllen>
the idea is, if you really need to know what specific error you should
<SeanTAllen>
1. have different try/else blocks
<SeanTAllen>
or use union types
<SeanTAllen>
like (U64 | UnableToDoThingBecauseX | UnableToDoThingBecauseY)
<SeanTAllen>
which is like an Either
<coopernurse>
SeanTAllen: excellent, thanks. are there any examples of errors that work like this in the stdlib?
<coopernurse>
That is, any errors in the stdlib that are expressed via unions?
<coopernurse>
(I'll peruse myself, but if you know one off the top of your head..)
<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"
<coopernurse>
ok thanks - I'm looking at the json parser - it looks like it has a slightly different approach
<SeanTAllen>
the json parser is pretty nasty
<SeanTAllen>
i dont think any of us are happy with it
<SeanTAllen>
if you check the channel history, you'll find more than one conversation about replacing the JSON code
<coopernurse>
bingo. thanks, that's what I'm after
<SeanTAllen>
ah yes, i forgot about that
<coopernurse>
another dumb question - does the compiler have a way to check non-exhaustive matches? failed() has this "else _env.out.print("Unknown ProcessError!")"
<coopernurse>
curious if the compiler could eliminate the need for that
theodus has quit [Quit: theodus]
<SeanTAllen>
coopernurse: we didnt used to but we do now
<SeanTAllen>
so there's still code from the pre-exhaustive match days around
<coopernurse>
ah, that's cool it's supported
<SeanTAllen>
when you find code like that, we'd love PRs