5 ms·

The following is purely anecdotally, my opinions is solely based on my personal experience with the language. As someone who learned TypeScript just by using i

The following is purely anecdotally, my opinions is solely based on my personal experience with the language. As someone who learned TypeScript just by using it and without any serious "study", I'll have to disagree the basic premise of the article. I already knew about almost everything the article mentioned and nothing really seemed weird to me at the time. The only point that I did not know about is type narrowing not working on nested objects, because that came up exactly 0 times in about 50k lines of TypeScript so far. Half of the points made are actually TypeScript being lenient (interfaces allowing excess properties, classes working like interfaces). In my book this makes the TS easier to work with, because it gets out of the way when it's not needed. Classes essentially working like interfaces is probably a result of TS wanting to be backward compatible with JS, because when you enrich your existing JS lib with type information, TS can't know about your "classes" - they're a runtime thing. Treating them the same as interfaces can make this much nicer. It also allows 3rd party code to add extra properties to your new-instanciated object and using an interface to reflect the change, but still being able to pass it to stuff expecting the original thing. This way you can have type safety without losing JS features.

yawaramin 7y ago
> TS can't know about your "classes" - they're a runtime thing. Treating them the same as interfaces can make this much nicer. No–this is a very surprising and unsound choice and not at all what you would expect if you previously saw that TypeScript lifts classes into types. > This way you can have type safety without losing JS features. IMHO, you can't get type safety out of an unsound type system. (Which TypeScript is, by choice.) I think surprises like the above drive that point home.
- shhsshs 7y ago
  TypeScript’s goal isn’t to be sound. Its goal is to be a balance between type-safety and effort. Full type safety would require a lot of runtime checks injected into the final JavaScript, which TypeScript intentionally avoids. JavaScript will never be fully type-safe without fundamental changes, which will probably never happen.
  - yawaramin 7y ago
    I understand that, which is why I said 'Which TypeScript is [unsound], by choice'. Disagree that full type safety would require a lot of runtime checks. That's not the experience I've had in ReasonML.
    - afiori 7y ago
      ReasonML is exactly the kind of backwards incompatible change that would be necessary. You cannot mix reasonML and JavaScript freely together.
  - nawitus 7y ago
    "Full type safety would require a lot of runtime checks injected into the final JavaScript" Why would this be the case?
    - nitram1 7y ago
      Array access is a good example. Many type-safe languages throw an exception if you attempt to access an element in an array that is out of bounds but javascript just returns undefined. Typescript ignores the fact that accessing an arbitrary element of an array could return undefined. If it did not ignore this fact then it would force you to deal with the potential undefined value retrieved from any array access (i.e you'd need to write a runtime check)
      - wwwigham 7y ago
        Index unsafety w.r.t. bounds and `undefined` is something TS would like to fix; but it's not ergonomic to fix until there are, something like automatic refinement range types applied to array length fields. Without it, TS'd get in the way, demanding `undefined` checks it almost definitely didn't need. Those range types and their complexity are, ultimately, what currently block TS from making these indexed accesses safer.
      - the_gipsy 7y ago
        Some languages do force you to check any time you access an element. If the rest of the language is in line with this, then it's actually amazing. Option/Maybe types help here, pattern matching lists also let's you make sure you handle all cases. In some instances it makes sense to use a special NonEmptyList type that guarantees there is always at least one element, so you don't need to check.
- loxs 7y ago
  The thing is... it doesn't seem to matter. After 30-40k lines of TS code (coming from OCaml) I am still to find a bug where OCaml would have done a better job, except for missing features like nominally typed primitives and no pattern matching. And these are hopefully coming to TS/JS
  - yawaramin 7y ago
    I recommend looking at your frontend console logs for instances of type errors a la https://rollbar.com/blog/top-10-javascript-errors/ https://rollbar.com/blog/top-10-javascript-errors/
    - loxs 7y ago
      My console is fine, definitely do not experience these errors :)
- seanmcdirmid 7y ago
  TypeScript’s goal isn’t absolute type safety, the goal is feedback (eg code completion) and earlier detection of many errors.
  - yawaramin 7y ago
    Yes, I realize that's not the goal which is why I said 'by choice'. I just think it's not the right approach ultimately. Other safer languages also reach the goals of code completion and error detection.
    - seanmcdirmid 7y ago
      Most of the highly typed languages actually do a poor job with code completion and error handling, they were specifically designed with safety in mind and other aspects of the type system are given only secondary attention. TyoeScript is nice because it focuses on where type systems are really useful (feedback) as a first concern.
      - yawaramin 7y ago
        Fortunately, the typed AltJS language with the highest interest levels after TypeScript actually has really good code completion and error reporting :-) Oh, and build speeds so fast that it's blink-and-you-miss-it. I think that's a pretty important part of useful feedback (and one that I hear TypeScript is not that great at).
        seanmcdirmid 7y ago
        Which language is that? Reason? How is its code completion experience anyways? TypeScript has a dog of a compiler, I'll give you that. But that wasn't what I was referring to.
        yawaramin 7y ago
        Yup! See: - https://reasonml.github.io/docs/en/editor-plugins https://reasonml.github.io/docs/en/editor-plugins - https://reasonml.github.io/docs/en/faq#why-are-bucklescript-and-bsb-so-fast-how-can-i-slow-it-down https://reasonml.github.io/docs/en/faq#why-are-bucklescript-... - Oh, and a really fun one from TypeScript: https://news.ycombinator.com/item?id=20045066 https://news.ycombinator.com/item?id=20045066
