Unless they are loop counters, array indices, they never are descriptive/intuitive outside of a 5 line function. I write a lot of Go (understatement) and for all but the former, my min is three, rarely two letters. I also buck the "system" and use "this" in my receivers :)

Nothing is worse than seeing a "r" in the body of some function or as a struct member and not knowing if it is a reader, response, request so rather than using "r", I'll go with rdr, resp, req or this (were applicable). That is hardly verbose and our code is immensely more readable than something "idiomatic" like the Go standard library IMHO. I think this really should not be considered an issue of idiomaticness, if is was gofmt or go vet should care.

The short is if you like Go and not single letter var names, great use Go with longer variables names! I realize this is a religious issue so I can already feel the flames burning :)

I don't consider req a long variable name. What I'm trying to communicate is that req is better than request, and res better than response, since they communicate the same thing and are easier to read and write. When it makes sense, i.e. when it can't lead to confusion, the variables have one-letter names--oftentimes this is e.g. i, j for loop variables or n for a number, and so on. Also, it is very common for a method on a type Bar to bind the Bar to a variable b, i.e. func (b Bar) Foo() { ... }

This is how the entire Go stdlib is written, and how most packages are written.