One example of why you would buck the trend would be to use of Left = Ok and Right = Err for a series of "retry" computations. Say you have a few functions of type Either a String, which all get progressively slower, but which work on progressively more advanced input. An example might be a series of regex engines, each of which run slower but handle more and more advanced lookahead syntax. You can then write something like:
makeRegex :: String -> Either Regex ParseError
makeRegex regexExpression = makeBasicRegex regexExpression >> makeLookaheadRegex regexExpression
Today, either lives on as a package: https://crates.io/crates/either It gets a lot of downloads because it is actually used by a few popular libraries: https://crates.io/crates/either/reverse_dependencies
List<LocalDate> dobs = users.stream()
.map(person -> Either.either(person::getDeprecatedDob, person::getDobLocalDate))
.map(oldOrNewFormat -> oldOrNewFormat.fold(
(Date oldFormat) -> convertOldFormatToNew(oldFormat),
(LocalDate newFormat) -> newFormat,
))
.collect(Collectors.toList());
The naming, afaik, comes from the correspondence to the logical disjunction operator and so the constructors name the Left side of the disjunction and the Right side of the disjunction. Seems rather sensible to me.
That being said, I don't think it takes that much energy to remember that the right is the good value. If you are comfortable with monads, just remember that monads must be parameterized over a single type, and for Either that will be the right type (because we must partially apply the type constructor with the left type to get it down to the correct form).
And then clever guys come and use left as the good value, because then want to retry on error (as you can see in this thread). Plus it takes quite some energy to discuss the, well, unfortunate naming.
edit: I should specify that I mean when Either is used as a 'Result' type. There are plenty of other use cases you can use Either outside of Ok/Err values.
Fortunately, Rust didn’t go with Haskell’s foolish Either, Left and Right naming for its error handling type, but gave the enum and its variants meaningful names, obvious semantics and good methods to go with that, so that the Result type has two variants, Ok and Err.
I write plenty of Rust and plenty of JavaScript. I find that various patterns that work very well in Rust don’t work so well in JavaScript; sometimes because I care about performance (runtime and memory) and porting the pattern harms that; and sometimes because of how you can’t conveniently add arbitrary methods to a type like you can in Rust due to its trait system, and so you’d have to give up method call syntax in favour of a hodge-podge of function and method calls. (This becomes a problem with all dynamic languages I know of; this is perhaps most clearly seen in Python where functional programming constructs are second-class citizens, in part because the likes of map are a function rather than a method—well, and because of its lambda syntax.) Also because you’re often working on existing projects that use the normal JS way of doing things, rather than getting to build from scratch, which would more readily allow you extravagances like trying out error handling models unusual for the language.