5 ms·

100% this. For a C++ or Rust programmer this reads so weird. Don't get me wrong, I'm not hating on JS here, and I have lots of beef with C++, but I fully agree

by tugu77 2y ago

100% this. For a C++ or Rust programmer this reads so weird. Don't get me wrong, I'm not hating on JS here, and I have lots of beef with C++, but I fully agree with your take that TS barely scratches the surface of the statically typed world.

throwuxiytayq 2y ago
Based on my small amount of work done in TS, it seemed like one of the more advanced type systems out there. To the detriment, even. The language was just huge, and that was years ago.
- eyelidlessness 2y ago
  And it’s so advanced because it was/is designed to represent the types of real world dynamic JavaScript. More often than not, when people complain about the complexity of the types they encounter in the TS type system, they’re really complaining about the types of the underlying JS (which are the same whether they’re expressed statically or not).
  - wk_end 2y ago
    There's a cultural problem in the TypeScript ecosystem, I find, where people are impressed (with both themselves and others) when complex interfaces can be expressed in the type system, and tend to embrace that instead of settling for simpler (and often admittedly more verbose) ones. Maybe that's because they're an ex-JS programmer who wants to use the exact same interface they'd use in JS with no compromise, or maybe it's just because they think it's cool. Either way I think it's really detrimental to TypeScript as a whole.
    - TheHegemon 2y ago
      Do you have some examples for that? Most cases I've seen with more complex interfaces is due to the fact that it is what the interface truly expects. Usually making it simpler tends to mean it's actually wrong or incomplete.
      - wk_end 2y ago
        This is hand-wavey, but that can't be true: less complex type systems manage to express all kinds of interfaces correctly all the time (sometimes at the cost of verbosity, but that that’s usually a good trade-off is the point). You're asking me to tell on my coworkers, and I'm too loyal to throw them under the bus :) Well, OK, here's one, but I'll keep it as blameless as possible. We had a thing where we wanted to register some event handlers. The primary use of these event handlers was to run a selector, and if the selected data changed, trigger an update, passing the selected data along. The initial implementation used existential types to store a list of callbacks, each returning different selected data. The "driver" then did the equality checking and update triggering. We later changed this, so that the callbacks - as far as the driver was concerned - all returned `void`, eliminating the need for an existential type. We just had to move the equality checking and update triggering to inside the callbacks. Some features are straightforward translations: anywhere you have overloading and/or optional arguments you can (and often should) simplify by refactoring into multiple functions. For a concrete, public example...well, I remember the Uppy library had a lot of stuff like this. A lot of work goes into making it's "Plugin" interface look the way it does (start at [1] and keep reading I guess) for instance, and while I haven't sat down and re-engineered it I don't think it needs to be this way, if you're willing to give up some of the slickness of the interface. [1] https://github.com/transloadit/uppy/blob/main/packages/%40uppy/core/src/Uppy.ts#L58 https://github.com/transloadit/uppy/blob/main/packages/%40up...
      - behnamoh 2y ago
        Like this: https://news.ycombinator.com/item?id=14905043 https://news.ycombinator.com/item?id=14905043 and this: https://news.ycombinator.com/item?id=37956856 https://news.ycombinator.com/item?id=37956856
    - gejose 2y ago
      > Maybe that's because they're an ex-JS programmer who wants to use the exact same interface they'd use in JS with no compromise, or maybe it's just because they think it's cool That sounds a little reductive and gate-keepy. Maybe an advanced type system allowing for complex types to be expressed easily actually allows you to write simpler, more effective code. Curious if you have any specific examples though.
    - chamomeal 2y ago
      I think there’s a difference between ideal library code and ideal business logic code. The more you lean into crazy ass generics in your library, the simpler and more error-free the user can make their biz logic code. Really nicely typed libraries almost give you zero chances to fuck things up, it’s amazing. But then again most of your devs wont be able to understand all those generics, so you need to keep your biz logic types relatively simple.
  - shepherdjerred 2y ago
    Adding static typing only shows you how bad your code already is
FractalHQ 2y ago
This isn’t true, is it? I’ve only ever heard that TypeScript has one of the most advanced type systems of any mainstream language.. but I don’t have enough experience with other languages to know how true that is.
shepherdjerred 2y ago
Typescript has one of the most advanced type systems of any of the common languages
deleted 2y ago
[deleted]
chamomeal 2y ago
Nawww I’d say something like python or php is “scratching the surface”. Typescript’s type system is phenomenal and pretty deep. Honestly I think it’s the most interesting one to work with, too. Which is not always a good thing, but it is fun. The only type systems I’ve seen that are similarly expressive are rust and Haskell. Even go doesn’t come anywhere close.

