[porridgeraisin]

> performance regression

What? Golang append()s also periodically grow the slice.

> Conditional logic

it's just a single if, really, the same thing is there in your filter()

> Multiple layers of nesting

2... You're talking it up like it's a pyramid of hell. For what it's worth, I've seen way way more nesting in usual FP-style code, especially with formatting tools doing

  func(
     args
  )

For longer elements of the function chain.

[stouset]

> What? Golang append()s also periodically grow the slice.

If you already know the size of the result (there are no filtering operations), the functional approach can trivially allocate the resulting array to already have the correct capacity. This happens with zero user intervention.

IIRC the Rust optimizer basically emits more or less optimal machine code (including SIMD) for most forms of iteration.

[porridgeraisin]

We are talking about making an array with unique elements here. You cannot know the correct capacity for that without overallocating.

If overallocating is indeed OK for your usecase, then you can do so yourself

  uniq := make([]MyObject, 0, len(my_objects))

[stouset]

I was talking more in the general case.

Yes, you can always just write more and more and more code to fix these things. Or you could just… not write more code and still get optimal performance.

[porridgeraisin]

> just... Not write more code

But the abstractions don't really adapt themselves to be performant in each usecase the way you imagine. I gave an example of c# distinct() above. Sure, they can. But do they? No. They only save anything at all for trivial usecases, where the imperative code is also obvious to parse.