Not only that, but rarely am I supporting a library that I'm the sole developer on. Go takes away so much "individuality" of code. On most teams I've been on with Python and Java I can open up a file and immediate tell who wrote the library based on various style and other such. It's a lot harder with Go and that's a very good thing.
Yeah, at times the obsession of gophers with "idiomatic code" is annoying. But when you read someone else's code and it's idiomatic, you almost immediately have an intuitive sense how it works and can understand and modify it easily. Compared to Java OO code where you have to start chasing inheritance layers to find out where the piece of logic you're actually interested in resides...
Well, "idiomatic code" can often mean "for what you're trying to do, there is a way that works with the language better than any other way; do that". That is, it often means "working with the tool rather than fighting it". So, yeah, do it the idiomatic way unless another way is clearly better. (Idiomatic ought to win if evaluating "better" gives you a tie, because idiomatic will be more readable.)
I never really stopped to think about it until I read your comment, but I just realized the same applies to old Go code. As some of mine is approaching probably close to 2-3 years (and few things I haven't touched or looked at since!), and while it certainly could be rewritten to be better, it's interesting that Go's partial enforcement of idiomatic authorship appears to reduce the number of WTFs generated as a consequence of atrophy over time, to say nothing about how much less time is spent understanding the code.
Perhaps it's psychosomatic, but it sure seems easier to pick up something written in Go--long since forgotten--than it is in other languages. Then again, maybe it's also that Go taught me to substitute cleverness with terseness. The advantage here is that I've never been especially clever.
