> That made me curious on your perspective on Result types ala Rust (I think Go > has that idea as well but I haven't written a single line of code in it, so > no clue).
For attribution, Haskell's `Maybe` and `Either` type and C# popularizing them via their own `Maybe` Monad inspired Rust. And Rust's pattern matching is inspired by Haskell as well. I personally have some issues with Nim exceptions: 1. The exception hierarchy. To use a management consulting terms, when introducing a taxonomy, I like MECE: Mutually Exclusive, Collectively Exhaustive. But often I just don't know how to classify say a tensor out-of-bounds, is it an IndexError? is it a RangeError? Should I create a library specific derivation? And once you figure that out, is that inheritance thing actually used anywhere? 2. The heap allocation. Heap allocation severely restricts where they can be used, not on GPU, not in situations where heap allocations are avoided (embedded, cryptography, safety-critical, ...) 3. Executors, be it multithreading runtimes or async executors, exceptions need special handling, or the closure need to enforce `raises: []`: > * In the past exceptions were just incompatible with multithreading due > to thread-local heaps. > * The reraised exceptions are unreadable in async. And the improved > readability of stacktraces is the main draw of exceptions. And even for that, > pretty sure we can use Result and a macro for emulating stack traces. See also this 2018 discussion with the Nimbus team on error handling: * <https://gist.github.com/zah/d2d729b39d95a1dfedf8183ca35043b3> * <https://joeduffyblog.com/2016/02/07/the-error-model/>
