7 ms·

> TypeScript is a wonderfully advanced language though it has an unfortunately steep learning curve An extremely steep one. The average multi-year TypeScript

> TypeScript is a wonderfully advanced language though it has an unfortunately steep learning curve An extremely steep one. The average multi-year TypeScript developer I meet can barely write a basic utility type, let alone has any general (non TypeScript related) notion of cardinality or sub typing. Hell, ask someone to write a signature for array flat, you'd be surprised how many would fail. Too many really stop at the very basics. And even though I consider myself okay at TypeScript, the gap with the more skilled of my colleagues is still impressively huge. I think there's a dual problem, on one side type-level programming isn't taken seriously by the average dev, and is generally not nurtured. On the other hand, the amount of ideas, theory, and even worse implementation details of the TypeScript compiler are far from negligible. Oh, and it really doesn't help that TypeScript is insanely verbose, this can easily balloon when your signatures have multiple type dependencies (think composing functions that can have different outputs and different failures).

undeveloper 1y ago
these are things most developers don't know how to do in most language's type systems. I think only rust with its focus on functional roots has seen similar focus on utilizing its type system to its fullest extent.
lloydatkinson 1y ago
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/ 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 1y ago
  On the other hand, would we even be talking about it if it hadn't stuck to its goals?
- fourthark 1y ago
  It will get pattern matching when JS does. Not certain yet but in progress. https://github.com/tc39/proposal-pattern-matching https://github.com/tc39/proposal-pattern-matching
  - ibejoeb 1y 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 1y 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.
      - ibejoeb 1y ago
        It'll work because that's what typescript does, and that's why it needs to be implemented there, also. That's my point. And as far as runtime goes, well, that's not what typescript does. It's a typical compile-time static type system. Typescript aside, even a javascript-level first-class pattern expression is still extremely useful. I really hope it gets in there soon.
- locknitpicker 1y ago
  > 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. I think you're confusing things that aren't even comparable. The primary reason TypeScript developers use the likes of `any` is because a) TypeScript focuses on adding support for static type checking on a language that does not support it instead of actually defining the underlying types, b) TypeScript developers mostly focus on onboarding and integrating TypeScript onto projects and components that don't support it, b) TypeScript developers are paid to deliver working projects, not vague and arbitrary type correctness goals. Hence TypeScript developers tend to use `any` in third party components, add user-defined type guards to introduce typing in critical areas, and iterate over type definitions when time allows.
ForHackernews 1y ago
Honestly I just use TypeScript to prevent `1 + [] == "1"` and check that functions are called with arguments. I don't care about type theory at all and the whole thing strikes me as programmers larping (poorly) as mathematicians.
- epolanski 1y ago
  I couldn't care less about mathematics, but I do care about making impossible state impossible and types documenting the domain. If you type some state as: isLoading: boolean result: Foo hasError: boolean errorMessage: string | null then you're creating a giant mess of a soup where the state of your program could have a result, be loading and an error at the same time. If you could recognise that the state of your program is a sum of possible states (loading | success | error), and not their product as the type above you could highly simplify your code, add more invariants and reduce the number of bugs. And that is a very simple and basic example, you can go *much* further, as in encoding that some type isn't merely a number through branded types, but a special type of number, be it a positive number between 2 and 200 or, being $ or celsius and avoiding again and entire class of bugs by treating everybody just as an integer or float.
  - what 1y ago
    >encoding that a number is between 2 and 200 What’s the point of this level of autism when you still have to add run time checks?
    - kennywinker 1y ago
      For a function setVelocity() that can accept 1..<200. You call it with numbers that you enter directly and types tell you something that would otherwise be a comment on the function, or you do runtime checks elsewhere, and the type becomes proof that you checked them before handing it into the function. Btw, using “autism” to mean “pedantry” leaves a bit of a bad taste in my mouth. Maybe you could reconsider using it that way in the future.
samdoesnothing 1y ago
I have mixed feelings about Typescript, I hate reading code with heavy TS annotations because JS formatters are designed to keep line widths short, so you end up with a confusing mess of line breaks. Pure JS is also just more readable. Also you can so easily go overboard with TS and design all sorts of crazy types and abstractions based on those types that become a net negative in your codebase. However it does feel really damn nice to have it catch errors and give you great autocomplete and refactoring tooling.
- locknitpicker 1y ago
  > I have mixed feelings about Typescript, I hate reading code with heavy TS annotations because JS formatters are designed to keep line widths short, so you end up with a confusing mess of line breaks. Pure JS is also just more readable. That's not a TypeScript issue, it's a code quality issue and a skill issue. Anyone can put together an unintelligible mess in any language.
