Golang Samber Lo

intent

use samber/lo when you need declarative, type-safe functional transforms on collections in Go. the library eliminates manual for-loops for Map, Filter, Reduce, GroupBy, Chunk, Flatten, Find, Uniq, and 400+ other operations across slices, maps, strings, math, channels, and tuples. lo is immutable by default, zero-dependency, and composes cleanly. apply this skill when importing github.com/samber/lo in your codebase, adopting functional patterns over imperative loops, or deciding between lo (core), lop (parallel), lom (mutable), loi (lazy iterators for Go 1.23+), or lo/exp/simd (experimental). not for streaming or reactive pipelines over infinite event streams (see golang-samber-ro skill instead).

inputs

• Go runtime , 1.18+ for core lo, lop, lom; 1.23+ for loi (iterators); 1.25+ amd64-only for lo/exp/simd
• github.com/samber/lo , installed via go get github.com/samber/lo
• profiling data (optional) , output from go tool pprof -alloc_objects to confirm allocation bottlenecks before switching to lom or lop
• context7 docs , access to samber/lo API reference (pkg.go.dev, lo.samber.dev, or local go.mod with samber/lo pinned)
• codebase import path , verify github.com/samber/lo is reachable and version-pinned in go.mod (recommended: use semantic versioning, e.g., v1.57.0+)

procedure

1. choose the right package , determine which lo variant matches your use case.

   • input: profiling results, dataset size, Go version, mutation requirements.
   • steps: consult the package decision table (lo vs lop vs lom vs loi vs simd); verify Go version support; check if allocation or CPU is the measured bottleneck.
   • output: selected package name (e.g., lo, lop, lom, loi).

2. import and alias the package , add the import statement to your Go source file.

   • input: chosen package (e.g., github.com/samber/lo).
   • steps: add import "github.com/samber/lo" or import lo "github.com/samber/lo" at the top of the file; for parallel, use import lop "github.com/samber/lo/parallel"; for mutable, use import lom "github.com/samber/lo/mutable".
   • output: import statement added to file, no compile errors on go build.

3. replace manual loops with lo functions , identify iteration boilerplate (for-range, append, conditionals) and replace with declarative lo calls.

   • input: existing code with manual for-loops (e.g., building a new slice from filtered/mapped input).
   • steps: identify the transform pattern (Map, Filter, Reduce, GroupBy, etc.); write the lo equivalent using inline function literals; verify type correctness; run go build and go test.
   • output: replaced code compiles and produces identical output to the manual version.

4. handle errors with error variants , if the transform function can fail, use MapErr, FilterErr, ReduceErr, or similar error-aware variants.

   • input: a transform that returns (result, error) and should stop on first error.
   • steps: replace lo.Map with lo.MapErr; the function signature is func(T, int) (U, error); check the returned error before using results; do not ignore the error.
   • output: errors propagated cleanly, no silent failures.

5. compose functions for readability , chain multiple lo calls instead of nesting complex loops.

   • input: a multi-step transform (filter, then map, then group).
   • steps: write each step as a separate lo call; pass the output of one as input to the next; verify intermediate types match.
   • output: code is declarative, easy to read, and easy to test (each step can be unit-tested independently).

6. profile and optimize if needed , only switch to lom or lop after confirming a bottleneck.

   • input: production code using lo, benchmark results or profile data showing allocation or CPU as the issue.
   • steps: run go test -bench . -benchmem and go tool pprof to measure hot spots; if allocations dominate, switch to lom (in-place mutation); if CPU-bound work on 1000+ items, switch to lop (parallel); if many chained transforms on large data, use loi (lazy iterators) to avoid intermediate slices.
   • output: optimized code with measured improvement (e.g., reduced allocations, faster runtime).

7. verify no panics in production , audit all uses of lo.Must and lo.Try to ensure they only appear in tests or init functions.

   • input: codebase using lo.Must or lo.Try.
   • steps: grep for lo.Must, lo.Try in request handlers and production code paths; replace with error-returning variants in hot paths.
   • output: no lo.Must in request handlers, only in tests or init.

decision points

