The data scientists don't know they need it yet just like the JavaScript devs didn't think they n needed it.

I've already started seeing organic adoption of assertions.

2012: “static types restrict my beautiful code”

2019: “static types are amazing!”

I’m still salty about this shift. No one really goes back and admits, “maybe we were all wrong.”

IMO, the best explanation is the high influx of new, young devs results in ideological conformity in lieu of developed aesthetics. This also explains the unnatural amount of sway by so-called “thought leaders.”

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.

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).

Agree. Been using TS + Svelte on a side project and it has been very nice. I say this as someone who runs screaming from webdev usually.

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.

Been using JavaScript for over a decade, we still don't need TypeScript.

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

Been using a rube goldberg machine for over a decade, we still don't need a bigger rube goldberg machine.

Been using those little hand held gas lighters for over a decade, but sometimes I still 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.

I'll keep that in mind the next time I have to work around pandas automatically converting strings to floats. Or ints to floats (nope, no NaNs in either the inputs or the output). I'm sure it'll make me feel better about my data getting corrupted.

This is also why languages such as R, F#, and many others have emerged. I’m most familiar with F#, so I’ll use it as my example, but it is built on .Net just like C# and VB. That means you not only get access to all of the features they offer, but in a functional language that doesn’t enforce any of them on you.

Microsoft was clearly going for a best of both worlds approach - .Net if you need it, just your data if you don’t. I find it a pain in the ass, but all the data guys at work love it because they can mix and match with our existing code and still do their own thing.

> I think this is one of the reasons Python took off.

Python took off for data because the frameworks and libraries around it. Without IPython/Jupyter, dataframes, Scipy, it would have way less marketshare.