afavour 1y ago
> Too many really stop at the very basics. I don’t think that means it has a steep learning curve. It just means the basics suffice for a ton of TypeScript deployments. Which I personally don’t see as the end of the world.
- vosper 1y ago
  Yes, to me this is a biggest feature of Typescript: A little goes a long way, while the advanced features make really cool things possible. I tend to think of there being two kinds of Typescript - Application Typescript (aka The Basics, `type`, `interface`, `Record`, unions etc...) and Library Typescript which is the stuff that eg Zod or Prisma does to give the Application Typescript users awesome features. While I aspire to Library TS levels of skill, I am really only a bit past App TS myself. On that note I've been meaning to the the Type-Level Typescript course [0]. Has anyone taken it? https://type-level-typescript.com/ https://type-level-typescript.com/
pcthrowaway 1y ago
> Hell, ask someone to write a signature for array flat, you'd be surprised how many would fail. To be clear, an array flat type: type FlatArr<Arg extends unknown[]> = Arg extends [infer First, ...(infer Rest)] ? First extends unknown[] ? [...First, ...FlatArr<Rest>] : [First, ...FlatArr<Rest>] : []; is far from basic Typescript. The average Typescript dev likely doesn't need to understand recursive conditional types. It's a level of typescript one typically only needs for library development. Not only have I never been expected to write something like this for actual work, I'm not sure it's been useful when I have, since most of my colleagues consider something like this nerd sniping and avoid touching/using such utilities, even with documentation.
- wk_end 1y ago
  If I saw that in a PR I would push very hard to reject; something like that is a maintenance burden that probably isn’t worth the cost, and I’ve been the most hardcore about types and TypeScript of anyone of any team I’ve been on in the past decade or so. Now, that said, I probably would want to be friends with that dev. Unless they had an AI generate it, in which case the sin is doubled.
  - deleted 1y ago
    [deleted]
  - 8note 1y ago
    looking back at them is also real hard to debug. you dont get a particularly nice error message, and a comment or a test would tell better than the type what the thing should be looking like
  - probabletrain 1y ago
    I think there’s a difference between what’s expected/acceptable for library code vs application code. Types like this might be hard to understand, but they create very pleasant APIs for library consumers. I’ve generally found it very rare that I’ve felt the need to reach for more complex types like this in application code, however. RXJS’s pipe function has a pretty complex type for its signature, but as a user of the library it ‘just works’ in exactly the type-safe way I’d expect, without me having to understand the complexity of the type.
madeofpalk 1y ago
> Too many really stop at the very basics. As someone who knows slightly more than the basics, and enough to know about the advanced stuff that I don't know about, this is the correct place to stop. I would much rather restructure my javascript than do typescript gymnastics to fit it into the type system.
- IceDane 1y ago
  [flagged]
  - ervine 1y ago
    You can restructure your JS to avoid some crazy verbose TS though, sometimes. I think that's the point they were making. Why be so hostile?
- IshKebab 1y ago
  I agree. The advanced stuff mostly exists in order to allow writing type annotations for JavaScript libraries that have APIs that are very dynamic. If you're purely writing Typescript then you mostly don't need it.
imiric 1y ago
You're right, but that begs the question: does a type system really require such complexity? I'm aware that type theory is a field in and of itself, with a lot of history and breadth, but do developers really need deep levels of type flexibility for a language to be useful and for the compiler to be helpful? I think TypeScript encourages "overtyping" to the detriment of legibility and comprehension, even though it is technically gradually typed. Because it is so advanced and Turing complete itself, a lot of brain cycles and discussion is spent on implementing and understanding type definitions. And you're definitely right that it being verbose also doesn't help. So it's always a bittersweet experience using it. On one hand it's great that we have mostly moved on from dynamically typed JavaScript, but on the other, I wish we had settled on a saner preprocessor / compiler / type system.
- rjh29 1y ago
  The idea is to make libraries preserve as much type information as possible, as a principle. Once type information is erased it can't be restored. For regular application code you don't need to use those features.
  - imiric 1y ago
    But regular application code also contains libraries. Type information is useful even if you're the only user of those APIs. My point was more related to the level of expressiveness required of a type system in order to allow a programmer to produce reliable code without getting in their way. I think TypeScript leans more towards cumbersome than useful. For example, I'm more familiar with Go's type system, which is on the other side of that scale. It is certainly much less expressive and powerful than TypeScript, and I have found it frustrating and limiting in many ways, but in most day-to-day scenarios it's reasonably adequate. Are Go programs inherently worse off than TypeScript programs? Does a Go programmer have a worse experience overall? I would say: no.
    - rjh29 1y ago
      They're completely different languages, Javascript is dynamically typed, not sure how useful such a comparison is. TS's type system evolved out of a desire to encode the type relations of JS functions, often native ones, which are very dynamic and polymorphic. When writing application code you can keep things simple, but trying to represent all the ways types can change for the native libraries is harder.
