They are right. And lo and mo are genuinely good solutions within the constraints of Go's type system. But those constraints are real, and they shape every API in ways that become visible the moment you compare them to what a language-level implementation looks like.

I am the author of GALA, a language that transpiles to Go. This is not a "lo is bad" post. This is a post about what happens when you move functional patterns from library space into language space -- and what you gain and lose in the process.

What lo and mo solve

lo gives Go developers Lodash-style collection operations: Map, Filter, Reduce, GroupBy, Chunk, Flatten, and dozens more. Before generics landed in Go 1.18, this was impossible without code generation or interface{}. lo was one of the first libraries to prove that Go generics could deliver real ergonomic gains.

mo goes further. It brings monadic types to Go: Option[T], Result[T], Either[L, R], Future[T]. These are types that encode success/failure, presence/absence, and either/or semantics directly in the type system, enabling method chaining instead of if err != nil waterfalls.

Both libraries are well-designed. Both solve real problems. But both also bump into limitations that no Go library can work around.

Side by side: Collection operations

Here is a common pattern -- filter a list of users, extract names, aggregate a result.

samber/lo:

evens := lo.Filter(users, func(u User, _ int) bool {
    return u.Active && u.Age >= 18
})

names := lo.Map(evens, func(u User, _ int) string {
    return u.Name
})

result := strings.Join(names, ", ")

totalAge := lo.Reduce(users, func(acc int, u User, _ int) int {
    return acc + u.Age
}, 0)

GALA:

val result = users
    .Filter((u) => u.Active && u.Age >= 18)
    .Map((u) => u.Name)
    .MkString(", ")

val totalAge = users.FoldLeft(0, (acc, u) => acc + u.Age)

Three differences stand out.

The unused index parameter. Every lo callback takes an extra _ int index parameter, even when you do not need it. This is a design compromise -- lo provides a single API for both indexed and non-indexed access. In GALA, lambdas take only the parameters the operation requires.

Method chaining vs function wrapping. lo uses free functions: lo.Filter(lo.Map(xs, f), g). To chain operations, you nest calls or use intermediate variables. GALA collections are types with methods, so operations chain naturally: xs.Map(f).Filter(g). The pipeline reads left to right, top to bottom.

Lambda syntax. Go requires func, explicit parameter types, explicit return type, and curly braces. GALA infers parameter types from the method signature: (u) => u.Name instead of func(u User, _ int) string { return u.Name }. The type information is still checked -- you just do not have to write it.

Here is a numeric example to make the contrast sharper:

samber/lo:

evens := lo.Filter(nums, func(x int, _ int) bool {
    return x%2 == 0
})
squares := lo.Map(evens, func(x int, _ int) int {
    return x * x
})
sum := lo.Reduce(squares, func(acc int, x int, _ int) int {
    return acc + x
}, 0)

GALA:

val result = nums
    .Filter((x) => x % 2 == 0)
    .Map((x) => x * x)
    .FoldLeft(0, (acc, x) => acc + x)

Same logic. One reads as a pipeline. The other reads as a sequence of transformations with ceremony around each step.

Side by side: Option types

mo brings Option[T] to Go, which is a genuine improvement over nil pointers.

samber/mo:

opt := mo.Some(42)
result := opt.FlatMap(func(value int) mo.Option[int] {
    if value > 50 {
        return mo.Some(value * 2)
    }
    return mo.None[int]()
}).OrElse(0)

GALA:

val result = Some(42)
    .Map((x) => x * 2)
    .FlatMap((x int) => if (x > 50) Some(x) else None[int]())
    .GetOrElse(0)

The API shapes are similar -- both support Map, FlatMap, and a default value fallback. But GALA's version benefits from shorter lambda syntax and the ability to use if/else as an expression (it returns a value, so no curly braces or explicit return needed).

The real difference shows up when you pattern match on the result:

samber/mo:

either := mo.Right[string, int](42)
either.Match(
    func(err string) { fmt.Println("error:", err) },
    func(val int) { fmt.Println("value:", val) },
)

GALA:

val r1 = validateAge(25) match {
    case Right(age) => s"Valid age: $age"
    case Left(err)  => s"Error: $err"
}

mo's Match takes two function callbacks. GALA's match is a language construct that destructures the value, binds variables, and returns a result -- all in one expression. The GALA version is also exhaustive: if Either had a third variant, the compiler would reject incomplete matches.

The three things Go lacks that no library can fix

lo and mo are pushing against the boundaries of what Go's type system allows. Three specific limitations shape every API decision:

1. Lambda syntax. Go's anonymous functions require func, parameter types, return type, and braces. This is fine for callbacks that span multiple lines, but painful for one-liners. func(x int, _ int) bool { return x%2 == 0 } is a lot of syntax for "is this number even?" GALA's (x) => x % 2 == 0 says the same thing with less noise, because parameter types are inferred from context.

2. Type inference for generics. Go can infer type parameters in some cases, but not all. mo requires mo.None[int]() -- you cannot write mo.None() and have the compiler figure out T=int from context. GALA's type inference resolves generic parameters from usage: Some(42) is Option[int] without annotation. FoldLeft(0, (acc, x) => acc + x) infers that the accumulator is int from the zero value.

3. Algebraic data types. This is the big one. Go has no sum types. mo implements Option as a struct with a boolean flag and a value field. Either is a struct with a flag indicating left or right. These work, but the compiler cannot enforce exhaustive handling. You can forget to check IsPresent() before calling MustGet(), and the compiler will not stop you. GALA's sealed types are true algebraic data types with compiler-enforced exhaustiveness:

sealed type Shape {
    case Circle(Radius float64)
    case Rectangle(Width float64, Height float64)
    case Point()
}

func describe(s Shape) string = s match {
    case Circle(r)       => f"circle with radius=$r%.2f"
    case Rectangle(w, h) => s"rectangle \({w}x\){h}"
    case Point()         => "a point"
}

Add a new variant to Shape and every match expression that does not handle it becomes a compile error. No library in Go can provide this guarantee, because Go's type system does not support closed type hierarchies.

What GALA adds beyond lo and mo

Beyond cleaner syntax for the same operations, GALA provides constructs that have no library equivalent:

Immutability by default. Variables declared with val cannot be reassigned. Struct fields are immutable unless explicitly marked var. Every struct gets an auto-generated Copy method for creating modified versions. This is not a convention -- it is compiler-enforced.

String interpolation. s"Hello \(name" and f"\)value%.2f" replace fmt.Sprintf calls. Format verbs are inferred from the variable type. No import needed.

Expression-oriented syntax. if/else, match, and single-expression functions all return values. func square(x int) int = x * x -- no braces, no return keyword. This removes an entire category of "forgot to return" bugs.

Full Go interop. GALA transpiles to Go. Every Go package is importable. Every Go type is usable. There is no FFI boundary, no wrapper generation, no runtime overhead beyond what the transpiler generates. If you use net/http, database/sql, or any Go library, it works directly.

When to use lo/mo vs GALA

Use lo/mo when:

• You have an existing Go codebase and want incremental improvements

• Your team is comfortable with Go and does not want to learn a new syntax

