TypeScript certainly has a more complicated and flexible type systems in many respects, but it is not the same w/r/t safety. It is quite common to run across `any`s all over the place in TypeScript code, and there is no such thing in OCaml. TypeScript's systems is explicitly unsound (i.e., not fully type safe) by design: https://www.typescriptlang.org/docs/handbook/type-compatibil...
yujzgzc|3 months ago
But if you write without the escape hatches in both languages, in my experience the safety is exactly the same and the cost of that safety is lower in TypeScript.
A very common example I've encountered is values in a const array which you want to iterate on and have guarantees about. TypeScript has a great idiom for this:
``` const arr = ['a', 'b'] as const; type arrType = typeof arr[number];
for (const x of arr) { if (x === 'a') { ... } else { // Type checker knows x === 'b' } } ```
I haven't experienced the same with Ocaml
debugnik|3 months ago
And second, you're dismissing the fact that TypeScript is unsound, even worse it is so by design. Easy examples: uninitialized variables holding undefined when their type says they can't [1]; array covariance [2]; and function parameter bivariance, which is part of the TypeScript playground's own example on soundness issues [3] but at least this one can be configured away.
C# and Java made the same mistake of array covariance, but they have the decency of checking for it at runtime.
[1]: https://www.typescriptlang.org/play/?#code/DYUwLgBAHgXBB2BXA... [2]: https://www.typescriptlang.org/play/?#code/MYewdgzgLgBAllApg... [3]: https://www.typescriptlang.org/play/?strictFunctionTypes=fal...
As for your example, I agree that TypeScript unions and singleton types are powerful, but I can't see what are you speficially missing here that pattern matching and maybe an additional variant type doesn't get you in OCaml. You get exhaustiveness checking and can narrow the value down to the payload of the variant.