- heisenbit 7y ago
  > TS can't know about your "classes" - they're a runtime thing. Treating them the same as interfaces can make this much nicer. It helps sticking mostly to interfaces as it helps managing expectations. Class information gets discarded during compilation and that brings with it some quirks. Java Generics is another example where type erasure leads to quirky surprises.

yawaramin 7y ago

> TS can't know about your "classes" - they're a runtime thing. Treating them the same as interfaces can make this much nicer. No–this is a very surprising and unsound choice and not at all what you would expect if you previously saw that TypeScript lifts classes into types. > This way you can have type safety without losing JS features. IMHO, you can't get type safety out of an unsound type system. (Which TypeScript is, by choice.) I think surprises like the above drive that point home.

shhsshs 7y ago
TypeScript’s goal isn’t to be sound. Its goal is to be a balance between type-safety and effort. Full type safety would require a lot of runtime checks injected into the final JavaScript, which TypeScript intentionally avoids. JavaScript will never be fully type-safe without fundamental changes, which will probably never happen.
- yawaramin 7y ago
  I understand that, which is why I said 'Which TypeScript is [unsound], by choice'. Disagree that full type safety would require a lot of runtime checks. That's not the experience I've had in ReasonML.
  - afiori 7y ago
    ReasonML is exactly the kind of backwards incompatible change that would be necessary. You cannot mix reasonML and JavaScript freely together.
- nawitus 7y ago
  "Full type safety would require a lot of runtime checks injected into the final JavaScript" Why would this be the case?
  - nitram1 7y ago
    Array access is a good example. Many type-safe languages throw an exception if you attempt to access an element in an array that is out of bounds but javascript just returns undefined. Typescript ignores the fact that accessing an arbitrary element of an array could return undefined. If it did not ignore this fact then it would force you to deal with the potential undefined value retrieved from any array access (i.e you'd need to write a runtime check)
    - wwwigham 7y ago
      Index unsafety w.r.t. bounds and `undefined` is something TS would like to fix; but it's not ergonomic to fix until there are, something like automatic refinement range types applied to array length fields. Without it, TS'd get in the way, demanding `undefined` checks it almost definitely didn't need. Those range types and their complexity are, ultimately, what currently block TS from making these indexed accesses safer.
    - the_gipsy 7y ago
      Some languages do force you to check any time you access an element. If the rest of the language is in line with this, then it's actually amazing. Option/Maybe types help here, pattern matching lists also let's you make sure you handle all cases. In some instances it makes sense to use a special NonEmptyList type that guarantees there is always at least one element, so you don't need to check.
loxs 7y ago
The thing is... it doesn't seem to matter. After 30-40k lines of TS code (coming from OCaml) I am still to find a bug where OCaml would have done a better job, except for missing features like nominally typed primitives and no pattern matching. And these are hopefully coming to TS/JS
- yawaramin 7y ago
  I recommend looking at your frontend console logs for instances of type errors a la https://rollbar.com/blog/top-10-javascript-errors/ https://rollbar.com/blog/top-10-javascript-errors/
  - loxs 7y ago
    My console is fine, definitely do not experience these errors :)
seanmcdirmid 7y ago
TypeScript’s goal isn’t absolute type safety, the goal is feedback (eg code completion) and earlier detection of many errors.
- yawaramin 7y ago
  Yes, I realize that's not the goal which is why I said 'by choice'. I just think it's not the right approach ultimately. Other safer languages also reach the goals of code completion and error detection.
  - seanmcdirmid 7y ago
    Most of the highly typed languages actually do a poor job with code completion and error handling, they were specifically designed with safety in mind and other aspects of the type system are given only secondary attention. TyoeScript is nice because it focuses on where type systems are really useful (feedback) as a first concern.
    - yawaramin 7y ago
      Fortunately, the typed AltJS language with the highest interest levels after TypeScript actually has really good code completion and error reporting :-) Oh, and build speeds so fast that it's blink-and-you-miss-it. I think that's a pretty important part of useful feedback (and one that I hear TypeScript is not that great at).
      - seanmcdirmid 7y ago
        Which language is that? Reason? How is its code completion experience anyways? TypeScript has a dog of a compiler, I'll give you that. But that wasn't what I was referring to.
        yawaramin 7y ago
        Yup! See: - https://reasonml.github.io/docs/en/editor-plugins https://reasonml.github.io/docs/en/editor-plugins - https://reasonml.github.io/docs/en/faq#why-are-bucklescript-and-bsb-so-fast-how-can-i-slow-it-down https://reasonml.github.io/docs/en/faq#why-are-bucklescript-... - Oh, and a really fun one from TypeScript: https://news.ycombinator.com/item?id=20045066 https://news.ycombinator.com/item?id=20045066
heisenbit 7y ago
> TS can't know about your "classes" - they're a runtime thing. Treating them the same as interfaces can make this much nicer. It helps sticking mostly to interfaces as it helps managing expectations. Class information gets discarded during compilation and that brings with it some quirks. Java Generics is another example where type erasure leads to quirky surprises.