stefan_ 1y ago
This is the bell curve meme, and you are in the middle telling us "template metaprogramming in C++ is amazing".
dzonga 1y ago
typescript is largely a result of solving a non-existent problem. Yeah JS is finicky & has foot-guns, however they're ways around those foot guns that don't involve typescript. Rich Hickey in 10 Years of Clojure & Maybe Not then the Value of Values - lays this out - though not meant at typescript but static types in general. the thing most people don't have proper Javascript fundamentals. Function signatures: JSDoc works Most types - use Maps | Arrays if a value doesn't exist in a map we can ignore it. There's also the safe navigation operator. Instead of mutable objects - there's ways around this too. Negating types again.
- fenomas 1y ago
  Uh, among several other issues with this, what use are JSDoc comments for typing, without typescript to check them?
- locknitpicker 1y ago
  > typescript is largely a result of solving a non-existent problem. Claiming that lack of static type checking is a non-existent problem is quite a bold claim. Care to offer some details to substantiate your claim?
monkpit 1y ago
> ask someone to write a signature for array flat Out of curiosity - what do you think is a satisfactory answer here? My answer would vary wildly based upon more details, but at the most basic all I can think you could guarantee is Array<unknown> => Array<unknown>?
- epolanski 1y ago
  In an interview I'd be happy just seeing some reasoning. IRL I'd be happy with someone at least searching for a definition and trying to learn from it. I've asked this question multiple times as implementing array flatten used to be our go to ice breaker question, and many devs had no issues reasoning and finding an okay type definition.
mook 1y ago
It's also terribly documented. As an example, I don't think `satisfies` is in the docs outside of release notes. There's lots more stuff like that, which makes using it kind of frustrating.
- lelandfe 1y ago
  Preach. It’s astonishing how much necessary documentation lives as unchanging footnotes on TS releases. https://www.google.com/search?q=site%3Ahttps%3A%2F%2Fwww.typescriptlang.org+%22satisfies%22 https://www.google.com/search?q=site%3Ahttps%3A%2F%2Fwww.typ...
cynicalcoder 1y ago
>And even though I consider myself okay at TypeScript, the gap with the more skilled of my colleagues is still impressively huge. Maybe they're smart, but the even smarter dev would avoid unnecessary complexity in the first place.
paulddraper 1y ago
Not steep so much as deep. There’s a lot you can do in TypeScript. But you don’t have to do it. And TS existed successfully a long time without those features.
mohas 1y ago
to our defense, we want to build stuff not become ts wizards. also I've worked with libraries with heavy heavy typing that it was a nightmare if you wanted to use their lib in any other way than what they have imagined.
knallfrosch 1y ago
Typescript types often devolve into keyof typeof[number] ? uppercase (myNum) On the other hand, there isn't much Omit, readonly, mutable in existing code bases, so devs have nowhere to learn but documentation. Then the ground shifts again and –what should be basic stuff – enums are banned, because erasableSyntaxOnly makes life so much easier.
Exoristos 1y ago
"There basics," well understood and judiciously applied, is where the bulk of TypeScript's value lies.
- locknitpicker 1y ago
  > "There basics," well understood and judiciously applied, is where the bulk of TypeScript's value lies. Yes, precisely. OP is also completely oblivious to the fact that TypeScript is designed to help developers gradually onboard legacy JavaScript projects and components, which definitely don't require arcane and convoluted type definitions to add value.
