And in the end you haven't gained anything, the functions that you use inside the block can still throw exceptions so you need a try/catch anyway.
It's cool as an exercise, but I would never use it practically (in js). In other languages that fully support sum types and errors-as-values (like Rust). I find it a joy to work with and like it much more than exceptions.
Objects have always been able to do a lot of what ADTs do and vice versa.
There's no support for sum types in js, or good support for pattern matching. If you like to use your home-grown Either type in js then more power to you. But there's no denying that you're shoehorning a concept into the language that it doesn't have good support for.
There's no support for sum types in js
Using TSc is a linter, there 100% is support. I'd be happy to demonstrate if you're interested. Though it's a bit beside the point, despite having access to them I didn't implement them that way as I prefer method chaining.
or good support for pattern matching.
What pattern matching do you need for an either type? I enjoy pattern matching for lists, but even when using languages with pattern matching I don't use them for Option/Maybe, or Either. I was under the impression it was an anti-pattern to use pattern matching where a suitable function existed.
But there's no denying that you're shoehorning a concept into the language that it doesn't have good support for.
I deny it. IMO you can create a perfectly usable Either Type in any language that supports classes, objects and generics (well, maybe not C++). There's a lot I miss in JS from Ocaml and F#, but monadic error types are not one of them, because they're easy to implement and just as ergonomic.
There's more than two ways to skin a cat, and after going back and forward between OO and FP for a while I realised I could accomplish the bulk of what I wanted in both paradigms.
I'm critiquing the implementation shown in the blog, not your hypothetical implementation in typescript that I've never seen.
> What pattern matching do you need for an either type?
In nominal type systems like Rust/Haskell/F# you want to be able to match on the constructor. In typescript where '|' means something slightly different you need to fake a type constructor by adding a type: "variantname" property
> I deny it. IMO you can create a perfectly usable Either Type in any language that supports classes, objects and generics (well, maybe not C++).
That was not what you originally wrote:
The fact is that it's forcing a concept that can't be expressed in the language properly.
Your claim was that it cannot be expressed in the language properly, and I am disagreeing.
You didn't answer the question, what useful pattern matching can you do with Either/Option? Give me pseudocode even.
A few jsdoc comments and tsc command, and hey presto - it does.