Not me. I understand both code snippets, while being only passingly familiar with Ruby and not at all with Go. I can guess what the bits I'm unfamiliar with do.

Ruby's code is more declarative, and seems to use common functional idioms, which make it very easy to understand ("map", "sort", "reverse", "take" mean mostly the same in a wide variety of languages). In this case I do not need to know what the computer is doing "close to the metal", just as I do not need to know the physics of asking someone to fetch me a glass of water.

The Go snippet is also easy to understand, but it has more noise in the form of boilerplate. Here the name of the function is more helpful to understand what it's supposed to do. If the function was named GuessWhatThisDoes I'd figure what it does, but I'd have a harder time than with the Ruby version.

To be honest, both snippets can be understood, but unless I truly needed to understand the step-by-step performance implications, I'd rather read the more declarative Ruby snippet.

Well, it's not very meaningful to compare a good example of something with the bad example of something else (one lines are generally considered bad practice also for this reason).

If that line would be "optimized for readability", there would be at least one or two intermediate variables.

I would disagree and say the functional style is perfectly fine in its one-liner form. I'd even say it is preferable in many cases over using intermediate variables. Why? Because naming is hard and more often than not I see the intermediate variables named things like "sorted_histogram" or "sorted_reversed_histogram" which is hardly any clearer than "@histogram.sort_by{..}.reverse" while being much more verbose.

Intermediate variables in functional languages are largely used for memoization. Occasionally are they used for self-documentation but generally I see "people.map(&:full_name)" over "full_names = people.map{ |p| p.first_name + ' ' + p.last_name }".

For me the debugger tends to drive if I use one liners often or not. In C++ or C# it tends to be easier to step thru code if it's broken out. In Ruby I think it's probably less common to work with a source stepping debugger so it feels more natural to write nice functional one liners that do a lot.

Yet the author found the ruby code easier to understand. And I very often read praises about functional programming language's ability to chain functions in this fashion. I'm very often able to understand when two functions are chained the first time i read the line, but i very often have to read the line many times and decompose each parts above three.