I get the concurrency gains, esp with older versions of dynamic languages without native support for coroutines.
But the test coverage argument seems quite contorted. If you're accepting 92% coverage because the "return an error" lines are not worth testing (fair) then why is that harder to achieve in, say, Ruby or Python? Is the argument that your 92% coverage in Go is _effectively_ 100% because compiler?
I like and use both of them but if you're trying to argue that the testing problem in Python is the same as that of Go or Rust, that argument will fail.
Wasn't trying to make that case, but I can see how my comment could be read that way.
I was genuinely trying to understand what the parent comment meant. Specifically whether they were saying error control code is _the_ critical but hard to test part of a code base (which I don't think is typically true), or rather error control code is just an example among many of less frequently executed paths in code, which categorically is easier with a static type checker. I think they meant the latter and I don't disagree with that.
Additionally with a dynamic language where the codebase has less than a 100% test coverage I would find it very hard to refactor anything without sweating bullets. The compiler is giving you a free test suite.