`neverthrow` and similar libraries are cool and all but there are a few major issues with monadic errors in javascript that make those libraries nothing more than a toy. ive seen people on twitter shilling them some time ago, but javascript is just not ready for that - no syntax sugar for unwrapping (like `?` in rust) (side note: neverthrow provides a `safeTry` that uses generators magic to do something similar, but that's a lot of runtime overhead lol) - generally no single way to build the error info objects. you *can* use a simple ts enum, but you'll miss on having extra info in the errors (and also ts enums suck). you *can* use a discriminated union, but that's syntactically awkward to type. you *can* use simple strings, but like why would you do that at this point - no zero-cost closures. its cool that those libraries provide those fancy `.andThen` and `.orElse` but what's the point if they are expensive as fuck? every `.andThen` is capturing fucking everything, which gets really expensive really soon if you start using results across your codebase. that's also the reason i tend to avoid map/filter/reduce and then/catch - closures are stupid expensive. like at this point why do you even do monadic errors if you are negating *any* performance benefits it gives? - awkward async support neverthrow provides `ResultAsync` type which is basically a wrapper over `Promise<Result<...>>`, but like what's the point if `async` functions always implicitly wrap everything into a normal `Promise` (and not using async functions is dumb because see above) all in all i just hope that eventually js will get native Result type, and typescript will get proper rust-like enums, and until then i guess i'll just keep writing ```ts function safeDoThing(): | { ok: true, thing: Thing } | { ok: false, err: Error } function doThing() { ... wraps the above one ... } ``` in places where errors are often and `throw`-ing be a performance bottleneck