I think we, as a profession, have a tendency to focus on what's "easy" (syntax and constructs we're already familiar with) to the exclusion of other, potentially more important factors. I am and have been guilty of this myself, so I'm not claiming any sort of sainthood, just making an observation.
Often people pick on the use of single-letter variable names as "unreadable." This is mostly a matter of keeping the code light on the page, as they put it. If you're dealing with a package centered around Foo, especially methods on same, it's customary to just abbreviate it to f. That clashes with a lot of people's instincts even though, once you get used to it, it works well.
"Once you get used to it" is key -- this is true of any language with substantially new or different syntax/semantics from what a programmer is used to. All else being equal, familiarity ought to be orthogonal to merit; the mere presence of a learning curve ought not be a deal-breaker.
Anyway, Go is one of the most readable languages I've ever seen, given that it is not a scripting language. Among other things, type inference and literals make the code very clean, to the point where you can in short order read the standard library code and expect to understand it.
I think the issue with single-letter variables goes deeper than it just being unreadable (although its that too for someone that isn't "used to it").
For example there are issues with scope (what happens when I need a second or third "f" variable" and maintainability too (6 months from now I have to remember if "f" stands for "foo" or "file").
Generally, I try not to use single letter variable names in any scope that doesn't fit into a single screen in my editor. That way, I don't need to remember what "f" means, it's right there in front of me. And I shouldn't have too many variables in that scope, so conflicts aren't all that important; if I really do, I just start using multi-letter names again.
This is a good heuristic. For me, single letter variables are almost always iterators in places where space is at a premium (i.e. one line list comprehensions in python). If I'm breaking a loop out over multiple lines (which is almost always the case), I prefer a longer, more informative variable name.
You can look at the method signature that accepts or returns f. At worst case, you need an IDE with hover popups, or to open the functions doc page or source code.
The biggest gripe I have with single-letter variable names is that they invariably require mental translation to their full names before anyone can understand how they're being used. Even for those who wrote the code in question.
I think we, as a profession, have a tendency to focus on what's "easy" (syntax and constructs we're already familiar with) to the exclusion of other, potentially more important factors. I am and have been guilty of this myself, so I'm not claiming any sort of sainthood, just making an observation.
Often people pick on the use of single-letter variable names as "unreadable." This is mostly a matter of keeping the code light on the page, as they put it. If you're dealing with a package centered around Foo, especially methods on same, it's customary to just abbreviate it to f. That clashes with a lot of people's instincts even though, once you get used to it, it works well.
"Once you get used to it" is key -- this is true of any language with substantially new or different syntax/semantics from what a programmer is used to. All else being equal, familiarity ought to be orthogonal to merit; the mere presence of a learning curve ought not be a deal-breaker.
Anyway, Go is one of the most readable languages I've ever seen, given that it is not a scripting language. Among other things, type inference and literals make the code very clean, to the point where you can in short order read the standard library code and expect to understand it.