A lot of it is cargo-culting based on comments of the go-team members and applying the advice of go team members as a blanket as opposed to applying it more sur

A lot of it is cargo-culting based on comments of the go-team members and applying the advice of go team members as a blanket as opposed to applying it more surgically in the context of your application. For example I used to get a lot of pushback from the go community when using an assertion library, for those not familiar, go's testing library doesn't have support for asserts so you end up writing a lot of code like if want != got { t.Fatalf(....) } this gets esp annoying as you deal with more complex objects. Many in the go community criticize using an assertion library to write simple assertions as in other languages for your tests, citing that the go team members are against casually bringing dependencies in your project. Not realizing the intent Go Team's "statement against dependencies" is a targeted word of caution urging people to think about the dependencies they bring into their project rather than a blanket attitude against dependencies. Almost certainly Go Team would not advise against bringing in a build time time dependency that is not even gonna be part of the binary you ship that will make your tests easier to write and error messages consistent.