locknitpicker 1y ago
> The average multi-year TypeScript developer I meet can barely write a basic utility type, let alone has any general (non TypeScript related) notion of cardinality or sub typing. Hell, ask someone to write a signature for array flat, you'd be surprised how many would fail. I think you're both exaggerating your blanket accusations of incompetence and confusing learning curve with mastering extremely niche techniques akin to language gotchas.
baxuz 1y ago
Being a JS/TS one-trick pony all my career, how does it compare to other languages? I don't really see much difference, except if comparing with some C++ shenanigans.
SkyPuncher 1y ago
I stopped doing anything advance because I realized nobody actually wanted to do all of the advanced stuff. None of the NPM community does anything more than the basics. Frankly, I prefer it that way. A lot of the advance stuff doesn’t actually enable any new functionality. It only shortens the code paths for implementing.

undeveloper 1y ago

these are things most developers don't know how to do in most language's type systems. I think only rust with its focus on functional roots has seen similar focus on utilizing its type system to its fullest extent.

lloydatkinson 1y ago

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/ 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 1y ago
On the other hand, would we even be talking about it if it hadn't stuck to its goals?
fourthark 1y ago
It will get pattern matching when JS does. Not certain yet but in progress. https://github.com/tc39/proposal-pattern-matching https://github.com/tc39/proposal-pattern-matching
- ibejoeb 1y 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 1y 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.
    - ibejoeb 1y ago
      It'll work because that's what typescript does, and that's why it needs to be implemented there, also. That's my point. And as far as runtime goes, well, that's not what typescript does. It's a typical compile-time static type system. Typescript aside, even a javascript-level first-class pattern expression is still extremely useful. I really hope it gets in there soon.
locknitpicker 1y ago
> 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. I think you're confusing things that aren't even comparable. The primary reason TypeScript developers use the likes of `any` is because a) TypeScript focuses on adding support for static type checking on a language that does not support it instead of actually defining the underlying types, b) TypeScript developers mostly focus on onboarding and integrating TypeScript onto projects and components that don't support it, b) TypeScript developers are paid to deliver working projects, not vague and arbitrary type correctness goals. Hence TypeScript developers tend to use `any` in third party components, add user-defined type guards to introduce typing in critical areas, and iterate over type definitions when time allows.

ForHackernews 1y ago

Honestly I just use TypeScript to prevent `1 + [] == "1"` and check that functions are called with arguments. I don't care about type theory at all and the whole thing strikes me as programmers larping (poorly) as mathematicians.

epolanski 1y ago
I couldn't care less about mathematics, but I do care about making impossible state impossible and types documenting the domain. If you type some state as: isLoading: boolean result: Foo hasError: boolean errorMessage: string | null then you're creating a giant mess of a soup where the state of your program could have a result, be loading and an error at the same time. If you could recognise that the state of your program is a sum of possible states (loading | success | error), and not their product as the type above you could highly simplify your code, add more invariants and reduce the number of bugs. And that is a very simple and basic example, you can go *much* further, as in encoding that some type isn't merely a number through branded types, but a special type of number, be it a positive number between 2 and 200 or, being $ or celsius and avoiding again and entire class of bugs by treating everybody just as an integer or float.
- what 1y ago
  >encoding that a number is between 2 and 200 What’s the point of this level of autism when you still have to add run time checks?
  - kennywinker 1y ago
    For a function setVelocity() that can accept 1..<200. You call it with numbers that you enter directly and types tell you something that would otherwise be a comment on the function, or you do runtime checks elsewhere, and the type becomes proof that you checked them before handing it into the function. Btw, using “autism” to mean “pedantry” leaves a bit of a bad taste in my mouth. Maybe you could reconsider using it that way in the future.

samdoesnothing 1y ago

I have mixed feelings about Typescript, I hate reading code with heavy TS annotations because JS formatters are designed to keep line widths short, so you end up with a confusing mess of line breaks. Pure JS is also just more readable. Also you can so easily go overboard with TS and design all sorts of crazy types and abstractions based on those types that become a net negative in your codebase. However it does feel really damn nice to have it catch errors and give you great autocomplete and refactoring tooling.

locknitpicker 1y ago
> I have mixed feelings about Typescript, I hate reading code with heavy TS annotations because JS formatters are designed to keep line widths short, so you end up with a confusing mess of line breaks. Pure JS is also just more readable. That's not a TypeScript issue, it's a code quality issue and a skill issue. Anyone can put together an unintelligible mess in any language.

afavour 1y ago

> Too many really stop at the very basics. I don’t think that means it has a steep learning curve. It just means the basics suffice for a ton of TypeScript deployments. Which I personally don’t see as the end of the world.

