This was my impression coming to Go as well (from Python and PHP) but since then I've changed my mind and somehow find it easier to unpack a small for loop than a HOF with a lambda function argument.

When you introduce lambdas/closures/HOF you immediately have to think about scope rules, non-local references etc.

Meanwhile, a foor loop is just a for loop.

Until you spawn a goroutine from a loop and suddenly you have to think about scope rules, nonlocal references, etc...

(It doesn't bother me, just noting the same complexities do come up pretty often).

BTW this is actually being addressed, specifically the for loop now essentially captures by value instead of by reference. I believe no real working programs were affected by the change, except for maybe fixing bugs in them.

Proof: https://go.dev/blog/loopvar-preview

Map and filter name what they’re doing, while loops look too much alike.

I haven’t checked whether any Go compiler does list fusion between producers and consumers (to avoid leaving a slice in the heap after reading it just once).

This wasn't feasable without generics, and now with generics they're already adding some convenience functions to the stdlib, like in the slices package.

For map, reduce etc it's not in the stdlib yet, but you can use https://pkg.go.dev/github.com/samber/lo

Higher order functions are not easy to grasp for beginners, but once you do, they simplify reasoning about the code a lot.

Go is targeted at system programming, which is a domain in which you need pretty advanced developers. But the language feature seems to favor use by absolute programming beginners. It's a trade-off which seems somehow inverted.

Go was designed to be easy to learn for inexperienced developers.

Is it actually intended for systems programming? Its main (and intended) use seems to be a faster and better at concurrency and parallelism alternative to Python, Ruby etc.

Rob Pike was after C++ programmers initially, turns out that naturally the language isn't appealing to that community.

> Although we expected C++ programmers to see Go as an alternative, instead most Go programmers come from languages like Python and Ruby. Very few come from C++.

https://commandcenter.blogspot.com/2012/06/less-is-exponenti...

I messed around with Go early on but haven’t touched it since (I mostly do numerical work these days) but this tracks with what I expected from the language. It felt reactionary to the C++ monster. It felt like the early goal was to make the language as simple as possible, like C, and add quality of life improvements that don’t increase complexity, especially for parallelization with the go routines.

There’s a talk by Rob Pike where he mentions that it would have been difficult for code using map, filter, etc. to be as fast as the equivalent code using a for loop without a sufficiently smart compiler.

So I think the motivation was more implementation simplicity . But if they had tried to add zero cost iterators it probably would have leaked complexity into the language too.

Generic iterators are included in go 1.22 behind an experimental feature flag and will most likely be in 1.23 by default. Once that's done you will probably see some support functions like map and filter in the standard library. Russ Cox already has a proposal for an experimental package xiter that includes Map/Filter/Reduce/Zip etc.

I can appreciate Go's design philosophy of simplicity and emphasizing fast tooling + one way to do things.

But as someone who has done a ton of functional programming, to me it is just too conservative of a language. There actually has been progress in the PL space the past 50 years, and I personally prefer a language that includes them.

I think OCaml strikes a better balance between power and simplicity, it is probably the closest to Go in the functional programming space (and is also a systems language). It has a blazingly fast compiler, it's easy to understand how it executes things, compiles down to a single binary, the tooling is good. Very similar advantages to Go.

Go is not a functional language.

The most common complaint against Go seems to be "My favourite programming language has X, why doesn't Go has X??"

There are things I would like to see in Go (e.g. real enums and the ? operator for error handling), but I DONT WANT Go to become a copy of C# or Haskell...