> I’ve not yet seen an explanation of what a monad is that I could understand. Monads are just too abstract for me to grasp, let alone reasoning about.

I had a similar thought about the Option monad when I was learning Scala at the time. My thought at the time was "why are you making it so damn hard for me to get access to underlying value?". At the time I kept trying to "unwrap" the value and continue using it.

Hang in there. An intuitive understanding of monads is necessary to understand how to work with monads like Result fluidly.

For learning monads the best way is to just read tons of different sources and tutorials on them. A lot of them won't make any sense. You might get a tiny hint each time and then it will just click.

Part of the reason monads are hard to understand is because they are typically taught only at the abstract level. You need to see concrete examples first, otherwise it's just a floating abstraction that you can't ground to existing knowledge.

I recommend finding some Javascript tutorials on monads because in the beginning I think a focus on types creates too much noise. Ignoring types will make the intuition stand out more.

You can also get most of the intuition behind the monad pattern by concentrating on just "functor composition".

Imagine:

fnReturningArray().map(doA).map(doB).map(doC)

Then,

fetchPromiseResult.then(doA).then(doB).then(doC)

What do they have in common?

Now you can create "combinators" to make it simpler:

pipe(doA, doB, doC)(fnReturningArray())

The "pipe" function is a generic utility that will work with any type/abstraction that follows the "functor" pattern.

Once you get familiar with the functor / monad intuition you can use and even build you own higher level combinators.

This is a large motivation behind the Result / Either monad. It creates a common pattern that higher order combinators can reuse. In essence, from the constraint of following the functor / monad laws, you get tons of higher order abstractions for free.