This is probably one of the areas where Zig shines. I'm mostly a Gopher but reading Zig is just as easy while ensuring that no allocations are hidden

Same, I work in Go most of the time in performance and memory sensitive areas and the lack of usable abstractions grates so hard. I’m increasingly fed up of long hand everywhere and the bug volume and frequency it inherently produces particularly under change. I was worried this would be the outcome of the iterator proposal and am not surprised at all to find that yes, it is in practice. I was similarly disappointed with rand/v2 where I provided feedback thah the interface in the middle of it had been seldom used and could have been eradicated and the choice was to preserve that part of the API because the compiler should in the future eradicate these costs. I see no actual plan for how that will be done though, and I’m skeptical it will happen in practice. I’ll finish with the comment that will lead to comment downvoting, but I derive tons of value for resource constrained work from rusts lazy iterator design combined with the aggressively optimizing compiler folding nice low cost of maintenance abstraction here into tight sometimes even vectorized or unrolled loops - it makes work I do demonstrably easier.

This is usually the case with C#'s equivalent as well. Enumerables and LINQ are nice options to concisely express logic, but you won't see them in hot paths.

Sounds pretty interesting. If you were to write up how you tested this, I’d definitely read it.

Since you asked, I’ll call you crazy.

This sort of “chaining” syntax is pretty standard in many languages (Java, JS, Elixir, etc). Especially for streams/iterators/lists. You can have pretty well named and flat logic too. I think it’s just poorly written demo code. To me, this “functional” style of chaining is great. It highlights intent when reading the chain (you read “filter” as a step instead of a for loop with a conditional inside). It’s also really easy to recompose or reorder, and the code-review diffs are super easy to reason about when that happens.

I don’t think it really generates anything conventionally called “horrors” either - you can still use named functions and everything you love, this just makes it easier to use. It may encourage more well-written code too.

Imagine a simple example - get all files in some directory, filter out non-json files, perform some name-manipulation (map) function, and then return a new list. The “old” way would require a series of for loops that make and fill slices passed to each. You then wrap that whole thing in a new method called “GetRenamedJsonFiles(path string) []File”.

With the iterator chaining, you can still wrap it in a named method, but now you can replace the repeated for loops and intermediary slices with: “return GetFiles(path).Filter(isJsonFunc).Map(updateFileNameFunc).Collect()”. It’s probably easier to read, easier to change up later if requirements change, and easier to validate intent when reviewing, etc. It even encourages smaller, dedicated, easy to update or share methods - it encourages named methods for the intermediary steps (getFiles, isJson, updateName).

When Go eventually lets all this horrible syntax sugar into the standard library, we will meet again in the Zig community.

Even JS doesn't really use functional styles that much. In fact, the whole reason for functional styles is the decomposability: any language with easy function chaining like `x |> f |> g |> h` will also have an easy extraction of any part of the chain (say, `x |> fg |> h where fg = f . g`). It is not a good idea to use chaining when the language supports no such feature, as it would be much harder to work with such chains then.

You're right, this functional style 'clever' programming is exactly what Go discourages (or did discourage... historically...) This is the exactly the kind of code I don't want to see. I want to see clear, easy to read, obvious functions that do exactly what they say on the tin.

It is a sad fact that Go is becoming more and more like JavaScript (and deviating from C).

.Net seems to handle it pretty well with LINQ?

https://medium.com/@sanjanasw99/an-in-depth-guide-to-linq-in...

Might be written in a hurry and maybe the author was thinking that not allocating new Iterator, which is in fact wrapper around iter.Seq, will produce less heap garbage. But I guess it's the same amount of garbage, because the size of Iterator is the same as iter.Seq which is allocated anyway, it's just different type of the object being discarded

This flagged for me right away too. I would be badly surprised if a Map-style chained method mutated the memory of the receiver.

No, Go programmers would write

    a := []int{1, 2, 3, 4}
    out := []int{}

    for idx := range a {
        val := a[len(a)-idx-1]
        if mappedVal := Map(val); mappedVal % 2 == 0 {
            out = append(out, mappedVal)
            fmt.Println(mappedVal)
        }
    }

They might indeed. Or

  a := []int{1,2,3,4}
  it       := slices.All(a)
  itRev    := slices.Reverse(it)
  itMap    := slices.Map(it)
  itFilter := slices.Filter(it, func(i int) bool { return i % 2 == 0 })
  slices.ForEach(it, func(i int) { fmt.Println(i) })

> I don't judge the Go enjoyers, but I prefer writing TypeScript to Go which says it all.

The functional style is fine for simple filter/map algorithms, but once you get into zipping multiple iterators together, classic for-loops are often easier.

My company's hiring coding task had this "trap", at one point you needed to write an algorithm to merge consecutive "empty" cells in a data structure that is used to represent a simple table. This is dead easy with a regular for-loop, but writing it in a "functional" style could easily become extremely hairy and/or have O(N^2) complexity.

