12 ms·

I'm a little shocked at some of the outcry in this thread. People are making it sound like they're switching from Rust to Ruby or extolling the virtues of types

I'm a little shocked at some of the outcry in this thread. People are making it sound like they're switching from Rust to Ruby or extolling the virtues of types: TypeScript does absolutely nothing for you at runtime. There are no types, there are no type checks, its all the same guarantees as good ol' JavaScript. You still can't trust function parameters to be what they say. It's a Babel configuration with inline doc annotations. If people are serious about types, then why isn't more front-end moving over to Elm, Reason, PureScript, OCaml etc? Hell, GWT is still out here even. TypeScript has convinced people they're getting the benefits of (strong?) types when they're just populating the auto-complete in VS Code.

samhh 6y ago
TypeScript is really about type safety within the confines of your application. You can address the unsafety at the edges with something like io-ts.
- diffrinse 6y ago
  But this is a niche application of TypeScript, most day-to-day front-end devs I've interviewed aren't reaching for fp-ts, let alone io-ts, whatever the benefits. Even then, why not just use any one of Elm, PureScript, Reason, ScalaJS, etc? Why implement yet another FP runtime? If something like this is the surest way to make optimal use of TypeScript then I feel like we're just right back where we started. For most devs, I'd wager they're still ending up writing all the same tests they were before TypeScript. tsc even offers to just consume jsdoc annotations for crying out loud. If its just some kind of type convention sandbox, what did it really bring to the table?
  - samhh 6y ago
    Elm's got questionable support; I wouldn't feel comfortable recommending that at work, it'd be irresponsible. PureScript I really like but it's a massive jump from JS/TS to PS/HS. All of these languages are harder to abandon than a library in the same language you'll keep using if you decide against the paradigm down the road. Do I like this compromise? Not really, but it makes sense. Also, advertising use of a functional language might open you up to candidates who wouldn't otherwise apply.
- Shacklz 6y ago
  Wholeheartedly agree and would like to point to another library that is capable of providing runtime typechecks: https://github.com/vriad/zod https://github.com/vriad/zod It doesn't come with the fp-approach that io-ts takes, and has, in my opinion, significantly better error reporting. Just plugging this here because I believe that zod is grossly underused :)
yawboakye 6y ago
AFAIK Elm doesn’t perform runtime checks, does it? One benefit of types is auto-complete, of course. The other benefit is that knowing the type of your input you can successfully guide it through your system to an expected output. That’s how all statically typed languages work: they don’t have runtime checks. It’s not for nothing that teams switching to TypeScript see a decrease in runtime exceptions (speaking from experience). Our bug tracker was reduced by more than 80% after we finally completed the switch from JavaScript to TypeScript.
- vimslayer 6y ago
  Elm doesn't need to perform runtime checks (apart from application boundaries like JSON parsing, where runtime checks are performed) because their type system is supposed to be sound, so you can't compile something that would have incorrect types at runtime. Or if you can, that's considered a bug in the compiler. That kind of sound type system has never been a goal for TypeScript. Note that I'm not saying that Elm would be better than TS or any other language or anything like that, just commenting about the runtime checks. Obviously languages have their strengths and weaknesses (Elm has plenty of both) and TS has had good reasons to go with their design goals.
ex3ndr 6y ago
Because runtime type checking is expensive. If most of your project is in TS then you will never hit type errors in runtime (we are yet to see after two years of development). I have been using GWT, too hard to use comparing to typescript with pretty much same benefits.
dbmikus 6y ago
Static typing, by definition, does nothing for you at runtime.

samhh 6y ago

TypeScript is really about type safety within the confines of your application. You can address the unsafety at the edges with something like io-ts.

diffrinse 6y ago
But this is a niche application of TypeScript, most day-to-day front-end devs I've interviewed aren't reaching for fp-ts, let alone io-ts, whatever the benefits. Even then, why not just use any one of Elm, PureScript, Reason, ScalaJS, etc? Why implement yet another FP runtime? If something like this is the surest way to make optimal use of TypeScript then I feel like we're just right back where we started. For most devs, I'd wager they're still ending up writing all the same tests they were before TypeScript. tsc even offers to just consume jsdoc annotations for crying out loud. If its just some kind of type convention sandbox, what did it really bring to the table?
- samhh 6y ago
  Elm's got questionable support; I wouldn't feel comfortable recommending that at work, it'd be irresponsible. PureScript I really like but it's a massive jump from JS/TS to PS/HS. All of these languages are harder to abandon than a library in the same language you'll keep using if you decide against the paradigm down the road. Do I like this compromise? Not really, but it makes sense. Also, advertising use of a functional language might open you up to candidates who wouldn't otherwise apply.
Shacklz 6y ago
Wholeheartedly agree and would like to point to another library that is capable of providing runtime typechecks: https://github.com/vriad/zod https://github.com/vriad/zod It doesn't come with the fp-approach that io-ts takes, and has, in my opinion, significantly better error reporting. Just plugging this here because I believe that zod is grossly underused :)

yawboakye 6y ago

AFAIK Elm doesn’t perform runtime checks, does it? One benefit of types is auto-complete, of course. The other benefit is that knowing the type of your input you can successfully guide it through your system to an expected output. That’s how all statically typed languages work: they don’t have runtime checks. It’s not for nothing that teams switching to TypeScript see a decrease in runtime exceptions (speaking from experience). Our bug tracker was reduced by more than 80% after we finally completed the switch from JavaScript to TypeScript.

vimslayer 6y ago
Elm doesn't need to perform runtime checks (apart from application boundaries like JSON parsing, where runtime checks are performed) because their type system is supposed to be sound, so you can't compile something that would have incorrect types at runtime. Or if you can, that's considered a bug in the compiler. That kind of sound type system has never been a goal for TypeScript. Note that I'm not saying that Elm would be better than TS or any other language or anything like that, just commenting about the runtime checks. Obviously languages have their strengths and weaknesses (Elm has plenty of both) and TS has had good reasons to go with their design goals.

ex3ndr 6y ago

Because runtime type checking is expensive. If most of your project is in TS then you will never hit type errors in runtime (we are yet to see after two years of development). I have been using GWT, too hard to use comparing to typescript with pretty much same benefits.

dbmikus 6y ago

Static typing, by definition, does nothing for you at runtime.