Comment by lloydatkinson

Comment by lloydatkinson 5 hours ago

4 replies

TypeScript codebases I've seen generally seem to have the widest demonstration of skill gap versus other languages I use.

For example, I don't ever see anyone using `dynamic` or `object` in C#, but I will often see less skilled developers using `any` and `// @ts-ignore` in TypeScript at every possible opportunity even if it's making their development experience categorically worse.

For these developers, the `type` keyword is totally unknown. They don't know how to make a type, or what `Omit` is, or how to extend a type. Hell, they usually don't even know what a union is. Or generics.

I sometimes think that in trying to just be a superset of JavaScript, and it being constantly advertised as so, TypeScript does not/did not get taken seriously enough as a standalone language because it's far too simple to just slot sloppy JavaScript into TypeScript. TypeScript seems a lot better now of having a more sane tsconfig.json, but it still isn't strict enough by default.

This is a strong contrast with other languages that compile to JavaScript, like https://rescript-lang.org/ which has an example of pattern matching right there on the home page.

Which brings me onto another aspect I don't really like about TypeScript; it's constantly own-goaling itself because of it's "we don't add anything except syntax and types" philosophy. I don't think TypeScript will ever get pattern matching as a result, which is absurd, because it has unions.

ervine 4 hours ago

On the other hand, would we even be talking about it if it hadn't stuck to its goals?

fourthark 3 hours ago

It will get pattern matching when JS does. Not certain yet but in progress.

https://github.com/tc39/proposal-pattern-matching

  • ibejoeb 3 hours ago

    That proposal is really dragging though. And typescript needs as much work because that's where the real power is. We need discern thing like

        match (x) {
          "bob": ...,
          string: ...,
          () => Promise<void>: ...,
          () => Promise<string>: ...,
        }
    
    with exhaustiveness checking for it to be truly useful.
    • ameliaquining an hour ago

      Discriminating a function or promise based on return type is never going to work, because JavaScript is dynamically typed and TypeScript erases types at compile time, so there's no way to know at runtime what type a function or promise is going to return.