vosper 1y ago
Yes, to me this is a biggest feature of Typescript: A little goes a long way, while the advanced features make really cool things possible. I tend to think of there being two kinds of Typescript - Application Typescript (aka The Basics, `type`, `interface`, `Record`, unions etc...) and Library Typescript which is the stuff that eg Zod or Prisma does to give the Application Typescript users awesome features. While I aspire to Library TS levels of skill, I am really only a bit past App TS myself. On that note I've been meaning to the the Type-Level Typescript course [0]. Has anyone taken it? https://type-level-typescript.com/ https://type-level-typescript.com/

pcthrowaway 1y ago

> Hell, ask someone to write a signature for array flat, you'd be surprised how many would fail. To be clear, an array flat type: type FlatArr<Arg extends unknown[]> = Arg extends [infer First, ...(infer Rest)] ? First extends unknown[] ? [...First, ...FlatArr<Rest>] : [First, ...FlatArr<Rest>] : []; is far from basic Typescript. The average Typescript dev likely doesn't need to understand recursive conditional types. It's a level of typescript one typically only needs for library development. Not only have I never been expected to write something like this for actual work, I'm not sure it's been useful when I have, since most of my colleagues consider something like this nerd sniping and avoid touching/using such utilities, even with documentation.

wk_end 1y ago
If I saw that in a PR I would push very hard to reject; something like that is a maintenance burden that probably isn’t worth the cost, and I’ve been the most hardcore about types and TypeScript of anyone of any team I’ve been on in the past decade or so. Now, that said, I probably would want to be friends with that dev. Unless they had an AI generate it, in which case the sin is doubled.
- deleted 1y ago
  [deleted]
- 8note 1y ago
  looking back at them is also real hard to debug. you dont get a particularly nice error message, and a comment or a test would tell better than the type what the thing should be looking like
- probabletrain 1y ago
  I think there’s a difference between what’s expected/acceptable for library code vs application code. Types like this might be hard to understand, but they create very pleasant APIs for library consumers. I’ve generally found it very rare that I’ve felt the need to reach for more complex types like this in application code, however. RXJS’s pipe function has a pretty complex type for its signature, but as a user of the library it ‘just works’ in exactly the type-safe way I’d expect, without me having to understand the complexity of the type.

madeofpalk 1y ago

> Too many really stop at the very basics. As someone who knows slightly more than the basics, and enough to know about the advanced stuff that I don't know about, this is the correct place to stop. I would much rather restructure my javascript than do typescript gymnastics to fit it into the type system.

IceDane 1y ago
[flagged]
- ervine 1y ago
  You can restructure your JS to avoid some crazy verbose TS though, sometimes. I think that's the point they were making. Why be so hostile?
IshKebab 1y ago
I agree. The advanced stuff mostly exists in order to allow writing type annotations for JavaScript libraries that have APIs that are very dynamic. If you're purely writing Typescript then you mostly don't need it.

imiric 1y ago

You're right, but that begs the question: does a type system really require such complexity? I'm aware that type theory is a field in and of itself, with a lot of history and breadth, but do developers really need deep levels of type flexibility for a language to be useful and for the compiler to be helpful? I think TypeScript encourages "overtyping" to the detriment of legibility and comprehension, even though it is technically gradually typed. Because it is so advanced and Turing complete itself, a lot of brain cycles and discussion is spent on implementing and understanding type definitions. And you're definitely right that it being verbose also doesn't help. So it's always a bittersweet experience using it. On one hand it's great that we have mostly moved on from dynamically typed JavaScript, but on the other, I wish we had settled on a saner preprocessor / compiler / type system.

rjh29 1y ago
The idea is to make libraries preserve as much type information as possible, as a principle. Once type information is erased it can't be restored. For regular application code you don't need to use those features.
- imiric 1y ago
  But regular application code also contains libraries. Type information is useful even if you're the only user of those APIs. My point was more related to the level of expressiveness required of a type system in order to allow a programmer to produce reliable code without getting in their way. I think TypeScript leans more towards cumbersome than useful. For example, I'm more familiar with Go's type system, which is on the other side of that scale. It is certainly much less expressive and powerful than TypeScript, and I have found it frustrating and limiting in many ways, but in most day-to-day scenarios it's reasonably adequate. Are Go programs inherently worse off than TypeScript programs? Does a Go programmer have a worse experience overall? I would say: no.
  - rjh29 1y ago
    They're completely different languages, Javascript is dynamically typed, not sure how useful such a comparison is. TS's type system evolved out of a desire to encode the type relations of JS functions, often native ones, which are very dynamic and polymorphic. When writing application code you can keep things simple, but trying to represent all the ways types can change for the native libraries is harder.

