Well, it's Go, so you're going to have some runtime type errors. interface{} is way too common to avoid them completely (I had the order of arguments for two ConcurrentMaps wrong, for instance, and it blew up on reads -- found it almost instantly, but alas, at runtime). But it should be a much smaller number than python.
That's a very good thing for a language to have, indeed. But Go isn't the best thing to look into for productivity-via-the-type-system. What is (barring the purely functional languages' learning curve) is most any ML descendant; albeit Rust in particular if Go-like performance is desirable.
In addition to typeclasses, Rust has discriminated unions (ergo algebraic datatypes), structural pattern matching, first-class functions, local type inference, and an exclusive/nonexclusive dichotomy of references which serves as a useful proxy for mutability.
people who use python more aren't as happy about it, otherwise mypy wouldn't exist.
i use python more, can't recommend mypy enough, it's great for what it is. it has warts, but that's to be expected if you add an optional strict modern type system to 20 years of dynamic language.
A large part of why mypy exists is due to cargo-culting groupthink that leaves the 'static typing > dynamic typing' trope less challenged than it ought to be. Static typing is just not as useful as the glossy claims - and the boilerplate cruft incurs way more friction than typists like to admit.
mypy is great, I use it in 'public' api's, tricky parts where context alone is inadequate and where I previously fucked up - the latter usually is a signal that the flow or abstractions can be improved to the extent that I can remove the typing hints.
mypy helps me, it does not force me to throw a goat into the lava pit to appease the compiler.
mixing untyped libraries with typed basically makes the whole monolith behave as if it was untyped. Once they get the major libraries typed, python projects will become much more robust.
