If you are using TypeScript (TFA mentions it), fp-ts provides a good functional programming layer. Although if you aren't already familiar with functional programming it's going to be hard as the documentation is rather lacking.
The option type also prevents you from accessing the value if it's absent. Something a C union cannot do. Is there any example of options in an imperative language that would predate ML (which AFAIK introduced Some/None as the variants of option)?
Not that I'm disagreeing with you in any way, but it's worth recognizing that imperative languages typically do pattern matching and type constraining in a declarative manner. So one could make an argument that what you're saying is only true because imperative languages are not forbidden from employing FP. If a language uses declarative constructs, then it's not a wholly imperative language.
I really don't think that FP should be able to take claim for this. Or, at the very least, I don't think the sort of evangelical FP should. Type pattern matching isn't all that different from virtual dispatch if you squint.
If the FP community wants to say that impure languages have been "doing FP" for decades then great! The religious war is over! We can happily have mixed paradigm languages and move on. But that's not what I'm seeing.
fp-ts had many niceties in it, but in Typescript, types are already non-nullanle by default; is there any reason to use Option<string> over string|null? You'd have the same exact type safety either way.
It's a bit high level in that the benefits aren't obvious until you buy into other functional concepts, but basically it's that Options can be layered i.e. Option<Option<string>> is possible. If you just use ordinary union types there's no way to express that.
As an aside, TypeScript is very unsafe by default, and still relatively unsafe with strict mode enabled. Stringent fp-ts usage bypasses these issues.
> still relatively unsafe with strict mode enabled
Is it? I have been using Typescript more and more these last few years, and lately haven't really experienced any issues where it's type system failed me.
To clarify, I'm not trying to argue against your point, genuinely curious to learn if fp-ts can really improve my code quality in production.
It is, for example accessing an array or record doesn't unionise the returned value type with undefined, though this particular gaping hole of unsafety is being addressed in 4.1 with a new flag.
Beyond that there's functions that throw/reject doing so outside the type system, something solved by Either/Option/similar types in fp-ts.
The biggest benefit of fp-ts though is that it makes you think functionally. If you're dead set against that, then there are plenty of other libraries that give you types/wrappers like these without having to use pipe/flow (two functions you'll want to use before anything else in fp-ts).