stefan_ 1y ago

This is the bell curve meme, and you are in the middle telling us "template metaprogramming in C++ is amazing".

dzonga 1y ago

typescript is largely a result of solving a non-existent problem. Yeah JS is finicky & has foot-guns, however they're ways around those foot guns that don't involve typescript. Rich Hickey in 10 Years of Clojure & Maybe Not then the Value of Values - lays this out - though not meant at typescript but static types in general. the thing most people don't have proper Javascript fundamentals. Function signatures: JSDoc works Most types - use Maps | Arrays if a value doesn't exist in a map we can ignore it. There's also the safe navigation operator. Instead of mutable objects - there's ways around this too. Negating types again.

fenomas 1y ago
Uh, among several other issues with this, what use are JSDoc comments for typing, without typescript to check them?
locknitpicker 1y ago
> typescript is largely a result of solving a non-existent problem. Claiming that lack of static type checking is a non-existent problem is quite a bold claim. Care to offer some details to substantiate your claim?

monkpit 1y ago

> ask someone to write a signature for array flat Out of curiosity - what do you think is a satisfactory answer here? My answer would vary wildly based upon more details, but at the most basic all I can think you could guarantee is Array<unknown> => Array<unknown>?

epolanski 1y ago
In an interview I'd be happy just seeing some reasoning. IRL I'd be happy with someone at least searching for a definition and trying to learn from it. I've asked this question multiple times as implementing array flatten used to be our go to ice breaker question, and many devs had no issues reasoning and finding an okay type definition.

mook 1y ago

It's also terribly documented. As an example, I don't think `satisfies` is in the docs outside of release notes. There's lots more stuff like that, which makes using it kind of frustrating.

lelandfe 1y ago
Preach. It’s astonishing how much necessary documentation lives as unchanging footnotes on TS releases. https://www.google.com/search?q=site%3Ahttps%3A%2F%2Fwww.typescriptlang.org+%22satisfies%22 https://www.google.com/search?q=site%3Ahttps%3A%2F%2Fwww.typ...

cynicalcoder 1y ago

>And even though I consider myself okay at TypeScript, the gap with the more skilled of my colleagues is still impressively huge. Maybe they're smart, but the even smarter dev would avoid unnecessary complexity in the first place.

paulddraper 1y ago

Not steep so much as deep. There’s a lot you can do in TypeScript. But you don’t have to do it. And TS existed successfully a long time without those features.

mohas 1y ago

to our defense, we want to build stuff not become ts wizards. also I've worked with libraries with heavy heavy typing that it was a nightmare if you wanted to use their lib in any other way than what they have imagined.

knallfrosch 1y ago

Typescript types often devolve into keyof typeof[number] ? uppercase (myNum) On the other hand, there isn't much Omit, readonly, mutable in existing code bases, so devs have nowhere to learn but documentation. Then the ground shifts again and –what should be basic stuff – enums are banned, because erasableSyntaxOnly makes life so much easier.

Exoristos 1y ago

"There basics," well understood and judiciously applied, is where the bulk of TypeScript's value lies.

locknitpicker 1y ago
> "There basics," well understood and judiciously applied, is where the bulk of TypeScript's value lies. Yes, precisely. OP is also completely oblivious to the fact that TypeScript is designed to help developers gradually onboard legacy JavaScript projects and components, which definitely don't require arcane and convoluted type definitions to add value.

locknitpicker 1y ago

> The average multi-year TypeScript developer I meet can barely write a basic utility type, let alone has any general (non TypeScript related) notion of cardinality or sub typing. Hell, ask someone to write a signature for array flat, you'd be surprised how many would fail. I think you're both exaggerating your blanket accusations of incompetence and confusing learning curve with mastering extremely niche techniques akin to language gotchas.

baxuz 1y ago

Being a JS/TS one-trick pony all my career, how does it compare to other languages? I don't really see much difference, except if comparing with some C++ shenanigans.

SkyPuncher 1y ago

I stopped doing anything advance because I realized nobody actually wanted to do all of the advanced stuff. None of the NPM community does anything more than the basics. Frankly, I prefer it that way. A lot of the advance stuff doesn’t actually enable any new functionality. It only shortens the code paths for implementing.