Diminishing returns of static typing
Static typing prevents bugs in code to the degree that the programmer can correctly encode the desired behavior of the program into the type system. Relatively little behavior can be encoded in inexpressive type systems, so there&#x27;s a lot of room for bugs that have nothing to do with types. A lot more behavior (e.g. the sorts of invariants mentioned in agentultra&#x27;s top level comment) can be encoded in a more expressive type system, but you then have the challenge of encoding it &#x2F;correctly&#x2F;. A lot of that kind of thinking is the same as the kind of thinking you&#x27;d have to do writing in a dynamic language, but you get more assurances when your type system gives you feedback about whether you&#x27;re thinking about the problem right.<p>For my money, I work in a primarily dynamic language and I already have a set of practices that usually prevent relatively simple type mismatches so I very rarely see bugs slip into production that involve type mismatches that would be caught by a Go-level type system, and just that level of type information would add a lot of overhead to my code.<p>But if I were already using types, a more expressive system could probably catch a lot of invariance issues. So I feel like the sweet spot graph is more bimodal for me: the initial cost of switching to a basic static type system wouldn&#x27;t buy me a lot in terms of effort-to-caught-bugs-ratio, but there&#x27;s a kind of longer term payout that might make it worth it as the type system becomes more expressive.