Why Go’s 8‑Year Debate Over Short Function Literals Still Matters

When writing Go code, developers often use sort.Slice with an explicit comparison function, repeating the parameter types even though the compiler can infer them, which many find noisy.

Where the problem lies

In a typical sort.Slice call, the function signature func(i, j int) bool repeats the types of i and j despite the compiler's ability to infer them. Other languages allow more concise lambda syntax, e.g. (i, j) => i < j.

After Go 1.18 introduced generics, higher‑order functions like slices.SortFunc, maps.Keys, and iterator adapters became common, making verbose function literals a daily friction point.

Eight years of debate in three phases

Phase 1 (2017–2020): Do we really need this?

The proposal was initially met with indifference. Core contributor Dave Cheney warned, “Please no, clear is better than clever,” emphasizing Go’s philosophy of explicit over implicit.

Phase 2 (2020–2023): Syntax explosion

With generics in Go 1.18, the need for concise literals surged, spawning dozens of syntax proposals, such as arrow syntax ( (x, y) => x < y), Haskell‑style ( \(x, y) x < y), and a Rust‑like fn keyword.

// Arrow syntax (JavaScript style)
(x, y) => x < y

// Haskell style
\(x, y) x < y

// fn keyword (Rust style)
fn(x, y) { return x < y }

Phase 3 (2024‑present): Convergence

In June 2024, Robert Griesemer formed a small working group and set three constraints:

Core benefit: omit parameter type annotations. Parameters must be wrapped in some form of parentheses. Parameters cannot be moved into the function body to preserve existing code structure.

Under these constraints, the most popular proposal is the fn keyword syntax:

// fn keyword + type inference
sort.Slice(people, fn(i, j) bool { return people[i].Age < people[j].Age })

// Expression body (shortest form)
sort.Slice(people, fn(i, j) => people[i].Age < people[j].Age)

Why the decision is hard

The core tension is between brevity and readability: how concise can code be before it becomes obscure? Every new syntax feature adds learning, maintenance, and tooling costs.

Learning cost: new syntax rules for newcomers.

Maintenance cost: language spec must cover edge cases.

Tooling cost: compilers, IDEs, and static analysis tools need updates.

For example, Go 1.23’s iterator feature makes function literals even more common. With short literals, the same logic can be written more compactly, but it may be less clear to beginners.

// Current Go (runnable code)
for k, v := range slices.Sorted(func(yield func(string, int) bool) {
    for k, v := range m {
        yield(k, v)
    }
}) {
    fmt.Println(k, v)
}

// With short literals
for k, v := range slices.Sorted(fn(yield) { for k, v := range m { yield(k, v) } }) {
    fmt.Println(k, v)
}

What’s next

As of early 2026 the proposal remains open, but the opposition has largely lost the core argument. If Go 1.27 ships with short function literals, it would be the most significant syntactic change since generics.

Summary

Issue #21498 has been open since 2017 with over 900 comments, the longest syntax debate in Go history.

The core issue: Go forces explicit type annotations even when the compiler can infer them.

The community is converging on fn(params) or \(params) syntax.

Go’s team stresses that brevity must not sacrifice readability.

A final proposal may land in 2026; keep an eye on issue #21498.