// the find
ahmetb/go-linq
.NET LINQ capabilities in Go
go-linq ports .NET's LINQ query operators to Go — Where, Select, GroupBy, OrderBy, Join, and the rest. It targets Go developers who miss method-chaining collection pipelines and don't want to write the same map/filter loops by hand. The v4 release (October 2025) finally aligns with Go's native iterator protocol from the `iter` package.
The v4 migration to `iter.Seq[any]` is the right call — queries now compose with `for range` and standard Go tooling instead of fighting the language. Zero dependencies is genuine; the go.mod is essentially empty. Test coverage is thorough: every operator has its own `_test.go` file and there's a benchmark suite, so performance regressions are visible. The typed constructors (`FromSlice`, `FromMap`, `FromChannel`) avoid reflection overhead on the hot path while keeping the old `From` around for compatibility.
The `any`-based API is the core problem: without Go generics threading through the chain, you're either writing type assertions everywhere or paying a 5–10x reflection penalty for the `T`-suffix methods — the README admits this openly. Go 1.18 generics have been stable for four years; a properly generic rewrite would eliminate both downsides, but it hasn't happened. Lazy evaluation is real but the chain allocates a closure per operator, so for tight loops over large slices the overhead adds up in ways a plain `for` loop never would. The `GroupBy` return type is `Group` with an untyped `Group []any` field, which means you still need type assertions at the final step even when using `T` methods throughout — the type safety leaks at collection boundaries.