More complicated functionality has moved to integrations/APIs in the past 8 years.

When you’re trying to ship an extensive application and building out features that few customers may ever use, types absolutely slow you down. When you’re integrating with a 3rd-party API, you have two differences:

1. relatively high confidence the API won’t change much, which makes implementing typed code lower risk and higher ROI

2. a slower feedback loop over the “reload the page” of rolling your own, so types catching issues earlier than heavy integration tests is much more valuable

I use untyped Ruby/Rails code for all of the CRUD, and golang AWS lambdas for anything integrating with SDKs/APIs. Best of both worlds, in my experience.

I think one size doesn’t fit all. Some engineers like static types & some don’t. People who want it will work on adding it. I don’t think same people who disliked earlier changed their mind.

Absolutely. “Anyone can write JavaScript” led to that crap. It also led to having modules that do things like determine if a number is even or odd and get exploited.

Earlier versions of typescript definitely were far more restrictive than recent ones- changes / updates to unions, enums, generics and inference, etc.

There are still some areas where it falls flat, but it is far more usable than before (very pleasant, in fact).

Been using flint stones for over a decade, we still don't need match sticks.

Same here.

Having tried TypeScript and Kotlin, TypeScript is like a half-assed type system that gives you cryptic error messages in compile time and mindfuck stack traces in run time.

Using assert(value, message?) function ends up being more useful and ergonomic.