5 ms·

Although it's technically a more complex case, I think many developers would intuitively understand something like this: const base: BaseClass = new SubCla

Although it's technically a more complex case, I think many developers would intuitively understand something like this: const base: BaseClass = new SubClass(); const keys = Object.keys(base); // should give you the subclass keys as well (This is pseudo-code that might not quite work due to how prototypes and classes interact, but I'm trying to illustrate a principle.) What's perhaps a bit surprising is that all types in TypeScript behave like BaseClass in this example. Object types (e.g. {a: number, b: string}) specify the minimally required properties, not the maximally allowed properties -- they are effectively the same thing as interfaces. Any concrete object that implements the interface can have more properties than the interface requires. That's so fundamental to the type system that I think if you want to work around it, you might not fully understand how TypeScript works yet.

ygra 3y ago
That's precisely the example that Anders gave and the article quoted. And yes, that makes the issue very apparent (as well as Object.keys({}) having to return never[] by TypeScript's rules).
nextaccountic 3y ago
> Object types (e.g. {a: number, b: string}) specify the minimally required properties, not the maximally allowed properties -- they are effectively the same thing as interfaces In contrast, OCaml's objects differs <a: int; b: int> (exactly those fields) from <a: int; b: int; ..> (may have more fields). Likewise for Purescript records etc This stuff was figured out decades ago. There was no need for Typescript to be like this
- chii 3y ago
  > There was no need for Typescript to be like this typescript is strictly a superset of javascript, and javascript is like this.
  - skinkestek 3y ago
    To build on this: I think it is also a large part of the reason why TypeScript is amazing and very useful in the real world.
    - giraffe_lady 3y ago
      Because you need a ridiculously complex type system to model JS's behavior and then in the end don't even get soundness for all your trouble? I know this comes across as really hostile but I just feel very burned by TS's promises and hype. You can work in it more confidently than JS I think but a lot of that is due to the tooling. In exchange you massively increase the required knowledge and mental modeling to keep track of what's going on and why. I used to be all about it but now after using it in a few big projects I've lost the enthusiasm. Someone on here once described it in an excellent way, saying it's great for working out "type puzzles," which smart engineers tend to experience as important and productive. But the actual practical benefits in "the real world" as you say I'm becoming less and less convinced of.
      - amitport 3y ago
        A sorry, it's really not that complex. That's just a matter of opinion and depends on what you compare with. B You say you are less convinced of the "real world" benefit and actually specify the main one: "a lot of that is due to the tooling"... great tooling requires specific typing, this is a only a compile-time pass.
        giraffe_lady 3y ago
        Yes obviously it's opinion and I was offering mine. It's more complex than other languages with similar benefits. Languages with type systems as sophisticated as TS give you MUCH stronger assurances for it. Languages with less sophisticated type systems give you much stronger assurances for it. People are bringing up ocaml in here for very good reason. It has a fairly limited and simple type system compared to TS yet is able to make strong assertions based on it. Rescript is an excellent example of how this could have been applied to JS. This is the core tradeoff of being a superset of JS, but as more time passes it's harder to see the other benefits of that. You need a compiler anyway.
toastercat 3y ago
> That's so fundamental to the type system that I think if you want to work around it, you might not fully understand how TypeScript works yet. I think most engineers who use (and swear by) TypeScript don't fully understand how TypeScript works (or JavaScript for that matter). I've worked across multiple teams at multiple companies and always run into types I can't trust because they are just plain wrong and inconsistent with the runtime, or data that isn't typed correctly. I also found that everyone writes TS differently, and sometimes the verbose typings and weird non-idiomatic patterns introduced just to please tsc actually make the code harder to read (30-line JS modules become 120-line TS behemoths). I still prefer working with TS on teams (though I prefer JS on solo projects now), but after a while I ask "is this the best we can do?" /end minirant

ygra 3y ago

That's precisely the example that Anders gave and the article quoted. And yes, that makes the issue very apparent (as well as Object.keys({}) having to return never[] by TypeScript's rules).

nextaccountic 3y ago

> Object types (e.g. {a: number, b: string}) specify the minimally required properties, not the maximally allowed properties -- they are effectively the same thing as interfaces In contrast, OCaml's objects differs <a: int; b: int> (exactly those fields) from <a: int; b: int; ..> (may have more fields). Likewise for Purescript records etc This stuff was figured out decades ago. There was no need for Typescript to be like this

chii 3y ago
> There was no need for Typescript to be like this typescript is strictly a superset of javascript, and javascript is like this.
- skinkestek 3y ago
  To build on this: I think it is also a large part of the reason why TypeScript is amazing and very useful in the real world.
  - giraffe_lady 3y ago
    Because you need a ridiculously complex type system to model JS's behavior and then in the end don't even get soundness for all your trouble? I know this comes across as really hostile but I just feel very burned by TS's promises and hype. You can work in it more confidently than JS I think but a lot of that is due to the tooling. In exchange you massively increase the required knowledge and mental modeling to keep track of what's going on and why. I used to be all about it but now after using it in a few big projects I've lost the enthusiasm. Someone on here once described it in an excellent way, saying it's great for working out "type puzzles," which smart engineers tend to experience as important and productive. But the actual practical benefits in "the real world" as you say I'm becoming less and less convinced of.
    - amitport 3y ago
      A sorry, it's really not that complex. That's just a matter of opinion and depends on what you compare with. B You say you are less convinced of the "real world" benefit and actually specify the main one: "a lot of that is due to the tooling"... great tooling requires specific typing, this is a only a compile-time pass.
      - giraffe_lady 3y ago
        Yes obviously it's opinion and I was offering mine. It's more complex than other languages with similar benefits. Languages with type systems as sophisticated as TS give you MUCH stronger assurances for it. Languages with less sophisticated type systems give you much stronger assurances for it. People are bringing up ocaml in here for very good reason. It has a fairly limited and simple type system compared to TS yet is able to make strong assertions based on it. Rescript is an excellent example of how this could have been applied to JS. This is the core tradeoff of being a superset of JS, but as more time passes it's harder to see the other benefits of that. You need a compiler anyway.

toastercat 3y ago

> That's so fundamental to the type system that I think if you want to work around it, you might not fully understand how TypeScript works yet. I think most engineers who use (and swear by) TypeScript don't fully understand how TypeScript works (or JavaScript for that matter). I've worked across multiple teams at multiple companies and always run into types I can't trust because they are just plain wrong and inconsistent with the runtime, or data that isn't typed correctly. I also found that everyone writes TS differently, and sometimes the verbose typings and weird non-idiomatic patterns introduced just to please tsc actually make the code harder to read (30-line JS modules become 120-line TS behemoths). I still prefer working with TS on teams (though I prefer JS on solo projects now), but after a while I ask "is this the best we can do?" /end minirant