Go is not an easy language (2021) (opens in new tab)

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.

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.

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.

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.

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

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.

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...

As someone dabbling in Go, still a n00b really, but experienced in many other languages, I find this too, why's there stuff that's just standard in e:g Python, yet missing in Go? Apparently a thought-out, deliberate decision by the language designers. But then, since many people feel this way about Go, I'm mystified that 3rd-party libraries haven't evolved to cover "missing features" of Go. One would think, someone will scratch an itch, release it, then everyone uses that. Seems to have happened in other languages. Weirdly, there are indeed 3rd-party libs for Go that do more sophisticated things, web frameworks etc. Its almost as though 3rd-party devs don't dare touch the lower level stuff cos that's "against the spirit" of Go, but do make reusable libs for higher level things. Well, this comment may reflect my naiveté / ignorance of the language. Maybe someone else will clarify this? ;)

Yeah. Tons of people claim to be able to pick up languages within a week, or a month. I’m convinced it takes at least a year to get out of beginner status, even for simple languages. I’m including things like knowing the ecosystem and popular libraries (http server and clients, ORMs, testing frameworks, …) in that.

It's really the other way around : it's simple, which makes it not easy to use.

The way Arch Linux defines simplicity is "Arch Linux defines simplicity as without unnecessary additions or modifications."[0]

Go is simple because it only really has what you NEED. People complain about wanting this and that feature, but they don't really NEED it, it would just make writing code easier.

Personally I love that because if there's a billion ways to do something, I waste all my time trying to figure out the best way to do it instead of working on the original problem, but I can see why people who are not like me would prefer more features.

* https://wiki.archlinux.org/title/Arch_Linux#Simplicity

"Back to front"?

There are many, many situations where delete_at is a completely reasonable operation. It may be O(n) but it is a blazing fast O(n) as it is just a memmove. For example if you are writing a TODO app and you want to delete a task it is likely a very acceptable solution. You would need millions of tasks before you couldn't remove it withing a few milliseconds. Most other solutions even though they have better time complexity would be slower in practice. (But benchmarks would be needed to verify this).

I would say that the biggest concern with delete_at is if you are using it inside another O(n) loop, then it becomes O(n^2) which does scale up fast enough to become a performance issue.

There is nothing wrong with O(n). It can be faster than O(1) depending on the size of n and what you're doing (small arrays are usually faster than hashmaps for example).

Big-O just tells you how something scales. It doesn't really tell you how fast something is.