Persona: You are a Go engineer who prefers declarative collection transforms over manual loops. You reach for lo to eliminate boilerplate, but you know when the stdlib is enough and when to upgrade to lop, lom, or loi.
samber/lo — Functional Utilities for Go
Lodash-inspired, generics-first utility library with 500+ type-safe helpers for slices, maps, strings, math, channels, tuples, and concurrency. Zero external dependencies. Immutable by default.
Official Resources:
This skill is not exhaustive — refer to library documentation and code examples for more information:
- For Go package docs, symbols, versions, importers, and known vulnerabilities, → See
samber/cc-skills-golang@golang-pkg-go-dev skill (godig), preferred over Context7 for Go package facts.
- To navigate this library's usage in your own code (definitions, call sites, diagnostics), → See
samber/cc-skills-golang@golang-gopls skill (gopls).
- Context7 remains a fallback for docs not indexed on pkg.go.dev.
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
| Package |
Import |
Alias |
Go version |
| Core (immutable) |
github.com/samber/lo |
lo |
1.18+ |
| Parallel |
github.com/samber/lo/parallel |
lop |
1.18+ |
| Mutable |
github.com/samber/lo/mutable |
lom |
1.18+ |
| Iterator |
github.com/samber/lo/it |
loi |
1.23+ |
| SIMD (experimental) |
github.com/samber/lo/exp/simd |
— |
1.25+ (amd64 only) |
Choose the Right Package
Start with lo. Move to other packages only when profiling shows a bottleneck or when lazy evaluation is explicitly needed.
| Package |
Use when |
Trade-off |
lo |
Default for all transforms |
Allocates new collections (safe, predictable) |
lop |
CPU-bound work on large datasets (1000+ items) |
Goroutine overhead; not for I/O or small slices |
lom |
Hot path confirmed by pprof -alloc_objects |
Mutates input — caller must understand side effects |
loi |
Large datasets with chained transforms (Go 1.23+) |
Lazy evaluation saves memory but adds iterator complexity |
simd |
Numeric bulk ops after benchmarking (experimental) |
Unstable API, may break between versions |
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
| Mistake |
Why it fails |
Fix |
Using lo.Contains when slices.Contains exists |
Unnecessary dependency for a stdlib-covered op |
Prefer slices.Contains/slices.Sort since Go 1.21+ and slices.Collect(maps.Keys(m)) since Go 1.23+ when a key slice is needed |
Using lop.Map on 10 items |
Goroutine creation overhead exceeds transform cost |
Use lo.Map — lop benefits start at ~1000+ items for CPU-bound work |
Assuming lo.Filter modifies the input |
lo is immutable by default — it returns a new slice |
Use lom.Filter if you explicitly need in-place mutation |
Using lo.Must in production code paths |
Must panics on error — fine in tests and init, dangerous in request handlers |
Use the non-Must variant and handle the error |
| Chaining many eager transforms on large data |
Each step allocates an intermediate slice |
Use loi (lazy iterators) to avoid intermediate allocations |
Best Practices
- 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 doesn't offer (Map, Filter, Reduce, GroupBy, Chunk, Flatten)
- Compose lo functions — chain
lo.Filter → lo.Map → lo.GroupBy instead of writing nested loops. Each function is a building block
- Profile before optimizing — switch from
lo to lom/lop only after go tool pprof confirms allocation or CPU as the bottleneck
- Use error variants — prefer
lo.MapErr over lo.Map + manual error collection. Error variants stop early and propagate cleanly
- Use
lo.Must only in tests and init — in production, handle errors explicitly
Quick Reference
| Function |
What it does |
lo.Map |
Transform each element |
lo.Filter / lo.Reject |
Keep / remove elements matching predicate |
lo.Reduce |
Fold elements into a single value |
lo.ForEach |
Side-effect iteration |
lo.GroupBy |
Group elements by key |
lo.Chunk |
Split into fixed-size batches |
lo.Flatten |
Flatten nested slices one level |
lo.Uniq / lo.UniqBy |
Remove duplicates |
lo.Find / lo.FindOrElse |
First match or default |
lo.Contains / lo.Every / lo.Some |
Membership tests |
lo.Keys / lo.Values |
Extract map keys or values |
lo.PickBy / lo.OmitBy |
Filter map entries |
lo.Zip2 / lo.Unzip2 |
Pair/unpair two slices |
lo.Range / lo.RangeFrom |
Generate number sequences |
lo.Ternary / lo.If |
Inline conditionals |
lo.ToPtr / lo.FromPtr |
Pointer helpers |
lo.Must / lo.Try |
Panic-on-error / recover-as-bool |
lo.Async / lo.Attempt |
Async execution / retry with backoff |
lo.Debounce / lo.Throttle |
Rate limiting |
lo.ChannelDispatcher |
Fan-out to multiple channels |
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
1---
2name: golang-samber-lo
3description: "Functional programming helpers for Golang using samber/lo — 500+ type-safe generic functions for slices, maps, channels, strings, math, tuples, and concurrency (Map, Filter, Reduce, GroupBy, Chunk, Flatten, Find, Uniq, etc.). Core immutable package (lo), concurrent variants (lo/parallel aka lop), in-place mutations (lo/mutable aka lom), lazy iterators (lo/it aka loi for Go 1.23+), and experimental SIMD (lo/exp/simd). Apply when using or adopting samber/lo, when the codebase imports github.com/samber/lo, or when implementing functional-style data transformations in Go. Not for streaming pipelines (→ See `samber/cc-skills-golang@golang-samber-ro` skill)."
4user-invocable: true
5license: MIT
6compatibility: Designed for Claude Code, Codex or similar harness, and for projects using Golang.
7metadata:
8 author: samber
9 version: "1.2.2"
10 openclaw:
11 emoji: "🧰"
12 homepage: https://github.com/samber/cc-skills-golang
13 requires:
14 bins:
15 - go
16 install: []
17 skill-library-version: "1.53.0"
18allowed-tools: Read Edit Write Glob Grep Bash(go:*) Bash(golangci-lint:*) Bash(git:*) mcp__context7__resolve-library-id mcp__context7__query-docs AskUserQuestion Bash(godig:*) Bash(gopls:*) LSP mcp__gopls__*
19paths:
20 - "**/*.go"
21---
22
23**Persona:** You are a Go engineer who prefers declarative collection transforms over manual loops. You reach for `lo` to eliminate boilerplate, but you know when the stdlib is enough and when to upgrade to `lop`, `lom`, or `loi`.
24
25# samber/lo — Functional Utilities for Go
26
27Lodash-inspired, generics-first utility library with 500+ type-safe helpers for slices, maps, strings, math, channels, tuples, and concurrency. Zero external dependencies. Immutable by default.
28
29**Official Resources:**
30
31- [github.com/samber/lo](https://github.com/samber/lo)
32- [lo.samber.dev](https://lo.samber.dev)
33- [pkg.go.dev/github.com/samber/lo](https://pkg.go.dev/github.com/samber/lo)
34
35This skill is not exhaustive — refer to library documentation and code examples for more information:
36
37- For Go package docs, symbols, versions, importers, and known vulnerabilities, → See `samber/cc-skills-golang@golang-pkg-go-dev` skill (`godig`), preferred over Context7 for Go package facts.
38- To navigate this library's usage in your own code (definitions, call sites, diagnostics), → See `samber/cc-skills-golang@golang-gopls` skill (`gopls`).
39- Context7 remains a fallback for docs not indexed on pkg.go.dev.
40
41## Why samber/lo
42
43Go'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:
44
45- **Type-safe generics** — no `interface{}` casts, no reflection, compile-time checking, no interface boxing overhead
46- **Immutable by default** — returns new collections, safe for concurrent reads, easier to reason about
47- **Composable** — functions take and return slices/maps, so they chain without wrapper types
48- **Zero dependencies** — only Go stdlib, no transitive dependency risk
49- **Progressive complexity** — start with `lo`, upgrade to `lop`/`lom`/`loi` only when profiling demands it
50- **Error variants** — most functions have `Err` suffixes (`MapErr`, `FilterErr`, `ReduceErr`) that stop on first error
51
52## Installation
53
54```bash
55go get github.com/samber/lo
56```
57
58| Package | Import | Alias | Go version |
59| --- | --- | --- | --- |
60| Core (immutable) | `github.com/samber/lo` | `lo` | 1.18+ |
61| Parallel | `github.com/samber/lo/parallel` | `lop` | 1.18+ |
62| Mutable | `github.com/samber/lo/mutable` | `lom` | 1.18+ |
63| Iterator | `github.com/samber/lo/it` | `loi` | 1.23+ |
64| SIMD (experimental) | `github.com/samber/lo/exp/simd` | — | 1.25+ (amd64 only) |
65
66## Choose the Right Package
67
68Start with `lo`. Move to other packages only when profiling shows a bottleneck or when lazy evaluation is explicitly needed.
69
70| Package | Use when | Trade-off |
71| --- | --- | --- |
72| `lo` | Default for all transforms | Allocates new collections (safe, predictable) |
73| `lop` | CPU-bound work on large datasets (1000+ items) | Goroutine overhead; not for I/O or small slices |
74| `lom` | Hot path confirmed by `pprof -alloc_objects` | Mutates input — caller must understand side effects |
75| `loi` | Large datasets with chained transforms (Go 1.23+) | Lazy evaluation saves memory but adds iterator complexity |
76| `simd` | Numeric bulk ops after benchmarking (experimental) | Unstable API, may break between versions |
77
78**Key rules:**
79
80- `lop` is for CPU parallelism, not I/O concurrency — for I/O fan-out, use `errgroup` instead
81- `lom` breaks immutability — only use when allocation pressure is measured, never assumed
82- `loi` eliminates intermediate allocations in chains like `Map → Filter → Take` by evaluating lazily
83- For reactive/streaming pipelines over infinite event streams, → see `samber/cc-skills-golang@golang-samber-ro` skill + `samber/ro` package
84
85For detailed package comparison and decision flowchart, see [Package Guide](./references/package-guide.md).
86
87## Core Patterns
88
89### Transform a slice
90
91```go
92// ✓ lo — declarative, type-safe
93names := lo.Map(users, func(u User, _ int) string {
94 return u.Name
95})
96
97// ✗ Manual — boilerplate, error-prone
98names := make([]string, 0, len(users))
99for _, u := range users {
100 names = append(names, u.Name)
101}
102```
103
104### Filter + Reduce
105
106```go
107total := lo.Reduce(
108 lo.Filter(orders, func(o Order, _ int) bool {
109 return o.Status == "paid"
110 }),
111 func(sum float64, o Order, _ int) float64 {
112 return sum + o.Amount
113 },
114 0,
115)
116```
117
118### GroupBy
119
120```go
121byStatus := lo.GroupBy(tasks, func(t Task, _ int) string {
122 return t.Status
123})
124// map[string][]Task{"open": [...], "closed": [...]}
125```
126
127### Error variant — stop on first error
128
129```go
130results, err := lo.MapErr(urls, func(url string, _ int) (Response, error) {
131 return http.Get(url)
132})
133```
134
135## Common Mistakes
136
137| Mistake | Why it fails | Fix |
138| --- | --- | --- |
139| Using `lo.Contains` when `slices.Contains` exists | Unnecessary dependency for a stdlib-covered op | Prefer `slices.Contains`/`slices.Sort` since Go 1.21+ and `slices.Collect(maps.Keys(m))` since Go 1.23+ when a key slice is needed |
140| Using `lop.Map` on 10 items | Goroutine creation overhead exceeds transform cost | Use `lo.Map` — `lop` benefits start at ~1000+ items for CPU-bound work |
141| Assuming `lo.Filter` modifies the input | `lo` is immutable by default — it returns a new slice | Use `lom.Filter` if you explicitly need in-place mutation |
142| Using `lo.Must` in production code paths | `Must` panics on error — fine in tests and init, dangerous in request handlers | Use the non-Must variant and handle the error |
143| Chaining many eager transforms on large data | Each step allocates an intermediate slice | Use `loi` (lazy iterators) to avoid intermediate allocations |
144
145## Best Practices
146
1471. **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 doesn't offer (Map, Filter, Reduce, GroupBy, Chunk, Flatten)
1482. **Compose lo functions** — chain `lo.Filter` → `lo.Map` → `lo.GroupBy` instead of writing nested loops. Each function is a building block
1493. **Profile before optimizing** — switch from `lo` to `lom`/`lop` only after `go tool pprof` confirms allocation or CPU as the bottleneck
1504. **Use error variants** — prefer `lo.MapErr` over `lo.Map` + manual error collection. Error variants stop early and propagate cleanly
1515. **Use `lo.Must` only in tests and init** — in production, handle errors explicitly
152
153## Quick Reference
154
155| Function | What it does |
156| --- | --- |
157| `lo.Map` | Transform each element |
158| `lo.Filter` / `lo.Reject` | Keep / remove elements matching predicate |
159| `lo.Reduce` | Fold elements into a single value |
160| `lo.ForEach` | Side-effect iteration |
161| `lo.GroupBy` | Group elements by key |
162| `lo.Chunk` | Split into fixed-size batches |
163| `lo.Flatten` | Flatten nested slices one level |
164| `lo.Uniq` / `lo.UniqBy` | Remove duplicates |
165| `lo.Find` / `lo.FindOrElse` | First match or default |
166| `lo.Contains` / `lo.Every` / `lo.Some` | Membership tests |
167| `lo.Keys` / `lo.Values` | Extract map keys or values |
168| `lo.PickBy` / `lo.OmitBy` | Filter map entries |
169| `lo.Zip2` / `lo.Unzip2` | Pair/unpair two slices |
170| `lo.Range` / `lo.RangeFrom` | Generate number sequences |
171| `lo.Ternary` / `lo.If` | Inline conditionals |
172| `lo.ToPtr` / `lo.FromPtr` | Pointer helpers |
173| `lo.Must` / `lo.Try` | Panic-on-error / recover-as-bool |
174| `lo.Async` / `lo.Attempt` | Async execution / retry with backoff |
175| `lo.Debounce` / `lo.Throttle` | Rate limiting |
176| `lo.ChannelDispatcher` | Fan-out to multiple channels |
177
178For the complete function catalog (300+ functions), see [API Reference](./references/api-reference.md).
179
180For composition patterns, stdlib interop, and iterator pipelines, see [Advanced Patterns](./references/advanced-patterns.md).
181
182If you encounter a bug or unexpected behavior in samber/lo, open an issue at [github.com/samber/lo/issues](https://github.com/samber/lo/issues).
183
184## Cross-References
185
186- → See `samber/cc-skills-golang@golang-samber-ro` skill for reactive/streaming pipelines over infinite event streams (`samber/ro` package)
187- → See `samber/cc-skills-golang@golang-samber-mo` skill for monadic types (Option, Result, Either) that compose with lo transforms
188- → See `samber/cc-skills-golang@golang-data-structures` skill for choosing the right underlying data structure
189- → See `samber/cc-skills-golang@golang-performance` skill for profiling methodology before switching to `lom`/`lop`