Types don't just guard against catastrophically stupid errors like Cars instead of Flowers. You can use them proactively to tag and refine data, excising a considerable deal of logic from your code.

If you are dealing with priority lanes, all of the methods could be written to only accept Carpool types, even if a Carpool struct has the exact same fields as a Car. Then you only need to parse a Car to a Carpool once and never worry about validating the passenger count after that.

Static typing only seems like a verbose straightjacket in the context of verbose languages like Java and Go. In reality it can help you write way less code. I don't expect the world to switch to Haskell, but I am excited by the direction TS is heading. I think "parse don't validate" will become common wisdom eventually.

Also, the crash cases you mention could be avoided elegantly with Option types.

Yes this! I've worked so much with static typing and I always think this when people talk about all the bugs that it prevents. I do from time to time wonder why stuff isn't working while I'm building it in a dynamic language just to find that I have a typo somewhere and I might get annoyed but then I think about all the types I would have to write and maintain and I'm happy again. I'm convinced that most of the time there is not enough ROI to justify the added complexity and mental burden of adding something that does nothing for the problem you're trying to solve.

> ... since nowadays we all do TDD (right? ;). I hope so! ).

Everything in moderation. TDD is good, but I've watched people write extensive tests before writing a line of code to test, and it often ends badly -- not too badly, they usually just needed to rewrite the tests once they figured out that they had the wrong API (oops, at least one example was a case for DOD, because the API was perfectly obvious from that lens) but sometimes that can trigger multiple refactors along the way. I've seen the same thing happen with documentation-first. I've seen top-down problems and bottom-up problems and code that ships before tests or docs were ever written/validated. In my not-even-remotely humble opinion, people need to be familiar with all the design patterns, and figure out which is best at project inception.