Your comment is helpful, so this sarcasm isn't directed at you. However, this looks like an extremely cumbersome way to wish your language had the Result monad.
I upvoted both your comment and GP. Here, hopefully this helps your comment feel more productive: this is a Result type, albeit yes not a Monad. It’s (AFAIK) the idiomatic way the type is expressed in Go, so maybe cumbersome to implement but trivial to adopt.
It’s also something I realized was lost in the JS progression towards Promise APIs and eventually async/await. Promises have ergonomic benefits over callback hell, but damn if the Node convention of cb: (error, result) => { /* … */ } wasn’t a Result type sitting there begging to be embraced. Again, not a Monad, but it’s a shame the good API design was thrown out with the inconvenient API design.
FWIW, that's because Rust also doesn't have a Result monad, it merely has a Result type: in Haskell, you would provide the actual operations of the Monad trait for your Result type--the way in which values are converted into and used from within the type: two functions called return and (>>=)--which would allow you to delegate the execution of that abstracted boilerplate to the language's do-notation.
It’s also something I realized was lost in the JS progression towards Promise APIs and eventually async/await. Promises have ergonomic benefits over callback hell, but damn if the Node convention of cb: (error, result) => { /* … */ } wasn’t a Result type sitting there begging to be embraced. Again, not a Monad, but it’s a shame the good API design was thrown out with the inconvenient API design.