Golang Closures and Anonymous Functions, with Examples

Anonymous functions

A function literal is a function without a name. It is an expression, so it can go anywhere a value can: a variable, an argument, a return value, a struct field.

package main

import (
	"fmt"
	"slices"
	"strings"
)

func main() {
	double := func(n int) int { return n * 2 }
	fmt.Println(double(21))

	// Call immediately.
	func(msg string) {
		fmt.Println("now:", msg)
	}("hello")

	// Pass inline as an argument.
	words := []string{"banana", "Apple", "cherry"}
	slices.SortFunc(words, func(a, b string) int {
		return strings.Compare(strings.ToLower(a), strings.ToLower(b))
	})
	fmt.Println(words)
}

Go has no arrow or lambda shorthand. The full func(params) results { body } form is the only way to write one.

Capturing variables

A function literal can use variables from the enclosing function. It does not copy them: the closure and the surrounding code share one variable.

package main

import "fmt"

func main() {
	count := 0
	inc := func() {
		count++
	}

	inc()
	inc()
	fmt.Println(count) // 2: the closure changed the outer variable

	count = 10
	inc()
	fmt.Println(count) // 11: and it sees outside changes too
}

The captured variable lives as long as some closure still refers to it, even after the function that declared it has returned. The compiler moves it to the heap when needed; you never manage that yourself.

Generators and counters

Returning a closure from a function gives each returned function its own private state.

package main

import "fmt"

func counter() func() int {
	n := 0
	return func() int {
		n++
		return n
	}
}

func fibonacci() func() int {
	a, b := 0, 1
	return func() int {
		r := a
		a, b = b, a+b
		return r
	}
}

func main() {
	c1 := counter()
	c2 := counter()
	fmt.Println(c1(), c1(), c1()) // 1 2 3
	fmt.Println(c2())             // 1: separate n

	fib := fibonacci()
	for range 10 {
		fmt.Print(fib(), " ")
	}
	fmt.Println()
}

Each call to counter() creates a new n, so c1 and c2 count independently. Nothing outside can read or reset n, which makes this a small form of encapsulation.

Closures in loops (Go 1.22 and later)

Before Go 1.22, a for loop had one loop variable for the whole loop. Closures created inside it all captured that single variable and saw its final value. That was the most common closure bug in Go.

Since Go 1.22, each iteration gets its own copy, so the code below prints 0 1 2:

package main

import "fmt"

func main() {
	var funcs []func()
	for i := range 3 {
		funcs = append(funcs, func() { fmt.Print(i, " ") })
	}
	for _, f := range funcs {
		f()
	}
	fmt.Println()
}

Under Go 1.21 and earlier, the same loop written as for i := 0; i < 3; i++ (range over an integer is also new in 1.22) printed 3 3 3. The new rule applies per module, based on the go line in go.mod, so an old module still gets the old behavior until its go line is raised to 1.22 or later. You will still see i := i or v := v inside loops in older code: it was the manual fix and is now redundant.

The per-iteration rule covers only variables declared by the for statement itself. A variable declared before the loop and updated in the body is still one shared variable:

var last string
for _, s := range items {
	last = s
	handlers = append(handlers, func() { use(last) }) // every closure sees the final value
}

Closures and goroutines

A goroutine started with a function literal is a closure too. The same sharing rules apply, plus the usual concurrency rule: if several goroutines write a captured variable, you need a mutex or a channel.

package main

import (
	"fmt"
	"sync"
)

func main() {
	var (
		mu    sync.Mutex
		wg    sync.WaitGroup
		total int
	)
	for i := 1; i <= 100; i++ {
		wg.Add(1)
		go func() {
			defer wg.Done()
			mu.Lock()
			total += i
			mu.Unlock()
		}()
	}
	wg.Wait()
	fmt.Println(total)
}

This always prints 5050. Each goroutine reads its own i (Go 1.22 loop semantics) and writes the shared total under a lock. Remove the mutex and the result becomes unpredictable; go run -race reports it as a data race. See goroutines for WaitGroup and the race detector.

Where closures show up in real code

• Sorting and searching: slices.SortFunc, slices.IndexFunc, sort.Slice all take a function literal.
• Deferred cleanup: defer func() { ... }() runs a block at function exit and can read the function's variables. See defer.
• HTTP middleware: a function that takes a handler and returns a new http.HandlerFunc literal that wraps it.
• Configuration: functional options (func WithTimeout(d time.Duration) Option { return func(c *Config) { c.Timeout = d } }) are closures over the argument.

A middleware example that captures both a parameter and a counter:

package main

import (
	"fmt"
	"strings"
)

type Handler func(string) string

func withLogging(name string, next Handler) Handler {
	calls := 0
	return func(in string) string {
		calls++
		out := next(in)
		fmt.Printf("%s call #%d: %q -> %q\n", name, calls, in, out)
		return out
	}
}

func main() {
	upper := withLogging("upper", strings.ToUpper)
	upper("go")
	upper("closures")
}

Common mistakes

• Expecting a snapshot. A closure reads the variable's current value when it runs, not the value when the closure was created. Pass the value as a parameter if you need a snapshot: go func(v int) { ... }(x).
• Recursive literals. A function literal cannot refer to itself by the variable it is being assigned to in the same :=. Declare the variable first: var walk func(n int); walk = func(n int) { ... walk(n-1) }.
• Unsynchronized writes from goroutines. Capturing is not synchronization. Guard shared writes.