3 ms·

> It also has tagged unions, product, and sum types, nullability, and extensive capabilities for typing 'this'. So I'm left to ask what exactly is the unique ad

> It also has tagged unions, product, and sum types, nullability, and extensive capabilities for typing 'this'. So I'm left to ask what exactly is the unique advantage of writing JS in OCaml? Because it's not immutability. Remember too, that OCaml has plenty of warts. I have similar feelings to be honest. Working in TypeScript, I know I can easily Google for JavaScript snippets, libraries and issues when required but if I'm working in OCaml it would feel too isolating. In TypeScript, I'm already using immutability, non-null/undefined types, no implicit any types, modules, map/reduce/filter etc. I'm not sure OCaml has enough advantages to overcome the downsides of working in a niche framework right now. I do miss OCaml's terse syntax though.

mirekrusin 9y ago
IMHO TypeScript/Flow missing pieces are 1) runtime side of type system (match) and 2) expressions instead of statements. Those two things complete the type system reaping rewards from annotating code with types. Both TS and Flow have reservations on adding those constructs to the language as it requires runtime support (match) and would be seen as too far departure from js (changing statement -> expression semantics). The unwritten motto of TS/Flow is "stripe type annotations and you've got vanilla js". Adding support for match and expressions would mean adding runtime dependency and transformations which would violate this 1-1 symmetry. This is a shame because type annotations are the hard/boring/sacrifice part, runtime matching is easy/fun/benefit out of it and expressions are just... I don't have words... - why would you think of making any of those statements? It's just pure limitation, adding verbosity, without any reason.