by tugu77 2y ago

throwuxiytayq 2y ago

Based on my small amount of work done in TS, it seemed like one of the more advanced type systems out there. To the detriment, even. The language was just huge, and that was years ago.

eyelidlessness 2y ago
And it’s so advanced because it was/is designed to represent the types of real world dynamic JavaScript. More often than not, when people complain about the complexity of the types they encounter in the TS type system, they’re really complaining about the types of the underlying JS (which are the same whether they’re expressed statically or not).
- wk_end 2y ago
  There's a cultural problem in the TypeScript ecosystem, I find, where people are impressed (with both themselves and others) when complex interfaces can be expressed in the type system, and tend to embrace that instead of settling for simpler (and often admittedly more verbose) ones. Maybe that's because they're an ex-JS programmer who wants to use the exact same interface they'd use in JS with no compromise, or maybe it's just because they think it's cool. Either way I think it's really detrimental to TypeScript as a whole.
  - TheHegemon 2y ago
    Do you have some examples for that? Most cases I've seen with more complex interfaces is due to the fact that it is what the interface truly expects. Usually making it simpler tends to mean it's actually wrong or incomplete.
    - wk_end 2y ago
      This is hand-wavey, but that can't be true: less complex type systems manage to express all kinds of interfaces correctly all the time (sometimes at the cost of verbosity, but that that’s usually a good trade-off is the point). You're asking me to tell on my coworkers, and I'm too loyal to throw them under the bus :) Well, OK, here's one, but I'll keep it as blameless as possible. We had a thing where we wanted to register some event handlers. The primary use of these event handlers was to run a selector, and if the selected data changed, trigger an update, passing the selected data along. The initial implementation used existential types to store a list of callbacks, each returning different selected data. The "driver" then did the equality checking and update triggering. We later changed this, so that the callbacks - as far as the driver was concerned - all returned `void`, eliminating the need for an existential type. We just had to move the equality checking and update triggering to inside the callbacks. Some features are straightforward translations: anywhere you have overloading and/or optional arguments you can (and often should) simplify by refactoring into multiple functions. For a concrete, public example...well, I remember the Uppy library had a lot of stuff like this. A lot of work goes into making it's "Plugin" interface look the way it does (start at [1] and keep reading I guess) for instance, and while I haven't sat down and re-engineered it I don't think it needs to be this way, if you're willing to give up some of the slickness of the interface. [1] https://github.com/transloadit/uppy/blob/main/packages/%40uppy/core/src/Uppy.ts#L58 https://github.com/transloadit/uppy/blob/main/packages/%40up...
    - behnamoh 2y ago
      Like this: https://news.ycombinator.com/item?id=14905043 https://news.ycombinator.com/item?id=14905043 and this: https://news.ycombinator.com/item?id=37956856 https://news.ycombinator.com/item?id=37956856
  - gejose 2y ago
    > Maybe that's because they're an ex-JS programmer who wants to use the exact same interface they'd use in JS with no compromise, or maybe it's just because they think it's cool That sounds a little reductive and gate-keepy. Maybe an advanced type system allowing for complex types to be expressed easily actually allows you to write simpler, more effective code. Curious if you have any specific examples though.
  - chamomeal 2y ago
    I think there’s a difference between ideal library code and ideal business logic code. The more you lean into crazy ass generics in your library, the simpler and more error-free the user can make their biz logic code. Really nicely typed libraries almost give you zero chances to fuck things up, it’s amazing. But then again most of your devs wont be able to understand all those generics, so you need to keep your biz logic types relatively simple.
- shepherdjerred 2y ago
  Adding static typing only shows you how bad your code already is

FractalHQ 2y ago

This isn’t true, is it? I’ve only ever heard that TypeScript has one of the most advanced type systems of any mainstream language.. but I don’t have enough experience with other languages to know how true that is.

shepherdjerred 2y ago

Typescript has one of the most advanced type systems of any of the common languages

deleted 2y ago

[deleted]

chamomeal 2y ago

Nawww I’d say something like python or php is “scratching the surface”. Typescript’s type system is phenomenal and pretty deep. Honestly I think it’s the most interesting one to work with, too. Which is not always a good thing, but it is fun. The only type systems I’ve seen that are similarly expressive are rust and Haskell. Even go doesn’t come anywhere close.