Hacker News new | ask | show | jobs
by tuetuopay 240 days ago
Sometimes it feels like that Go mistakes readability for comprehendability. Sure, I can read every single line of Go I've ever read. But can I comprehend the bigger picture? Can I understand why? Isn't the actual meat buried under piles of non-abstraction?

This is precisely the premise for their library: I don't have the mental context to fit all the boilerplate in, nor do I have the brainpower to sift through it.

Sure, assembly is readable: every line is one machine instruction. But that's way too many details. On the other hand, C++ templates are not enough details.
2 comments
imiric 240 days ago
> But can I comprehend the bigger picture? Can I understand why? Isn't the actual meat buried under piles of non-abstraction?

The way you approach this in Go (and I would argue in any other language) is by building small abstractions when and if it makes sense to do so. Not by introducing abstractions early, or in order to make a piece of code slightly easier to follow. A simple comment might help to explain tricky logic, but otherwise you shouldn't need explanations about core language features.

Abstractions are not free. They can be poorly written, leaky, abstract too much or too little, inflexible, increase overall complexity and thus cognitive load, impact performance, introduce bugs, etc.

So relying on them only when absolutely necessary is often the sensible choice.

Also, if possible, building your own bespoke abstraction is often preferable to using an external package. You can tailor it to your exact use case, without adding another dependency, which carries its own risks and problems.

This specific package seems designed to be syntax sugar over language features, which is not a good idea for future maintainers of the code that uses it. They would need to understand how this 3rd-party library works, even if the author claims it to be more readable, ergonomic, or what have you.

link
unscaled 240 days ago
I feel like Go's concept of readability is very Blub-oriented[1]. Can a Blub programmer read this line? Then it's readable. Sometimes Go fans would say that this code:

  var result := []string{}
  for i = 0; i < items.Length(); i++ {
    item := items.Get(i)
    if item < threshold {
      result = append(result, converToString(item))
    }
  }
return result

I more readable than this code:

  return items
    .filter { it < threshold }
    .map    { convertToString(it) }
The argument is that everybody understand what the loop does, it's just a stupid loop. Bring back an an Algol 68, Pascal or C programmer from the 70s and they all understand what a for loop is. But my second example requires you to learn about filter and map and closures and implicit parameters like 'it'.

Of course, once you do understand these very complicated concepts, the code above is far more readable: it clearly states WHAT the program does (filtering all values below the threshold and converting them to string) rather than HOW it does that (which nobody cares about). "readability" here is only counted from the narrow perspective of an imperative programmer who is not familiar with functional declarative data processing.

I feel the same about the "ro" examples in the OP. I don't particularly like that ro takes (mostly because Go forces its hand, I assume), like having to put everything in an explicit pipe, but I find the example far more readable than the pure Go example which combines loops, channels and WaitGroups. That's far worse than the loop example I gave in this reply, to be honest, and I really don't know why people say this example is readable. I guess you can optimize it a little, but I always found both channel and WaitGroups waitable, unreadable and error prone. They are only "readable" in narrow perverted sense that has somehow become prevalent in the Go community, where "readability" is redefined to mean: no closures, no immutable values, no generics, no type safety and certainly nothing that smells like FP.

[1] https://wiki.c2.com/?BlubParadox

link