[unscaled]

Lack of expressiveness does not guarantee improved readability. It can only prevent abuse of language expressiveness that could harm reability.

But expressiveness, when used correctly, can also improve reability. Which is more readable?

  longNames := users.filter(x -> len(x.name) > 10)

  longNames := make([]User)
  for _, x := range users {
    if len(x.name) > 10 {
      longNames := append(longNames, x.name)
    }
  }

The only world in which the second example is more readable is one where developers never heard of filter, but have fully memorized (and are not confused by) all 3 variants of make(), the strange syntax of append (including all of its shared data pitfalls) and just got used to mentally parsing this behemoth pattern above as "filter".

This world is probably real in some corners of the wider world where Go is used, but it is not the only possible world, and I don't think it's a good one.

[harry8]

Both of those are equally simple to read as it is a very, very simple example. Simple examples are never the issue. The issue is when there are complex things involving edge cases and fiddly bits where there's a nasty hack in the middle of it that can't be removed easily or cleanly or both.

In theory there's no difference between theory and practice. In practice Go is a lot younger than Haskell, to take that as some kind of comparison, and there seem to be a lot more successful projects written in Go despite that. I like Haskell, I haven't even be bothered to learn Go yet on my own. But lets be sensible about readability. Simplicity almost always wins or at worst ties, as in the simple filter above.

Everyone writing serious Haskell tends to end up writing new additions to the standard library to make it work. Reading Haskell can be challenging on this basis. There absolutely is pyrotechnical showing off. I don't see this kind of issue at all in Go - for good or ill. I'd be astounded if Go is 5% of the fun of writing Haskell. I'd be more likely to choose Go than Haskell if I have a large project than needs to work in short-ish amount of time. (And when isn't the amount of time short-ish?)

[dcow]

Not to mention the item index, which is so often unused as in your example, as the first position in `for` loop bindings. Would it be so hard to have a `range_indexed` version that includes the index? Maybe I don't write enough Go code, but I also tend to think the first item conveys more importance which is why I often double take when I read Go for loops. "Wait why are they ignoring... oh yeah it's just the index".