No, not really. Languages that don’t really embrace such a type can usually never make its use ergonomic. Adding such a construct to C or Java would be “trivial” but its use would be exceedingly painful.
Here's an example of a result type in Kotlin implemented as a library monad. (the language is getting an official one but is currently less featureful than this lib)
You can use exception or Result depending on when it makes the most sense and this is the best of both worlds.
https://github.com/kittinunf/Result
Swift had a bunch for a while too, but it’s getting an official one as well. Again, that’s only because the language provides the right tools for it to exist, in languages where you don’t have this you’re going to have a very hard time trying to add these things in.
That depends a lot on what you mean by "use". Pretty much every commonly used language would be able to define something that can hold one of two things and provide ways to determine which one is present and retrieve one of the two options, but comparatively few are going to be able to provide the same guards against accidental or intentional misuse that pattern matching gets you.
Though I don't think it's perfect, languages like Go that treat errors as simply another type and you check as a return value do get closer to treating errors and success symmetrically versus an exception throwing and typing system like some other languages.
Building on that, the ADT languages with full option types here are fantastic here, because the shape of the data in each case can be taught to the compiler.
