3 ms·

I liked the article, and I'm sympathetic to the overall point... > The kind of hoops I have to jump through to get types "just right" in a web app versus a lib

I liked the article, and I'm sympathetic to the overall point... > The kind of hoops I have to jump through to get types "just right" in a web app versus a library is dramatically different. It's rare in a web app for me to need constructs like conditional types, type operators, and overloads. As a library developer, they are heavily used. These constructs are highly dynamic and embed logic into your types. This leads into my next frustration with typescript which is debugging. I would have like to see some examples of "conditional types, type operators, and overloads" in action, and an argument for why these constructs are so much more prevalent in library code than in application code. I don't have a counter-argument, and I don't have any reason to doubt the author's insight, but after reading the article I don't feel like I have an increased understanding of the problem-space.

usrusr 4y ago
It's been ages since my last dive into the js galaxy, but from my outside perspective I read that as "the usual mess that we like to do to provide awesome backwards compatibility when introducing wildly changed API generations is very difficult to sneak past the typechecker". Not sure that I read it correctly, but it would certainly fit "conditional types, type operators, and overloads". Why are they more prevalent in library code: to make changes non-breaking (or breaking, but fixable with minor tweaks). Of course types can also be a solution to this problem, by promoting consequences of incompatible change from runtime to compile time, but that only holds if you can assume that all calling code is type checked.
mirekrusin 4y ago
Because in application you're on consumer side, you have concrete types you're working with, in library on the other hand you're often providing generic code with parametric polymorphism, some constraints, you'll use type mapping etc. Before judging it as "terrible" it would be good if author has more constructive criticism - if typescript is "terrible" what is not "terrible", haskell? What are specific things that can be changed to make it simpler? What if typescript is actually very good but the underlying type theory is just inherently complex? You also have to appreciate what kind of value it brings to library users - and imho, in many cases, the value is so high that the whole discussion is a nobrainer. In my opinion - if you want to use typescript, you need to learn it, especially when writing libraries. It doesn't make sense to want to use something and not want to learn it at the same time.

usrusr 4y ago

It's been ages since my last dive into the js galaxy, but from my outside perspective I read that as "the usual mess that we like to do to provide awesome backwards compatibility when introducing wildly changed API generations is very difficult to sneak past the typechecker". Not sure that I read it correctly, but it would certainly fit "conditional types, type operators, and overloads". Why are they more prevalent in library code: to make changes non-breaking (or breaking, but fixable with minor tweaks). Of course types can also be a solution to this problem, by promoting consequences of incompatible change from runtime to compile time, but that only holds if you can assume that all calling code is type checked.

mirekrusin 4y ago

Because in application you're on consumer side, you have concrete types you're working with, in library on the other hand you're often providing generic code with parametric polymorphism, some constraints, you'll use type mapping etc. Before judging it as "terrible" it would be good if author has more constructive criticism - if typescript is "terrible" what is not "terrible", haskell? What are specific things that can be changed to make it simpler? What if typescript is actually very good but the underlying type theory is just inherently complex? You also have to appreciate what kind of value it brings to library users - and imho, in many cases, the value is so high that the whole discussion is a nobrainer. In my opinion - if you want to use typescript, you need to learn it, especially when writing libraries. It doesn't make sense to want to use something and not want to learn it at the same time.