[iopq]

That's the answer for everything in the Go community. More ad-hoc tools to replace the type system. Have concurrency bugs? Use a tool that detects some types of data races. Have problems with errors? Have a tool that detects not checking for errors.

How is approaching every single problem with a different tool more simple than using the type system as the one tool for static checking? The Go ecosystem is creating a ad-hoc, informally-specified, bug-ridden, slow implementation of half of the type checker of Haskell.

[pacala]

The jury is out on whether, for large time frames and for large communities, having a centralized type system is better than having a decentralized set of independent tools.

I'm not very excited by GHC's model of language extensions, https://downloads.haskell.org/~ghc/6.12.2/docs/html/users_gu.... And in spite of the large number of Haskell extensions, there are still pragmatic niches that aren't covered, see for example Rust's encoding of memory management in the type system.

In a sense, GHC contains a ad-hoc, informally-specified, bug-ridden, slow implementation of half of the type checker of Coq ;) Which is to say that there are many flavors of sophisticated type systems, and it's not clear which flavor is most conducive for writing good software on a tight time budget.