Very nicely written article.. and yeah, stable-pointer all the things! meme.<p>That said, these issues are why I'm considering switching away from Haskell long-term... but that's not easy, I'm deeply invested, and all the other features let me be really productive / creative. But the occasional weird runtime bug or timesink that takes a week to track down.. could live without that.<p>(There are ways to use the concurrency and queuing primitives like these kind of safely but it needs a deep expertise, there are too many non-obvious parts where you can let an exception slip through at the unintended place or otherwise get yourself burned. Lack of stack traces don't help much either, though that can be somewhat orthogonal)
While I don’t know Haskell or GHC, that sounds like a bug in the runtime.<p>My understanding:<p>- Deadlock detection is a feature some language runtimes can provide.<p>- To my knowledge there’s no reasonable path of recovery from within the process (broad sense of the term) itself.<p>- If you have process isolation then a parent or supervisor can kill and respawn. (Is this what Erlang does?)<p>- Deadlocks are only theoretically detectable in the cases where the runtime can trace the “path” to something it knows about. This may include runtime objects like channels and mutices, but certainly does not include IO etc. For example: program is currently waiting on a tcp socket with no timeout.<p>- As such, deadlock detection is at most moderately useful for typical application debugging and development workflows.<p>Personally I would much rather have easy access to a “what are processes currently blocked on” list than “the runtime is so smart it will error out automagically” kind of thing.