if you need stdlib coverage for a function, then prefer stdlib over lo (e.g., slices.Contains, slices.Sort since Go 1.21+, slices.Collect(maps.Keys(m)) since Go 1.23+), else use lo for Map, Filter, Reduce, GroupBy, Chunk, Flatten, Uniq, Find, and other transforms the stdlib does not offer.

if dataset size is small (< 100 items) and CPU usage is not measured as a bottleneck, then use core lo for simplicity, else if dataset is large (1000+ items) and CPU-bound work is confirmed by profiling, then switch to lop (parallel) to leverage goroutines, else if allocation pressure is measured and in-place mutation is acceptable, then switch to lom, else if many chained transforms on large data and Go 1.23+ is available, then use loi to avoid intermediate allocations.

if the transform function can return an error (e.g., HTTP request in Map), then use the error variant (MapErr, FilterErr, etc.) to stop on first error and propagate cleanly, else use the non-error variant.

if code is in a test, init function, or other non-critical path, then lo.Must is acceptable for brevity, else if code is in a request handler or production hot path, then always handle errors explicitly and never use lo.Must.

if using reactive or streaming patterns over infinite event streams, then prefer samber/ro (reactive extensions) over chaining lo calls, else use lo for bounded collections.

if numeric bulk operations require SIMD acceleration and Go 1.25+ amd64 is available, then benchmark lo/exp/simd after establishing a performance requirement, else use core lo.

if the transform is a one-liner (e.g., lo.Map(items, func(x T, _ int) U { return x.Field })), then inline the function literal, else if the logic is complex (multi-line, multiple transforms), then extract to a named function for readability.

output contract

• successful transformation , the returned slice/map is a new collection with the correct type, length, and element order matching the declared transform (no mutations to input unless explicitly using lom).
• error handling , if using an error variant (MapErr, FilterErr, etc.), the returned error is non-nil on first transform failure and the result collection is incomplete (halted early).
• no compile errors , go build succeeds with no type mismatches between input, function signature, and output.
• no panics in production , lo.Must never appears in request handlers or production code paths; only in tests or init.
• allocation efficiency , core lo allocates exactly one output collection (no intermediate buffers); lom avoids allocations by mutating in place; loi avoids intermediate slices in chained operations; lop may allocate goroutine overhead but reduces per-item computation cost on large datasets.

outcome signal

• code is more readable , replaced verbose for-loops with declarative lo calls; function intent is clear from the function name (Map, Filter, Reduce, GroupBy, etc.).
• tests pass , all existing tests pass after replacing manual loops with lo equivalents, confirming output correctness.
• no type errors , go build succeeds and go vet reports no issues.
• profiling confirms improvement (if optimizing) , after switching to lop or lom, go tool pprof shows reduced allocations, lower CPU time, or both compared to the previous version.
• error handling is explicit , error variants (MapErr, FilterErr) are used where the transform can fail, and all errors are checked before using results.

why samber/lo

Go's stdlib slices and maps packages (1.21+) cover roughly 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, zero interface boxing overhead.
• immutable by default , returns new collections, safe for concurrent reads, easier to reason about.
• composable , functions take and return slices/maps, 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 golang-samber-ro skill plus samber/ro package.

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 and 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,
)

group by

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)
})
if err != nil {
    return err
}

common mistakes

best practices

1. prefer stdlib when available , slices.Contains and slices.Sort (Go 1.21+) carry no dependency; maps.Keys is Go 1.23+ and returns an iterator, so use slices.Collect(maps.Keys(m)) when you need a slice. use lo for transforms the stdlib does not offer (Map, Filter, Reduce, GroupBy, Chunk, Flatten).
2. compose lo functions , chain lo.Filter to lo.Map to 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 plus manual error collection. error variants stop early and propagate cleanly.
5. use lo.Must only in tests and init , in production, handle errors explicitly.
6. watch for channel deadlock in lo.ChannelDispatcher , ensure all dispatcher output channels are drained concurrently to avoid blocking; use select with done channel or io.MultiCloser-like patterns.
7. be aware of lo.Debounce and lo.Throttle state , these functions maintain internal timers; do not assume they are stateless or safe to call concurrently without synchronization.

quick reference