At the time of this writing, here's the guidance from the Go team on how to name receivers:
The name of a method's receiver should be a reflection of its identity; often a one or two letter abbreviation of its type suffices (such as "c" or "cl" for "Client"). Don't use generic names such as "me", "this" or "self", identifiers typical of object-oriented languages that gives the method a special meaning. In Go, the receiver of a method is just another parameter and therefore, should be named accordingly. The name need not be as descriptive as that of a method argument, as its role is obvious and serves no documentary purpose. It can be very short as it will appear on almost every line of every method of the type; familiarity admits brevity. Be consistent, too: if you call the receiver "c" in one method, don't call it "cl" in another.
And now, for something completely different...
Consistent with past writings, I'm about to go against the grain.
The name of a method's receiver should be a reflection of its identity;
Not necessarily. The name of a method's receiver is orthogonal to its type.
...often a one or two letter abbreviation of its type suffices (such as "c" or "cl" for "Client")
Wrong. Truncating words is a barrier to readability. Also, to my last point about orthogonality, a one or two letter abbreviation based on the current name of its type creates a direct coupling which discourages future type name rename operations. See bufio.Writer for a concrete example of a type whose receiver was probably once an abbreviation of its type (maybe BufferedWriter?), but is no longer.
Don't use generic names such as "me", "this" or "self", identifiers typical of object-oriented languages that gives the method a special meaning
Actually, please do use generic names such as "this" or "self" because it's actually helpful if the receiver is consistently indicated as such within a method definition.
In Go, the receiver of a method is just another parameter and therefore, should be named accordingly
While the receiver is technically another parameter, it's name should clearly identify it as the receiver as a reminder of what type is the focal point of the method in question. If your methods for a given type are short (as they should be), you will be reminded of the type of the receivers in each method several times per screen of code. You'll never be far from the definition of the method.
The name need not be as descriptive as that of a method argument, as its role is obvious and serves no documentary purpose
Correct, and using 'self' or 'this' is sufficiently descriptive.
It can be very short as it will appear on almost every line of every method of the type; familiarity admits brevity
That last statement about familiarity and brevity really rubs me wrong. Brevity is a barrier to familiarity for new readers, but 'me' is short and clearly identifies the receiver as such.
Be consistent, too: if you call the receiver "c" in one method, don't call it "cl" in another.
Yes, be consistent, so use 'me', 'this', and 'self' consistently across entire projects. Don't use one or two letter abbreviations for variable names except in the case of very tight loop counters.