golang-samber-mo

Implement monadic types in Go using samber/mo for type-safe nullable values and error handling.

1|Updated Jun 2, 2026
One-click install
npx skills add https://github.com/VerifiedOrganic/onboard --skill golang-samber-mo-verifiedorganic
Or copy as Structured Prompt for Agent▼
Please help me install this Agent Skill.
Skill: golang-samber-mo
Source: https://github.com/VerifiedOrganic/onboard/tree/main/.agents/skills/golang-samber-mo
Command: npx skills add https://github.com/VerifiedOrganic/onboard --skill golang-samber-mo-verifiedorganic

SYSTEM DOCUMENTATION & REQUIREMENTS

💡 This Skill requires github.com/samber/mo, and includes references (resource) components.

What problem does it solve? Go codebases rely on nil pointers and repetitive if err != nil checks, which cause runtime panics and verbose error handling. This Skill teaches how to use the samber/mo library's monadic types — Option, Result, Either, Future, IO, Task, and State — to make absence and failure explicit in the type system and compose multi-step pipelines without nested error checks. ## Core Features & Use Cases - Option[T] for nullable values: Replace nil pointers with Some/None, with built-in JSON marshaling and SQL Scanner/Valuer support for database models and API responses. - Result[T] and Either[L, R] for error handling: Convert Go's (T, error) tuples with TupleToResult, chain operations with Map/FlatMap, and use Either when both outcomes are valid alternatives. - Type-changing pipelines: Use sub-package functions (option.Map, result.Pipe3) and mo.Do notation to work around Go's limitation that methods cannot introduce new type parameters. - Use Case: When building a config loader that reads a file, parses YAML, and validates the result, wrap os.ReadFile with mo.TupleToResult and chain parse and validate steps through result.Pipe2 so errors short-circuit automatically. ## Quick Start Ask the agent to refactor a Go function that returns (T, error) into a samber/mo Result pipeline using TupleToResult and FlatMap chaining.

Frequently Asked Questions about golang-samber-mo

High-intent search queries and answers about installing and using this skill.

FAQPage Schema
How do I handle nullable database columns in Go with samber/mo?▼

Use mo.Option[string] for nullable columns instead of *string. Option implements sql.Scanner and driver.Valuer, so row.Scan and db.Exec work directly, and it also implements json.Marshaler so the same struct serves both database and JSON API responses.

When should I use Result vs Either in samber/mo?▼

Use Result[T] when one path is an error, since it is specialized for success/failure with an error type. Use Either[L, R] when both outcomes are valid alternatives, such as cached versus fresh data, where neither side represents a failure.

Why can't Option.Map change the type in samber/mo?▼

Go methods cannot introduce new type parameters, so Option.Map returns Option[T] with the same type. For type-changing transforms like Option[int] to Option[string], use the curried option.Map function from the github.com/samber/mo/option sub-package.

How do I convert Go's (T, error) pattern to samber/mo Result?▼

Call mo.TupleToResult with the function's return values, for example mo.TupleToResult(os.ReadFile(path)). This converts the tuple to Ok on nil error or Err otherwise, letting you chain Map and FlatMap without manual error checks.

When should I avoid using monads in Go?▼

Avoid monads for simple one-step operations where a plain if err != nil check is clearer, in performance-critical hot paths, and when the team is unfamiliar with functional patterns. Result and Option shine in multi-step transformation chains, not single calls.

What is the difference between Future and Task in samber/mo?▼

Future starts executing immediately when constructed, while Task is lazy and only runs when Run() is called. Task.Run() returns a *Future[T], so use Task when you want to define an async computation now but trigger it later.