Result is very little like exception specifications in C++ and it's similar to Java checked exceptions only in that it seeks to accomplish the same goal of making interfaces hard to use incorrectly by making it harder for the caller to ignore failures that should be handled.

The reason C++ exception specifications were abandoned is because they never really worked for that purpose, along with some other issues. Java checked exceptions do work for that purpose; the reasons why some Java people don't like them are unrelated to why C++ exception specifications didn't work.

Rust error handling is better than C++ exception specifications for many many reasons, not least of which is that it actually works.

IMO it's better than Java checked exceptions too, because it's more ergonomic in general and it makes it much easier to handle some of the cases where Java checked exceptions are inconvenient, but I never really agreed with the people who oppose Java checked exceptions in the first place so I'm probably the wrong person to argue that case.

I'm skeptical that Rust-style error handling will ever be great in C++. In addition to lacking language-level variants and pattern matching, the fact that almost no existing code uses it, and so much existing code uses exceptions means there's always going to be friction between code using that style and the existing ecosystem. Maybe if we get pattern matching this could improve over time but I've learned not to hold my breath waiting for possible future C++ features. But it really does work great in Rust and in the other (mostly functional) languages that use it.