So, instead of waiting a minute for the typescript compiler, you wait for the engineer to write tests.
Type safety is easy in a dynamic language. Stop mutating variables and stop mixing types. Suddenly that whole class of errors evaporates. No need to test things that are impossible.
And for those times you want some magic in your life, nothing is stopping you, no need for generics, just proceed with caution and test accordingly.
Firstly, they'd be written in the same language that you are coding in, not a weird, half baked type language, that adds visual noise to your code.
Secondly, they'd have much more power to define meaningful and useful behaviour rather than being restricted to talk about correct behaviour via types.
Thirdly, they'd run when you wanted the tests to run, and you could tier different tests to run at different times, so they aren't all slowing you down while you're doing fast iteration.
I used to like types, but then I realised that what matters is how quickly you see the bug. Seeing it in your code editor is brilliant, but if it's slower in time than hitting control S and seeing the actual app in the other pane auto reload, and fail or not, then it's worse.
These days I look on the idea that you know the exact types of all data your program will interact with at the time you write your code as the same sort of mistake that we made when we thought we understood the deep inheritance hierarchies of the real world.
I write a lot of Purescript and a lot of Clojure. Purescript, being basically a Haskell variant, is about closing down every last little part of the system into types. You _do_ pick up a lot of visual noise for this (like `liftEffect` ugh...). Whereas Clojure, is the polar opposite. It's about keeping the system open, using large chunks of data, and having functions take/change what they need and pass along everything else none-the-wiser to what's present.
Bouncing back and forth between these two worlds, I think I've begun to lean towards the opinion that I really only care about strict types at the boundaries of my program and certain very specific checkpoints along the way (generally, something like a module/namespace boundary).
Clojure has Spec, but it misses the mark in my opinion because it doesn't solve refactoring. It's not (currently) instrumented enough to help the me as a human make changes to the code without also just "bumping into the guard rails" to try and figure out what I broke along the way.
A middle ground orthogonal type system sounds really appealing to me. "Type coverage" is an idea I've been kicking around. Something like Spec in Clojure, but more symbiotic with the host code such that it can tell you things _about_ your code and help in refactoring, symbol resolution, etc..
That's a lot of words, but tl;dr I think I agree with you : )
Which, if we're doing TDD, involves no waiting at all, since it was already written before the implementation. Ideally anyway.
