That's really misguided. Go is not a functional programming language, it's an imperative programming language. You're going against its design. You're like these people who write Java and "class hierarchies" in Go, just from a different angle. If you like FP you should use Haskell instead of Go. I say this as a fan of Go.

I don't think things are that simple. I like functional programming, but I also like good tooling, having a rich ecosystem, job opportunities, backward compatibility, simplicity, people to talk to. There are lots of things that can weigh on your choice of language. Semi-functional Go might be the sweet spot for some people, and absolute hell for others.

A map() is much easier to read and understand than create slice, for loop, return slice. Coding is about reading code.

An unfused map-filter chain is a performance disaster waiting to happen.

In Go or in general? I've written code for companies with 50k+ concurrent writing users, I've bootstrapped and scaled and sold a startup on Scala (which has bad performance b/c of immutable lists but with usual list <100 elements no problem) and I haven't seen this in other languages, but I'm not experienced enough in Go and haven't deployed something major in Go yet.

Other popular languages will fuse either via JIT or via some kind of linear types.

You should preen less in your comments.

I think it's always easier to understand a point of view if you know where someone is coming from and the context.

"An unfused map-filter chain is a performance disaster waiting to happen."

Could you share your experience with that perfromance disaster here?

> Go is still plenty fast with it

It is not. Your program might still hit acceptable speed targets, but you're taking enormous absolute perf hits for extremely questionable gains.

https://news.ycombinator.com/item?id=30696210

As long as it's only you who has to maintain the code and not another Go programmer ...

The Go developers I know understand map() and filter() perfectly well.

What a condescending comment in response of someone trying to help

s/trying to help/trying to be right/g

The linked comment was about an implementation of partition with the specific problem of allocating too many slices in the opinion of the author. It was not about lo in general, did not help or shared any performance numbers E.g. for a size of a usual lists of <50 elements with filter() or the use case of three chunks, that people use when writing web applications (which I do, I don't write a database in Go - something the author could have found out my asking instead of assuming).

There's no ergonomic loss to using the faster approach. It's just cargo culting patterns from other languages even though they're less accessible and less performant in Go.

The problem with your comments isn't the context for what you're doing, it's the "40y, scaled and sold" bullshit. That's bragging, not an argument nor context. Or as a senior colleague used to remind me, "shipping is easy if you're willing to ship shit." I'm not here to discuss shipping.

"shipping is easy if you're willing to ship shit."

What a nasty comment.