Generated banner for Golang Samber Lo
Generated logo for Golang Samber Lo

Golang Samber Lo

Samuel BertheCommunityCreated by samberDistributed by Samuel Berthe

  • Skill
  • Tool integration
  • Software development
  • MIT
  • No issues found

From the author

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).
— the description by samber

AutoGineer summary

Written by AutoGineer from the skill’s own files, not by the author

The samber/lo library brings Lodash-inspired functional programming patterns to Go. It provides a comprehensive suite of type-safe, generic functions for manipulating slices, maps, channels, and strings. By offering immutable-by-default operations, it helps developers reduce boilerplate code associated with manual loops while maintaining type safety and avoiding reflection. The library includes specialized sub-packages for parallel processing (lop), in-place mutation (lom), and lazy evaluation (loi), allowing developers to scale from simple data transformations to performance-optimized pipelines.

What it does

  • Provides 500+ generic functions for common data manipulation tasks like Map, Filter, Reduce, and GroupBy.
  • Supports immutable operations by default to ensure safer concurrent reads.
  • Includes specialized packages for parallel execution (lop) and in-place mutation (lom) for performance tuning.
  • Offers lazy iterator support (loi) for Go 1.23+ to minimize memory allocations in transformation chains.
  • Includes error-handling variants for common functions to simplify control flow.
  • Maintains zero external dependencies, relying solely on the Go standard library.

When to use it

  • When you need to perform complex data transformations on slices or maps that would otherwise require verbose manual loops.
  • When you want to adopt a more declarative, functional coding style in your Go projects.
  • When you need to handle errors during collection processing using built-in error-propagating variants.
  • When profiling indicates that standard library approaches are insufficient and you need parallel or lazy evaluation strategies.
  • When you need to perform set operations or complex grouping tasks efficiently.

Advantages

  • Eliminates boilerplate code and reduces the surface area for logic errors in loops.
  • Type-safe generics ensure compile-time checking without the overhead of interface boxing.
  • Composable design allows chaining operations cleanly.
  • Progressive complexity allows starting with simple helpers and upgrading to performance-oriented variants only when necessary.
  • Zero dependencies minimize supply chain risks.

Usage examples

“Use lo.Map to extract names from a slice of user structs.”
The agent generates a concise lo.Map call, replacing a manual for-loop and make-slice initialization.
“How do I group tasks by status using samber/lo?”
The agent provides a snippet using lo.GroupBy, demonstrating how to transform a slice into a map of slices.
“I have a large slice and need to filter and map it without extra allocations.”
The agent suggests using the loi (lazy iterator) package to chain operations lazily, avoiding intermediate slice allocations.
“My code is failing on the first error during a map operation; how can I fix this?”
The agent recommends switching to lo.MapErr, which stops processing immediately upon encountering an error and returns the error value.

Install

  1. Download the skill as a ZIP:

    https://mp-staging.autogineer.com/agent-skills/samber/golang-samber-lo/download
  2. Unzip it into the cross-client skills folder of your project:

    mkdir -p .agents/skills && unzip golang-samber-lo.zip -d .agents/skills

Documentation by samber

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
PackageImportAliasGo version
Core (immutable)github.com/samber/lolo1.18+
Parallelgithub.com/samber/lo/parallellop1.18+
Mutablegithub.com/samber/lo/mutablelom1.18+
Iteratorgithub.com/samber/lo/itloi1.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.

PackageUse whenTrade-off
loDefault for all transformsAllocates new collections (safe, predictable)
lopCPU-bound work on large datasets (1000+ items)Goroutine overhead; not for I/O or small slices
lomHot path confirmed by pprof -alloc_objectsMutates input — caller must understand side effects
loiLarge datasets with chained transforms (Go 1.23+)Lazy evaluation saves memory but adds iterator complexity
simdNumeric 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

MistakeWhy it failsFix
Using lo.Contains when slices.Contains existsUnnecessary dependency for a stdlib-covered opPrefer 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 itemsGoroutine creation overhead exceeds transform costUse lo.Map — lop benefits start at ~1000+ items for CPU-bound work
Assuming lo.Filter modifies the inputlo is immutable by default — it returns a new sliceUse lom.Filter if you explicitly need in-place mutation
Using lo.Must in production code pathsMust panics on error — fine in tests and init, dangerous in request handlersUse the non-Must variant and handle the error
Chaining many eager transforms on large dataEach step allocates an intermediate sliceUse loi (lazy iterators) to avoid intermediate allocations

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 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

FunctionWhat it does
lo.MapTransform each element
lo.Filter / lo.RejectKeep / remove elements matching predicate
lo.ReduceFold elements into a single value
lo.ForEachSide-effect iteration
lo.GroupByGroup elements by key
lo.ChunkSplit into fixed-size batches
lo.FlattenFlatten nested slices one level
lo.Uniq / lo.UniqByRemove duplicates
lo.Find / lo.FindOrElseFirst match or default
lo.Contains / lo.Every / lo.SomeMembership tests
lo.Keys / lo.ValuesExtract map keys or values
lo.PickBy / lo.OmitByFilter map entries
lo.Zip2 / lo.Unzip2Pair/unpair two slices
lo.Range / lo.RangeFromGenerate number sequences
lo.Ternary / lo.IfInline conditionals
lo.ToPtr / lo.FromPtrPointer helpers
lo.Must / lo.TryPanic-on-error / recover-as-bool
lo.Async / lo.AttemptAsync execution / retry with backoff
lo.Debounce / lo.ThrottleRate limiting
lo.ChannelDispatcherFan-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

Files

Requirements and compatibility

Written for: Claude Code, OpenAI Codex

Works with: Claude Code, Claude apps, OpenAI Codex, GitHub Copilot, Cursor, Gemini CLI, Kiro, OpenCode, Goose, Amp, Roo Code, JetBrains Junie, Factory Droid, Devin (ex-Windsurf), Mistral Vibe, OpenHands, Letta

“Works with” means the tool reads the open Agent Skills format; a skill written for one tool may use features others lack.

Needs: Declares allowed tools, Claude Code frontmatter

The author says: Designed for Claude Code, Codex or similar harness, and for projects using Golang.

Security

No issues found by our static scan· No issues found

A static scan is not a guarantee. Skills are third-party content: review a skill before you let an agent use it.

Attribution and licence

Created by
samber
Publisher
Samuel Berthe (Community)
Distributed by
Samuel Berthe
Source
samber/cc-skills-golang · skills/golang-samber-lo · commit bb1d43d
Licence
MIT License (redistribution allowed)
  • LICENSE (added by AutoGineer from LICENSE)
  • ATTRIBUTION.md (written by AutoGineer)
Synced

AutoGineer is not affiliated with or endorsed by samber or Samuel Berthe.

Download ZIP

The ZIP holds the skill’s files, its licence files and an ATTRIBUTION.md. Download golang-samber-lo.zip