golang-samber-lo

Call lo.Map with a transform function and lo.Filter with a predicate; both take the slice plus a callback receiving each element and its index. They return new slices without modifying the input, so assign the result: filtered := lo.Filter(users, func(u User, _ int) bool { return u.Active }).

lo is the immutable core returning new collections. lop runs CPU-bound transforms in parallel goroutines for large datasets. lom mutates slices in place to eliminate allocations. loi provides lazy iterators requiring Go 1.23+ that avoid intermediate allocations in chained pipelines.

Prefer stdlib slices.Contains and slices.Sort since Go 1.21, and slices.Collect(maps.Keys(m)) since Go 1.23, because they carry no dependency. Use lo only for operations the stdlib lacks, such as Map, Filter, Reduce, GroupBy, and predicate-based queries like ContainsBy.

No, lop is designed for CPU-bound parallelism, not I/O-bound work. For concurrent HTTP calls use errgroup with context cancellation instead, since lop lacks context support and spawns goroutine-per-element overhead that provides no benefit for network waits.

The core lo, lop, and lom packages require Go 1.18+, so they work with Go 1.20. However, the lo/it lazy iterator package requires Go 1.23+ because it uses range-over-func, and the experimental SIMD package requires Go 1.25+ on amd64.

lo is immutable by default: every core function allocates and returns a new collection rather than modifying its input. If you discard the return value, the original slice is unchanged. Use lom.Filter when you explicitly need in-place mutation and accept losing the original data.