Did you even read the second half of the post? The author's answer to your concerns is testing. He suggests relying on tests rather than on strict type system that forces you to design everything upfront.
Personally, I can see arguments for both approaches - stricter types or more tests.
Tests check the operation for a single value of the, potentially infinite, input space.
Types check the operation for many, and can be made for all possible input values.
The difference is:
None of these boxes contain bicycles because:
* With tests: we checked 3 of them and found no bicycles
* With types: all the boxes are too small to contain bicycles.
Yes I did, which doesn’t mean I buy the point at all. Testing clearly falls into “manually noticing the mistake”.
I've written python and C++. For small simply problems python is nice, and writing tests for everything is easy enough. However as the program gets larger python becomes painful to work with. Writing code is the easy part, the hard part is when you want to refactor existing code to add a new feature - if you don't have the right tests (integration tests, not unit tests - though these terms are poorly defined) you will miss some code path that then won't work when it finally is run - unless you have a good type system which catches most of the errors that can happen when refactoring.
C++ is a notoriously difficult language to write in. However when the problem demands tens of millions of lines of code I'll take it over python because of the type system. There are other languages with good type systems that are reportedly better.