samber/lo — Functional Utilities for Go

This skill is not exhaustive. Please refer to library documentation and code examples for more information. Context7 can help as a discoverability platform.

Why samber/lo

Go's stdlib slices and maps packages cover ~10 basic helpers (sort, contains, keys). Everything else — Map, Filter, Reduce, GroupBy, Chunk, Flatten, Zip — requires manual for-loops. lo fills this gap:

• Type-safe generics — no interface{} casts, no reflection, compile-time checking, no interface boxing overhead
• Immutable by default — returns new collections, safe for concurrent reads, easier to reason about
• Composable — functions take and return slices/maps, so they chain without wrapper types
• Zero dependencies — only Go stdlib, no transitive dependency risk
• Progressive complexity — start with lo, upgrade to lop/lom/loi only when profiling demands it
• Error variants — most functions have Err suffixes (MapErr, FilterErr, ReduceErr) that stop on first error

Installation

go get github.com/samber/lo

Choose the Right Package

Start with lo. Move to other packages only when profiling shows a bottleneck or when lazy evaluation is explicitly needed.

Key rules:

• lop is for CPU parallelism, not I/O concurrency — for I/O fan-out, use errgroup instead
• lom breaks immutability — only use when allocation pressure is measured, never assumed
• loi eliminates intermediate allocations in chains like Map → Filter → Take by evaluating lazily
• For reactive/streaming pipelines over infinite event streams, → see samber/cc-skills-golang@golang-samber-ro skill + samber/ro package

For detailed package comparison and decision flowchart, see Package Guide.

Core Patterns

Transform a slice

// ✓ lo — declarative, type-safe
names := lo.Map(users, func(u User, _ int) string {
    return u.Name
})

// ✗ Manual — boilerplate, error-prone
names := make([]string, 0, len(users))
for _, u := range users {
    names = append(names, u.Name)
}

Filter + Reduce

total := lo.Reduce(
    lo.Filter(orders, func(o Order, _ int) bool {
        return o.Status == "paid"
    }),
    func(sum float64, o Order, _ int) float64 {
        return sum + o.Amount
    },
    0,
)

GroupBy

byStatus := lo.GroupBy(tasks, func(t Task, _ int) string {
    return t.Status
})
// map[string][]Task{"open": [...], "closed": [...]}

Error variant — stop on first error

results, err := lo.MapErr(urls, func(url string, _ int) (Response, error) {
    return http.Get(url)
})

Common Mistakes

Best Practices

1. Prefer stdlib when available — slices.Contains, slices.Sort, maps.Keys carry no dependency. Use lo for transforms the stdlib doesn't offer (Map, Filter, Reduce, GroupBy, Chunk, Flatten)
2. Compose lo functions — chain lo.Filter → lo.Map → lo.GroupBy instead of writing nested loops. Each function is a building block
3. Profile before optimizing — switch from lo to lom/lop only after go tool pprof confirms allocation or CPU as the bottleneck
4. Use error variants — prefer lo.MapErr over lo.Map + manual error collection. Error variants stop early and propagate cleanly
5. Use lo.Must only in tests and init — in production, handle errors explicitly

Quick Reference

For the complete function catalog (300+ functions), see API Reference.

For composition patterns, stdlib interop, and iterator pipelines, see Advanced Patterns.

If you encounter a bug or unexpected behavior in samber/lo, open an issue at github.com/samber/lo/issues.

Cross-References

• → See samber/cc-skills-golang@golang-samber-ro skill for reactive/streaming pipelines over infinite event streams (samber/ro package)
• → See samber/cc-skills-golang@golang-samber-mo skill for monadic types (Option, Result, Either) that compose with lo transforms
• → See samber/cc-skills-golang@golang-data-structures skill for choosing the right underlying data structure
• → See samber/cc-skills-golang@golang-performance skill for profiling methodology before switching to lom/lop