Discussion on "Library vs Language: Two Approaches to Functional Programming in Go"

Maksim Martianov · 2026-03-15T21:48:08.665Z

If you have used IBM's fp-go library, you know the promise of functional programming in Go -- and the pain of Go's syntax fighting you every step of the way. Pipe3, Pipe5, Pipe7. Function adapters eve

Congratulations on this awesome article and kudos for the development of GALA. I think you are spot on pinpointing the challenges one faces when trying to apply functional patterns to pure go. In particular the lack of function overloading that leads to PipeXXX in fp-go is a real pain point. And so is the limitted types system. Go 1.24 has made a significant step forward by allowing type aliases for generic types. This makes switching between monads much simpler.

As the author of fp-go I would like to point out that the syntax of the fp-go examples can be simplified.

For example instead of

result := function.Pipe3(
    O.Some(42),
    O.Map(func(x int) int { return x * 2 }),
    O.Chain(func(x int) O.Option[int] {
        if x > 50 { return O.Some(x) }
        return O.None[int]()
    }),
    O.GetOrElse(func() int { return 0 }),
)

I would write

    result := F.Pipe3(
        O.Some(42),
        O.Map(N.Mul(2)),
        O.Filter(N.MoreThan(50)),
        O.GetOrElse(L.Of(0)),
    )

Actually in the spirit of the library I would avoid writing a pipeline but rather a new function that implements the pipeline and that can then be reused and composed like this:

    endo := F.Flow4(
        O.Some,
        O.Map(N.Mul(2)),
        O.Filter(N.MoreThan(50)),
        O.GetOrElse(L.Of(0)),
    )
    fmt.Println(endo(42))
    fmt.Println(endo(2))

As a bonus such a function can be unit tested.

Thanks for your splendid work and for spreading the idea of functional patterns across the go community!

Carsten

Great article - really enjoyed reading this.

The comparison between the library approach (fp-go) and the language-level approach (GALA) to bringing functional programming into Go is very insightful. The examples around Option pipelines, Either error handling, and collection transformations clearly show how Go’s syntax introduces verbosity when FP patterns are implemented purely as libraries.

I especially liked the discussion around type annotations, Pipe functions, and the signal-to-noise ratio in fp-go versus the cleaner method chaining, lambda inference, and pattern matching in GALA. The side-by-side examples make the trade-offs very clear.

It’s interesting to see how fp-go proves that FP abstractions can work in Go, while GALA explores what happens when those ideas are supported at the language level instead of through libraries.

Really thoughtful breakdown of the design tension between staying within Go’s ecosystem vs improving developer ergonomics for FP-heavy codebases.

Search Hashnode

Library vs Language: Two Approaches to Functional Programming in Go

Responses(4)