• You need a few specific utilities (lo's Chunk, GroupBy, Uniq) without adopting a new language

• You want to stay within the official Go toolchain

Consider GALA when:

• You are starting a new Go-targeted project and want stronger type guarantees from day one

• Your domain has complex state machines, protocol types, or AST-like structures that benefit from sealed types

• You want immutability enforced by the compiler, not by convention

• You come from Scala, Kotlin, or Rust and want similar expressiveness with Go's deployment model

• You are building data transformation pipelines where functional collection operations dominate the code

Honest tradeoffs

GALA is not a free upgrade. Here is what you give up:

Ecosystem maturity. Go has world-class tooling: debuggers, profilers, IDE support, error messages refined over 15 years. GALA has an IntelliJ plugin with syntax highlighting and completion, but it is not at the same level. You will hit rough edges.

Team familiarity. lo is Go code. Any Go developer can read it, debug it, and contribute to it. GALA requires learning a new syntax. The concepts (sealed types, pattern matching, FoldLeft) are well-established in other languages, but they require investment from developers who have not used them before.

Compilation step. GALA adds a transpilation step before Go compilation. With Bazel, this is seamless. Without it, you are running gala build before go build.

Community size. lo has 21,000 stars and a large contributor base. GALA is a younger project. The standard library is solid -- Option, Either, Try, Future, six collection types -- but the ecosystem around it is smaller.

These are real costs. Whether the expressiveness gains justify them depends on your team, your domain, and your tolerance for early-adopter friction.

Try it

GALA has a browser-based playground at gala-playground.fly.dev with built-in examples. No installation required.

For local development: download a binary from GitHub releases, or build from source with Bazel. GALA is at v0.17.1, with binaries for Linux, macOS, and Windows.

The 21,000 stars on samber/lo are not just a success story for a library. They are evidence that a significant segment of Go developers wants functional programming patterns -- and is willing to adopt third-party dependencies to get them. GALA asks: what if those patterns were not bolted on, but built in?

I am the author of GALA. Source: github.com/martianoff/gala

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 everywhere. Type parameters that stretch across the screen. You know the patterns work because you have seen them in Haskell or fp-ts, but the Go rendition feels like wearing a suit two sizes too small.

fp-go is a serious library. With nearly 2,000 GitHub stars and a design rooted in fp-ts, it brings real functional abstractions to Go: Option, Either, IO, Reader, State, and more. The engineering is impressive. But it also exposes a fundamental tension: Go's syntax was not designed for this style of programming, and no library can fully bridge that gap.

This article compares two approaches to the same problem: fp-go (the library approach) and GALA (the language approach). Both target developers who want FP patterns in Go-compatible code. They make very different trade-offs.

Disclosure: I am the author of GALA. I have tried to present both approaches fairly, but you should know where I stand. I have genuine respect for fp-go's engineering -- it pushed me to think about what a language-level solution should look like.

The Library Approach: fp-go

fp-go models functional abstractions as Go packages. Option lives in github.com/IBM/fp-go/option. Either lives in github.com/IBM/fp-go/either. Composition happens through Pipe functions that chain operations sequentially.

Here is a typical fp-go Option pipeline. You have a value that might be absent, and you want to transform it:

import (
    O "github.com/IBM/fp-go/option"
    "github.com/IBM/fp-go/function"
)

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

This works. The types are correct, the behavior is well-defined. But look at what Go's syntax demands: explicit func keywords on every lambda, full type annotations on every parameter and return, separate imports for each module, and a Pipe3 function (not Pipe2, not Pipe4 -- the arity must match the number of operations).

Error handling with Either follows the same pattern:

import (
    E "github.com/IBM/fp-go/either"
    "github.com/IBM/fp-go/function"
)

result := function.Pipe2(
    E.Right[string](25),
    E.Chain(func(age int) E.Either[string, int] {
        if age < 0 {
            return E.Left[int]("age cannot be negative")
        }
        return E.Right[string](age)
    }),
    E.Fold(
        func(err string) string { return "Error: " + err },
        func(age int) string { return fmt.Sprintf("Valid age: %d", age) },
    ),
)

The signal-to-noise ratio is the issue. The business logic -- "validate that age is non-negative" -- occupies a fraction of the code. The rest is structural: type annotations, function wrappers, pipe plumbing.

This is not a criticism of fp-go's design. It is an observation about Go as a host language for FP patterns. Go lacks three things that FP-heavy code relies on: concise lambda syntax, type inference for function parameters, and method chaining on generic types. No library can add these to Go.

The Language Approach: GALA

GALA is a language that transpiles to Go. It generates standard Go code, produces native binaries, and interoperates with every Go library. But it has its own syntax designed around functional patterns.

Here is the same Option pipeline in GALA:

package main

func main() {
    val result = Some(42)
        .Map((x) => x * 2)
        .FlatMap((x int) => if (x > 50) Some(x) else None[int]())
        .GetOrElse(0)
    Println(result)
}

No imports for Option -- it is a built-in type. No func keyword on lambdas. No Pipe function -- method chaining works directly. The lambda parameter type in Map is inferred from the Option's type parameter. The code reads as a description of the transformation, not a fight with the type system.

The difference is not cosmetic. It changes how much code you can absorb at a glance, which matters when you are reading a codebase you did not write.

Side-by-Side: Option Handling

fp-go:

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

GALA:

val result = Some(42)
    .Map((x) => x * 2)
    .FlatMap((x int) => if (x > 50) Some(x) else None[int]())
    .GetOrElse(0)

Both produce the same result: 84 (since 42 * 2 = 84, which is > 50). The GALA version is roughly a third of the line count. More importantly, the transformation pipeline is visible without mentally filtering out syntax.

Side-by-Side: Error Handling with Try

fp-go handles fallible operations through Either and IO. GALA provides a Try monad that wraps operations that might throw, similar to Scala's Try:

fp-go (Either-based):

import (
    E "github.com/IBM/fp-go/either"
    "github.com/IBM/fp-go/function"
    "strconv"
)

result := function.Pipe2(
    E.TryCatchError(func() (int, error) {
        return strconv.Atoi("42")
    }),
    E.Map[error](func(n int) int { return n * 2 }),
    E.GetOrElse(func(err error) int { return -1 }),
)

GALA:

package main

import "strconv"

func safeParse(s string) Try[int] = Try(() => strconv.Atoi(s))

func main() {
    val result = safeParse("42")
        .Map((n) => n * 2)
        .Recover((e) => -1)
    Println(result)

    val failed = safeParse("not_a_number")
        .Map((n) => n * 2)
        .Recover((e) => -1)
    Println(failed)
}

GALA's Try automatically handles Go's (T, error) multi-return convention. The lambda () => strconv.Atoi(s) returns (int, error), and Try converts a non-nil error into a Failure. No explicit error type parameters, no TryCatchError adapter.

Side-by-Side: Collections

Functional collection processing is where the verbosity gap becomes stark.

fp-go:

import (
    A "github.com/IBM/fp-go/array"
    "github.com/IBM/fp-go/function"
)

nums := []int{1, 2, 3, 4, 5, 6, 7, 8, 9, 10}
result := function.Pipe3(
    nums,
    A.Filter(func(x int) bool { return x%2 == 0 }),
    A.Map(func(x int) int { return x * x }),
    A.Reduce(func(acc int, x int) int { return acc + x }, 0),
)

GALA:

package main

import . "martianoff/gala/collection_immutable"

func main() {
    val nums = ArrayOf(1, 2, 3, 4, 5, 6, 7, 8, 9, 10)
    val result = nums
        .Filter((x) => x % 2 == 0)
        .Map((x) => x * x)
        .FoldLeft(0, (acc, x) => acc + x)
    Println(s"Sum of squares of evens: $result")
}

Both compute the same value: the sum of squares of even numbers from 1 to 10 (220). The GALA version chains methods on the collection itself. The fp-go version pipes the collection through free functions. Both are valid compositional styles, but method chaining eliminates the Pipe scaffolding and makes the data flow more immediately visible.

The Hidden Cost: Type Annotations

The examples above hint at it, but it is worth calling out explicitly: fp-go requires you to annotate types that GALA infers automatically.

In fp-go, every Map, Chain, and Fold call needs explicit type parameters because Go's generic inference does not propagate through free functions:

// fp-go: you must spell out every type
O.Map[int](func(x int) int { return x * 2 })
A.Filter(func(x int) bool { return x%2 == 0 })
A.Map(func(x int) int { return x * x })
A.Reduce(func(acc int, x int) int { return acc + x }, 0)
E.Chain(func(age int) E.Either[string, int] { ... })

In GALA, the transpiler infers lambda parameter types from the method's generic context. When you call .Map on an Array[int], the transpiler knows the lambda parameter is int. When you call .FoldLeft(0, ...), it infers the accumulator type from the zero value:

// GALA: types inferred from context
nums.Filter((x) => x % 2 == 0)          // x is int (from Array[int])
nums.Map((x) => x * x)                  // x is int, return is int
nums.FoldLeft(0, (acc, x) => acc + x)   // acc is int (from 0), x is int

This is not just fewer characters. It changes how you read code. In the fp-go version, your eyes parse type annotations before reaching the logic. In the GALA version, the logic is all there is. The types are still checked at compile time -- they are just inferred rather than written.

The inference extends to method type parameters too. list.Map((x) => x.Name) on a List[Person] infers that x is Person and the result is List[string], without writing Map[string] or annotating x.

Side-by-Side: Pattern Matching

This is where fp-go hits a hard wall. Go has no pattern matching syntax, so fp-go uses Fold functions as eliminators:

fp-go:

E.Fold(
    func(err string) string { return "Error: " + err },
    func(age int) string { return fmt.Sprintf("Valid age: %d", age) },
)(validateAge(25))

GALA:

package main

func validateAge(age int) Either[string, int] {
    if (age < 0) {
        return Left("age cannot be negative")
    } else if (age > 150) {
        return Left("age seems unrealistic")
    } else {
        return Right(age)
    }
}

func main() {
    val r1 = validateAge(25) match {
        case Right(age) => s"Valid age: $age"
        case Left(err)  => s"Error: $err"
    }
    Println(r1)

    val r2 = validateAge(-5) match {
        case Right(age) => s"Valid age: $age"
        case Left(err)  => s"Error: $err"
    }
    Println(r2)
}

Fold is functionally equivalent to pattern matching. It is also harder to read at scale. When you have nested matches, guards, or multiple extracted values, the anonymous-function-per-branch style becomes difficult to follow. GALA's match expression reads like a conditional: each branch is a pattern, an optional guard, and a result.

GALA also provides sealed types -- something fp-go cannot offer at all:

package main

sealed type Shape {
    case Circle(Radius float64)
    case Rectangle(Width float64, Height float64)
    case Point()
}

func describe(s Shape) string = s match {
    case Circle(r)       => f"circle with radius=$r%.2f"
    case Rectangle(w, h) => s"rectangle \({w}x\){h}"
    case Point()         => "a point"
}

func main() {
    Println(describe(Circle(3.14)))
    Println(describe(Rectangle(10, 5)))
    Println(describe(Point()))
}

If you add a new variant to Shape and forget to handle it in a match expression, the compiler rejects your code. This is compile-time exhaustiveness checking -- something that no Go library can provide because Go's type system does not support closed type hierarchies.

When to Use Which

Choose fp-go when:

• You need to stay in pure Go. Your team, your CI, your tooling -- all Go. fp-go is a dependency, not a language change.

• You want specific abstractions (IO, Reader, State) without adopting a new syntax. fp-go's module coverage is broad.

• You are adding FP patterns to an existing Go codebase incrementally. Import one package, use it in one function, expand from there.

• You want a mature community around Haskell-style typeclasses in Go. fp-go's design is principled and well-documented.

Choose GALA when:

• You want FP to feel native, not bolted on. Lambdas, type inference, and method chaining are part of the syntax.

• You need sealed types and exhaustive pattern matching. No Go library can provide compile-time exhaustiveness.

• You are starting a new project and want Go's operational characteristics (native binaries, goroutines, the Go ecosystem) with more expressive syntax.

• You come from Scala, Kotlin, or Rust and want similar idioms without the JVM or borrow checker.

Honest Trade-offs

GALA adds a transpilation step. Your source files are .gala, not .go. This means:

• Build tooling. GALA uses Bazel for its build system and provides gala run for quick iteration. This is an additional tool in your stack.

• Debugging. You debug the generated Go code, not the GALA source. The generated code is readable, but it is an extra layer of indirection.

• Community size. fp-go has nearly 2,000 GitHub stars and an active community. GALA is newer and smaller. You will find fewer Stack Overflow answers and fewer blog posts.

• IDE support. GALA has an IntelliJ plugin with syntax highlighting and completion. It is not at the level of Go's LSP-powered tooling.

• Maturity. fp-go has been battle-tested in production at IBM. GALA is at v0.17.1 -- functional and improving, but younger.

On the other side:

• fp-go's verbosity is structural, not fixable. Go will likely never get concise lambda syntax or HKT. The Pipe/Map/Chain ceremony is permanent.

• fp-go cannot add new syntax. Sealed types, pattern matching, val immutability, string interpolation -- these require language-level support.

• fp-go's learning curve is steep in its own way. Understanding Pipe5(value, F.Map(...), F.Chain(...), F.Fold(...), ...) requires internalizing a convention that has no visual affordance in Go.

Try It

GALA has an online playground where you can write and run code in the browser, no installation required:

gala-playground.fly.dev

The playground includes examples for Option chaining, pattern matching, sealed types, collections, and Go interop. If the code samples in this article looked interesting, the playground is the fastest way to get a feel for the language.

Source code and documentation: github.com/martianoff/gala

fp-go and GALA represent two legitimate responses to the same observation: Go's syntax makes functional patterns unnecessarily verbose. fp-go works within Go's constraints, accepting the ceremony as the cost of staying in the ecosystem. GALA steps outside those constraints, accepting a transpilation step as the cost of cleaner syntax. Neither is wrong. The right choice depends on how much of your codebase is FP-heavy, how important compile-time exhaustiveness is to your domain, and whether your team is willing to adopt a new language versus a new library.

If you are already using fp-go and find yourself wishing Go's lambdas were shorter, its type inference were better, and its type system supported sum types -- that is exactly the gap GALA was built to fill.

GALA is a programming language that transpiles to Go, bringing sealed types, exhaustive pattern matching, and algebraic data types to the Go ecosystem with zero runtime overhead. The output is plain Go code. Every Go library works. Every Go tool works. You just get better type safety where it matters.

This post walks through the problem, the solution, and real code you can try today.

The Problem: Modeling Variants in Go

Suppose you are building a graphics library and need to represent shapes. In Go, the standard approach uses interfaces and type switches:

type Shape interface {
    isShape()
}

type Circle struct {
    Radius float64
}
func (c Circle) isShape() {}

type Rectangle struct {
    Width  float64
    Height float64
}
func (r Rectangle) isShape() {}

type Triangle struct {
    Base   float64
    Height float64
}
func (t Triangle) isShape() {}

To compute the area, you write a type switch:

func area(s Shape) string {
    switch v := s.(type) {
    case Circle:
        return fmt.Sprintf("circle area: %.2f", math.Pi*v.Radius*v.Radius)
    case Rectangle:
        return fmt.Sprintf("rect area: %.2f", v.Width*v.Height)
    case Triangle:
        return fmt.Sprintf("triangle area: %.2f", 0.5*v.Base*v.Height)
    default:
        return "unknown shape"
    }
}

This works. But it has three problems that get worse as your codebase grows:

1. No exhaustiveness checking. Add a new Pentagon variant. The compiler says nothing. The default branch silently absorbs it, or worse, you forget the default and get a zero-value return. You find the bug in production.

2. Boilerplate. Every variant needs a struct, a marker method, and the type switch needs a default case. The interface itself (isShape()) carries no information -- it exists only to close the type set, and it does not even do that reliably since any package can implement it.

3. No destructuring. You cannot extract fields inline. You match the type, then access fields on the bound variable. This is verbose and error-prone when variants have many fields.

These issues have been discussed in Go proposals for years (golang/go#19412, golang/go#41716). Sum types and pattern matching remain among the most requested features. The Go team has chosen not to add them, and that is a reasonable decision for the language's goals. But the need does not go away.

Enter GALA

GALA (Go Alternative Language) transpiles to Go. You write GALA source, the transpiler produces standard Go code, and you build the result with go build or Bazel. There is no runtime library, no reflection magic, no code generation at runtime. The generated Go is the kind of code you would write by hand -- just more of it, and correct.

GALA gives you sealed types (algebraic data types), exhaustive pattern matching with destructuring and guards, Option[T]/Either[A,B]/Try[T] monads, immutable collections, and full Go interop. You can import any Go package, call any Go function, and use any Go library.

The trade-off is honest: you add a transpilation step. Your source files are .gala instead of .go. IDE support is available for IntelliJ but not yet universal. Whether that trade-off is worth it depends on your project. For codebases heavy on variant types, state machines, or functional data processing, it often is.

Sealed Types: Closed Type Hierarchies Done Right

Here is the same Shape example in GALA:

sealed type Shape {
    case Circle(Radius float64)
    case Rectangle(Width float64, Height float64)
    case Triangle(Base float64, Height float64)
}

That is the entire definition. The transpiler generates:

• A parent struct Shape with a _variant discriminator field

• Companion objects Circle{}, Rectangle{}, Triangle{} with Apply methods for construction

• Unapply methods for pattern matching (destructuring)

• IsCircle(), IsRectangle(), IsTriangle() discriminator methods

• Copy and Equal methods

Construction is concise:

val c = Circle(3.14)
val r = Rectangle(10.0, 20.0)

Sealed types also support generics:

sealed type Result[T any] {
    case Ok(Value T)
    case Err(Error error)
}

val success = Ok(42)
val failure = Err[int](fmt.Errorf("not found"))

Compare this to the Go version. The GALA definition is 4 lines. The Go version is 18 lines of structs and marker methods, and it still does not give you exhaustiveness checking or destructuring.

Pattern Matching: Beyond the Type Switch

GALA's match expression supports literal matching, variable binding, destructuring, guards, nested patterns, and type-based matching. Here is the area function:

func area(s Shape) string = s match {
    case Circle(r)       => f"circle area: ${3.14159 * r * r}%.2f"
    case Rectangle(w, h) => f"rect area: ${w * h}%.2f"
    case Triangle(b, h)  => f"triangle area: ${0.5 * b * h}%.2f"
}

Notice what is different from Go:

• Destructuring. case Circle(r) binds the Radius field to r in one step. No v := s.(Circle); r := v.Radius.

• Expression syntax. The entire match is an expression that returns a value. No var result string declaration before the switch.

• No default case. All three variants are covered. The compiler knows this. If you remove the Triangle branch, you get a compile error.

Guards

Guards add conditions to patterns:

struct Person(Name string, Age int)

val status = person match {
    case Person(name, age) if age < 18 => s"$name is a minor"
    case Person(name, age) if age > 65 => s"$name is a senior"
    case Person(name, _)               => s"$name is an adult"
}

The equivalent Go code needs a type switch (or if-else chain), manual field access, and a mutable variable to hold the result:

var status string
switch {
case person.Age < 18:
    status = fmt.Sprintf("%s is a minor", person.Name)
case person.Age > 65:
    status = fmt.Sprintf("%s is a senior", person.Name)
default:
    status = fmt.Sprintf("%s is an adult", person.Name)
}

Nested Patterns

Patterns compose. You can match extractors inside extractors:

type Even struct {}
func (e Even) Unapply(i int) Option[int] = if (i % 2 == 0) Some(i) else None[int]()

val opt = Some(10)
opt match {
    case Some(Even(n)) => Println(s"even number: $n")
    case Some(n)       => Println(s"odd number: $n")
    case None()        => Println("nothing")
}

Try writing that with Go type switches. You would need nested switches, temporary variables, and manual extractor logic. In GALA, the intent is clear in a single expression.

Type-Based Matching

When working with any or interface types, GALA supports type patterns directly:

val x any = "hello"

val res = x match {
    case s: string => "string: " + s
    case i: int    => s"int: $i"
    case _         => "unknown"
}

This is similar to Go's type switch, but integrated into the same match syntax as everything else.

Exhaustive Matching: The Compiler Catches Missing Cases

This is where golang sealed types and exhaustive matching really pay off. When you match on a sealed type and miss a variant, the GALA transpiler rejects the code at compile time.

Given this sealed type:

sealed type TrafficLight {
    case Red()
    case Yellow()
    case Green()
}

This code compiles:

val action = light match {
    case Red()    => "stop"
    case Yellow() => "caution"
    case Green()  => "go"
}

But remove the Yellow case and the transpiler reports an error: the match is not exhaustive. You cannot forget to handle a variant.

In Go, you would use iota constants or separate types with a type switch, and nothing stops you from forgetting a case. Linters like exhaustive exist but they are optional, require configuration, and only work with iota-based enums. GALA's exhaustiveness checking is built into the language and works with full algebraic data types, not just integer constants.

If you only care about some variants, use a wildcard catch-all:

val msg = light match {
    case Red() => "must stop"
    case _     => "can proceed"
}

This is explicit -- you are telling the compiler you have intentionally handled the remaining cases together.

Real-World Example: Expression Evaluator

Let us build a simple arithmetic expression evaluator using sealed types and pattern matching. This is a classic use case for go algebraic data types.

package main

sealed type Expr {
    case Num(Value float64)
    case Add(Left Expr, Right Expr)
    case Mul(Left Expr, Right Expr)
}

func eval(e Expr) float64 = e match {
    case Num(v)    => v
    case Add(l, r) => eval(l) + eval(r)
    case Mul(l, r) => eval(l) * eval(r)
}

func show(e Expr) string = e match {
    case Num(v)    => f"$v%.0f"
    case Add(l, r) => s"(\({show(l)} + \){show(r)})"
    case Mul(l, r) => s"(\({show(l)} * \){show(r)})"
}

func main() {
    // (2 + 3) * 4
    val expr = Mul(Add(Num(2), Num(3)), Num(4))
    Println(s"\({show(expr)} = \){eval(expr)}")
}

Output: ((2 + 3) * 4) = 20

Now here is the equivalent Go code. It is what the transpiler generates (simplified for clarity):

package main

import "fmt"

const (
    Expr_Num uint8 = iota
    Expr_Add
    Expr_Mul
)

type Expr struct {
    _variant uint8
    Value    float64
    Left     Expr
    Right    Expr
}

// Companion objects + Apply methods omitted for brevity

func eval(e Expr) float64 {
    switch e._variant {
    case Expr_Num:
        return e.Value
    case Expr_Add:
        return eval(e.Left) + eval(e.Right)
    case Expr_Mul:
        return eval(e.Left) * eval(e.Right)
    default:
        panic("non-exhaustive match")
    }
}

func show(e Expr) string {
    switch e._variant {
    case Expr_Num:
        return fmt.Sprintf("%.0f", e.Value)
    case Expr_Add:
        return fmt.Sprintf("(%s + %s)", show(e.Left), show(e.Right))
    case Expr_Mul:
        return fmt.Sprintf("(%s * %s)", show(e.Left), show(e.Right))
    default:
        panic("non-exhaustive match")
    }
}

func main() {
    expr := Expr{_variant: Expr_Mul,
        Left: Expr{_variant: Expr_Add,
            Left:  Expr{_variant: Expr_Num, Value: 2},
            Right: Expr{_variant: Expr_Num, Value: 3},
        },
        Right: Expr{_variant: Expr_Num, Value: 4},
    }
    fmt.Printf("%s = %.0f\n", show(expr), eval(expr))
}

The Go version is roughly three times longer. More importantly, the Go version has no compile-time guarantee that the switch is exhaustive. The default: panic is a runtime safety net, not a compile-time one. Add a Div variant to Expr and the Go compiler says nothing. The GALA compiler rejects the code until you handle Div in every match.

Option, Either, and Try: Standard Library Patterns

GALA's standard library uses sealed types throughout. These are not special compiler features -- they are regular sealed types that you could define yourself:

sealed type Option[T any] {
    case Some(Value T)
    case None()
}

sealed type Either[A any, B any] {
    case Left(LeftValue A)
    case Right(RightValue B)
}

sealed type Try[T any] {
    case Success(Value T)
    case Failure(Err error)
}

They all support pattern matching:

val result = fetchUser(id) match {
    case Success(user) => s"Hello, ${user.Name}"
    case Failure(err)  => s"Error: $err"
}

val name = user.Email match {
    case Some(email) => email
    case None()      => "no email on file"
}

And they support monadic chaining with Map, FlatMap, Filter, GetOrElse, and Recover:

val displayName = user.Name
    .Map((n) => strings.ToUpper(n))
    .GetOrElse("ANONYMOUS")

val result = divide(10, 2)
    .Map((x) => x * 2)
    .FlatMap((x) => divide(x, 3))
    .Recover((e) => 0)

This eliminates entire categories of nil-pointer bugs and forgotten error checks. The types make missing cases visible, and pattern matching makes handling them concise.

Try It Yourself

In your browser: The GALA Playground lets you write and run GALA code with no installation.

On your machine: Download a binary from GitHub Releases for Linux, macOS, or Windows. Then:

# Create a file
cat > main.gala << 'EOF'
package main

sealed type Shape {
    case Circle(Radius float64)
    case Rectangle(Width float64, Height float64)
}

func describe(s Shape) string = s match {
    case Circle(r)       => f"circle with radius $r%.2f"
    case Rectangle(w, h) => f"\({w}%.0f x \){h}%.0f rectangle"
}

func main() {
    Println(describe(Circle(3.14)))
    Println(describe(Rectangle(10, 5)))
}
EOF

# Run it
gala run main.gala

For projects, GALA integrates with Bazel:

load("//:gala.bzl", "gala_binary")

gala_binary(
    name = "myapp",
    src = "main.gala",
)

Conclusion

GALA does not replace Go. It transpiles to Go. The output is standard Go code that uses Go's type system, Go's runtime, and Go's toolchain. There is no runtime dependency, no reflection overhead, and no magic.

What GALA adds is a layer of compile-time safety for a specific class of problems: modeling closed variant types and ensuring every case is handled. If your codebase has state machines, AST nodes, protocol messages, API response types, or any domain with a fixed set of variants, sealed types and exhaustive pattern matching eliminate an entire category of bugs that Go's type system cannot catch.

The trade-off is a transpilation step and a different source language. For many projects, that trade-off is not worth it -- Go's simplicity is its strength. But for projects where type safety at the variant level matters more than syntactic familiarity, GALA gives you go pattern matching that the language itself has not yet provided.

Check out the GitHub repository for the full language specification, or try the playground to experiment with sealed types and pattern matching right now.

type Customer struct {
    firstName string
    car *Car // customer might have a car
}

type Car struct {
    plateNumber string
}

func getCustomerPlateNumber(customer Customer) *string {
    if customer.car != nil {
        return &customer.car.plateNumber
    }
    return nil
}

To make code more readable, especially if we have to deal with a chain of optional values, I made a library https://github.com/martianoff/go-option that uses functional language patterns and follows syntax of Scala Option

import "github.com/martianoff/go-option"

type Customer struct {
    firstName string
    car option.Option[Car] // customer might have a car
}

type Car struct {
    plateNumber string
}

func getCustomerPlateNumber(customer Customer) option.Option[string] {
    return option.Map(customer.car, func(car Car) string {
        return car.plateNumber
    })
}

Features of the package:

• Safe Handling of Missing Values: The Option[T] type encourages safer handling of missing values, avoiding null pointer dereferences. It can be checked for its state (whether it's Some or None) before usage, ensuring that no nil value is being accessed.

• Functional Methods: The module provides functional methods such as Map, FlatMap etc. that make operations on Option[T] type instances easy, clear, and less error-prone.

• Pattern Matching: The Match function allows for clean and efficient handling of Option[T] instances. Depending on whether the Option[T] is Some or None, corresponding function passed to Match get executed, which makes the code expressive and maintains safety.

• Equality Check: The Equal method provides an efficient way to compare two Option[T] instances, checking if they represent the same state and hold equal values.

• Generics-Based: With Generics introduced in Go, the module offers a powerful, type-safe alternative to previous ways of handling optional values.

• Json serialization and deserialization: Build-in Json support

By leveraging functional language patterns, developers can handle optional or nullable objects more effectively, reducing the risk of null pointer dereferences.

I have decided to dump my personal leetcode solutions archive. Currently it contains Scala solutions only. I will eventually publish all the remaining solutions in GO, JS and PHP and others.

These solutions have been collected over years and might have slightly different style, which evolved over time.

Purpose of the Project

The purpose of this project is not to endorse the mere copying of solutions but to learn, understand and internalize the logic and elegance of problem-solving in Scala. So, seize this opportunity to deepen your knowledge and become a better developer.

Access the Archive

The link to the archive is https://github.com/martianoff/leetcode-archive. Enjoy!

case class Time(hour: Hour, minutes: Minute)
case class Hour(hour: Int)
case class Minute(minute: Int)

Now let's try to implement a code that parses a string into Time using custom extractor

object Time {
  def unapply(stringTime: String): Option[Time] = {
    stringTime.split(":", 2) match {
      case Array(h, m) =>
        Some(Time(h, m))
      case _ => None
    }
  }
}

The problem with this code is that hours and minutes are not validated, therefore strings like "30:-1" will still be considered as valid time.

To solve this problem we can embed conditions into time extractor directly or better define separate Hour and Minute extractors with their own validation rules.

object Hour {
  def unapply(stringHour: String): Option[Hour] = {
    stringHour.toIntOption match {
      case Some(h) if h >= 0 && h <= 23 => Some(Hour(h))
      case _ => None
    }
  }
}

object Minute {
  def unapply(stringMinute: String): Option[Minute] = {
    stringMinute.toIntOption match {
      case Some(m) if m >= 0 && m <= 59 => Some(Minute(m))
      case _ => None
    }
  }
}

These extractors allow to extract minutes and hours from string only if they are valid. Now adjust the Time extractor to use extractors for hours and minutes

object Hour {
  def unapply(stringHour: String): Option[Hour] = {
    stringHour.toIntOption match {
      case Some(h) if h >= 0 && h <= 23 => Some(Hour(h))
      case _ => None
    }
  }
}

object Minute {
  def unapply(stringMinute: String): Option[Minute] = {
    stringMinute.toIntOption match {
      case Some(m) if m >= 0 && m <= 59 => Some(Minute(m))
      case _ => None
    }
  }
}
object Time {
  def unapply(stringTime: String): Option[Time] = {
    stringTime.split(":",2) match {
      case Array(Hour(h), Minute(m)) =>
        Some(Time(h, m))
      case _ => None
    }
  }
}

Let's test the code on a few unit tests

object TimeExtractors extends App {

  List("12:30", "-1:23", "a:b", "4:59", "1:2:3", "12:77").foreach {
    case strTime @ Time(t) => println(s"${strTime} converted to ${t}")
    case strTime => println(s"unknown time ${strTime}")
  }

}

Output from the code above

12:30 converted to Time(Hour(12),Minute(30)) 
unknown time -1:23 
unknown time a:b 
4:59 converted to Time(Hour(4),Minute(59)) 
unknown time 1:2:3 
unknown time 12:77

This article demonstrates how to implement a simple Time case class with validation for hours and minutes using extractors in Scala and how to combine multiple extractors to increase readability

val arr = Array(1,2,3)
arr(1) = 3
println(arr.mkString(",")) // 1,3,3

Immutable alternative to Scala Array is Scala Vector

val arr = Vector(1,2,3)
println(arr.updated(1,3).mkString(",")) // 1,3,3
println(arr.mkString(",")) // 1,2,3 because original array remains unchanged

Vector provides O(1) asymptotic time complexity prepend, append, random read, random write operations

Most important methods of Vector class:

Tap example

import scala.util.chaining._

trait StatsCounter {
    def incr(counterName: String): Unit
}

object Solution extends App {
      val value = 123
      val counter: StatsCounter = ... // implementation
      stringValue(value)
      def stringValue(v: Int): String = {
           // tap adds pure side effect without changing input value
           v.toString.tap { 
                 result => counter.incr(result)
            }
            // this code does the same without chaining
            // val result = v.toString
            // counter.incr(result)
            // result
       }
}

Pipe example

def calculate(value: Int) = {
      value
     .pipe(_ + 100)
     .pipe(Some(_)) 
}

calculate(100) // returns Some(200)

Pipe + Tap example

def calculate(value: Int) = {
     value
     .tap(println)
     .pipe(_ + 100)
     .tap(println)
     .pipe(Some(_))
     .tap(println)
}

calculate(100) 
/* 
returns Some(200)
prints:
100
200
Some(200)
*/

Scala's chaining utils provide a powerful and efficient way to streamline code by enabling the use of tap and pipe methods. By leveraging these methods, developers can optimize their functional code, enhance readability, and improve overall productivity.

val collection = Map.empty[Int, Int]

// unsafe way that will throw an exception if key is not present
val value = collection(1)

// safe way
val valueOpt = collection.get(1) match {
    case Some(value) => // key is present
    case None => // key is not present
}

In Scala, object references can have a value of null. That makes them unsafe. Bugs, that are related to unsafe calls, are very hard to detect. Luckily, the Option class can help to handle them for free:

var mutableRef: Car = null
Option(mutableRef) match {
    case Some(value) => // non-null
    case None => // null
}

This also lets us use Option composition to make safe calls:

class Car() {
    val width: Int = 100
}

var mutableRef: Car = null

// unsafe way that will throw an exception if mutableRef is null
val carWidth = mutableRef.width

// safe way
val carWidthOpt = Option(mutableRef).map(_.width)

Scala's Option class provides a powerful way to handle null values and safeguard collections and object references, minimizing the risk of bugs related to unsafe calls. By utilizing Option composition, developers can create more robust and maintainable code, ensuring a safer and more efficient development experience.

We can define a case class and then use it conveniently in the code:

import scala.collection.mutable

case class MyFeature(a: Int, b: Int, c: Int, d: Int)

object Solution extends App {
  val feature = MyFeature(1,2,3,4)
  val queue = mutable.Queue.empty[MyFeature]
  queue.enqueue(feature)
  while(queue.nonEmpty) {
    queue.dequeue() match {
      case MyFeature(_,b,_,_) => // do something with B
    }
  }
}

The problem starts when we have to deal with model evolution. What if we need to add a new parameter to MyFeature and update the case class definition to MyFeature(a: Int, b: Int, c: Int, d: Int, e: Int)

If we launch our code as is, Scala will start to complain:

Wrong number of arguments for the extractor, found: 4, expected: 5

It means that you will have to find all places in the codebase where the built-in MyFeature extractor has been used and fix all of them.

case MyFeature(_,b,_,_,e) => ...

First, let's implement a custom extractor

object BParameter {
  def unapply(f: MyFeature): Option[Int] = {
    Some(f.b)
  }
}

Refactor the original loop with our new extractor

while(queue.nonEmpty) {
  queue.dequeue() match {
    case BParameter(b) => // do something with B
  }
}

This code will not depend on MyFeature extensions. Additionally, you can define many unapply methods with different parameters to extract the same type of objects from different classes.

In conclusion, while Scala's case classes provide built-in extractors for convenience, they can become problematic when dealing with model evolution. To avoid issues, consider implementing custom extractors, which offer more flexibility and adaptability as your case class evolves.