I wrote Go code all the time, and I don't /hate/ it. But it would be a mistake to call Go's tooling "incredible". The race detector is /sometimes/ useful, but it doesn't do any "real" analysis (you have to be very close to the race window in order to trigger the race detector to complain, which is quite difficult for more obscure race conditions based on random variables). The Linux kernel (which as we all know is written in C) has lots of far more sophisticated detection of lock contention and other such things at runtime. But I think you need static analysis if you actually want to figure out where races might exist in your code.

Vendoring makes life hard for people who have to package software. Traditionally, you have build dependencies which are the libraries your software uses. In Go (because nobody follows semantic versioning when changing the API of their libraries, and the Go tooling doesn't allow you to specify versions of a package -- WHICH IS ACTUALLY CRITICAL) you just have to dump all of your dependencies into the same place as your source and be done with it. I don't see why people see vendoring as the solution. Defining version dependencies in your source is the solution if you want to go with "our source code defines what we need to pull in". Don't get me started on the static linking issue. Oh, and build dependencies have to be packaged as source code (packaging them in their compiled form is quite hard to do).