This is equivalent to:

    let x = match may_fail_who_knows() {
        Ok(y) => Ok(another_computation_which_can_fail(use_value(x))),
        Err(e) => with_some_error_handling_that_can_rescue(
            some_error_processing(e)),
    };
    match x {
        Ok(y) => y,
        _ => a_default_value,
    }

It's a bit more verbose than using the combinators, but someone coming across it for the first time will understand it immediately because there's less to remember to understand it (this is where go really shines).

Also: by avoiding functors there are fewer subtle lifetime issues and `move ||` stuff to deal with and you can return from the containing function and use the `?` operator.

During the discussions of how `.await` was going to work for rust async there was the proposal to add other suffix keywords. So this would look like:

    may_fail_who_knows()
    .match {
        Ok(y) => Ok(another_computation_which_can_fail(use_value(x))),
        Err(e) => with_some_error_handling_that_can_rescue(
            some_error_processing(e)),
    }
    .match {
        Ok(y) => y,
        _ => a_default_value,
    }

Maybe not that different.

I would love to use this style but I find myself reverting back to the match syntax.

    match may_fail_who_knows() {
      Ok(success) => {
        do_something_with_success(success)?
      },
      Err(failed) => {
        some_error_processing(failed)
      }
    }

As `do_something_with_success` in a closure can't early return from the function (since it's in a closure), which makes sense, but just annoying to read nested results.

And

    let result = may_fail_who_knows()?
      .use_value_which_might_also_fail()?
      .use_a_different_way_that_might_fail()?;

That does clean stuff up a bit, but still requires nesting if you need to access more than one value generated in the chain at a time. Go's pattern of val, err := ... is a little cleaner in that regard, but does have a lot of redundant if err != nil checks.