> it = slices.Map(it)

There is no such function as "slices.Map()".

https://pkg.go.dev/slices@go1.23.2

Nit - I think you've missed the `func` argument in the `slices.Map` line.

(But - yes, bravo, correct, you're right and you should say it)

You can actually (almost) make it work, you just need to add an extra type parameter to keep Go's silly limitations happy [0]:

  strs := []string{"abc", "defgh", "klmnopqrst"}
  ints := From[string, int](strs).
           Map(func(a string) int { return len(a) }).
           Filter(func(a int) bool { return a >= 4 })
  Iterator[int, float32](ints).
           Map(func(a int) float32 { return float32(a) }).
           Each(func(a float32) { fmt.Printf("%v\n", a) })
  //prints 5, then 10

Note that the original implementation in the article modifies the collections in place, in which case this issue doesn't come up at all: you can't put strings in an array of ints. My implementation creates copies of these collections so that the concept of mapping to a new type actually makes sense.

[0] https://go.dev/play/p/ggWrokAk7nS

I never understood why that limitation exist.

Can someone explain the reason for this?

It's not interesting. Boring people did this a million times, the result is always the same: just use for loops.

> Tips for lazy developers > I cannot recommend it, but in case you are too lazy for repeating lo. everywhere, you can import the entire library into the namespace.

    import (
        . "github.com/samber/lo"
    )

Back when the Go team announced generics, I had a go (pun intended) at it: https://github.com/gtramontina/go-extlib -- might resurrect it one day. `lo` is pretty comprehensive though.

Here's one: https://github.com/szmcdull/glinq It doesn't do function chaining though.

Its really not. For example, a map function tells you that there will be the exact number of outputs as inputs. A for loop doesn't have any guarantees. You have to read each line inside the loop to understand what its doing. In practice, having to be so explicit causes many more issues. I've never experienced as many mishandled errors on java projects as I have in Go.

That eliminates one of the main reasons to use this approach. Function chaining as most people write is awful for performance because it involves creating a separate array for each step in the chain. Given that most programs are actually more memory-blocked than CPU blocked, this is a bad tradeoff. Composing Go iterators, and composing iterators in general, is preferable because it doesn't have to create all the intermediate arrays. A bad reverse wrecks that back up.

Still, you need the option, and while reverse is one of the more common iterators, it's still usually avoidable if you need to. But if at all possible I'd suggest a "reverse" type-specialized to slices, and as necessary and possible, type-specialized to whatever other types you are using to actually crawl a value "backwards" rather than collecting a full iterator into a slice.

(Then again, I'm not a fan of this approach in imperative languages in general, due to the generalized difficulty in refactoring code written in this style and the fact that observationally, people just don't refactor it once written and it affords a style rife with repetition. One of the most important considerations about code is how easily it can be refactored. In Haskell, this approach is excellent, precisely because it refactors very, very well in Haskell. In imperative languages, it tends not to, thus, serving as another example of why you can't just blindly bring over nice things from one language into another without verifying they haven't become sour in the process.)

Why reverse the slice at all? Collect the input into a slice, then return an iterator that navigates the slice in backward order.

What this sort of thing lacks is any ability to optimize. For example, let's say the operation is Reverse().Take(20). There's no reason for the reverser to keep more than 20 elements in its buffer. But to express that, you have to make sure the iterator can be introspected and then rewritten to merge the operators and maybe unroll some of the loops to get better cache locality. This is what Haskell can achieve via Stream Fusion, which is pretty neat. But not so viable in Go.

According to https://pkg.go.dev/iter#hdr-Single_Use_Iterators , most iterators are expected to be reusable, but some are single use. A function returning a single-use iterator is expected to document that with a comment.

So the Reverse implementation in this article wouldn't work with single-use iterators. The iter package isn't clear whether a function that requires a multi-use iterator needs to be documented as such.

It always bugs me when I see that pattern in JavaScript, because each `map`, etc. call is an array allocation. Yeah, yeah, I know that the VM's memory allocators are likely optimized for fast allocation, but that doesn't make the allocation completely free.

But not because you can't easily chain functions. That's just a deficiency in the language design.

I looked at the code and it was giving me a headache, been messing around with Go for a decade, i do not like this

Nice rewrite for 1.23. Btw, just sent you a PR for a typo in the readme.

I just use play.go.dev

Life without REPLs.

You often end up with a lot of extraneous variables with no useful names if you do that. A lot of the time the intermediate results in a pipeline are almost meaningless.

I get that, i still dont like to write f5(f4(f3(f2(f1())))) instead of writing f1().f2().f3().f4().f5()

Yes. The following is a lot more concise:

    a = [1, 2, 3, 4]
    print([v*v for v in reversed(a) if v*v % 2 == 0])