DEV Community: Kyle Grah

🐹 Series: Leetcoding in Go — slices.Backward()

Kyle Grah — Wed, 14 May 2025 00:59:23 +0000

As Go engineers, we take pride in the language and our experience with it. Yet, many Go developers default to Python in technical interviews, often believing it's more interview-friendly.

But if you're applying to a Go-heavy team, there's no better way to win over your future coworkers than by showing you're fluent in Go — even under pressure.

There's a common perception that interviewing in Go puts you at a disadvantage compared to interviewing in Python. Python has built-ins such as reversed()—great for saving time and lines of code.

slices.Backward(): https://pkg.go.dev/slices#Backward (introduced in 1.23)

The following is a valid solution to leetcode 347: https://leetcode.com/problems/top-k-frequent-elements/description/

This solution:

Tracks frequencies in a single map pass
Groups numbers into frequency “buckets”
Uses slices.Backward() to iterate from highest frequency down
Stops early once k results are collected

import "slices"

func topKFrequent(nums []int, k int) []int {
    frequencies := make(map[int]int)

    for _, n := range nums {
        frequencies[n]++
    }

    buckets := make([][]int, len(nums)+1)
    for n, freq := range frequencies {
        buckets[freq] = append(buckets[freq], n)
    }

    results := make([]int, 0, k) 

// Reverse-iterate the buckets slice. Comparable to Python's reversed.
    for _, b := range slices.Backward(buckets) {
        if len(results) == k {
            return results
        }

        if len(b) <= k-len(results) {
            results = append(results, b...)
        } else {
            results = append(results, b[:k-len(results)]...)
        }
    }

    return results
}

Compared to for i := len(nums) - 1; i >= 0; i-- {}, using slices.Backward() is easier to read, more expressive of intent, and shows fluency with Go’s modern standard library.

🐹 Series: Leetcoding in Go — slices.Backward()

Kyle Grah — Wed, 14 May 2025 00:59:23 +0000

As Go engineers, we take pride in the language and our experience with it. Yet, many Go developers default to Python in technical interviews, often believing it's more interview-friendly.

But if you're applying to a Go-heavy team, there's no better way to win over your future coworkers than by showing you're fluent in Go — even under pressure.

There's a common perception that interviewing in Go puts you at a disadvantage compared to interviewing in Python. Python has built-ins such as reversed()—great for saving time and lines of code.

slices.Backward(): https://pkg.go.dev/slices#Backward (introduced in 1.23)

The following is a valid solution to leetcode 347: https://leetcode.com/problems/top-k-frequent-elements/description/

This solution:

Tracks frequencies in a single map pass
Groups numbers into frequency “buckets”
Uses slices.Backward() to iterate from highest frequency down
Stops early once k results are collected

import "slices"

func topKFrequent(nums []int, k int) []int {
    frequencies := make(map[int]int)

    for _, n := range nums {
        frequencies[n]++
    }

    buckets := make([][]int, len(nums)+1)
    for n, freq := range frequencies {
        buckets[freq] = append(buckets[freq], n)
    }

    results := make([]int, 0, k) 

// Reverse-iterate the buckets slice. Comparable to Python's reversed.
    for _, b := range slices.Backward(buckets) {
        if len(results) == k {
            return results
        }

        if len(b) <= k-len(results) {
            results = append(results, b...)
        } else {
            results = append(results, b[:k-len(results)]...)
        }
    }

    return results
}

Compared to for i := len(nums) - 1; i >= 0; i-- {}, using slices.Backward() is easier to read, more expressive of intent, and shows fluency with Go’s modern standard library.

🐹 Series: Leetcoding in Go — slices.Backward()

Kyle Grah — Wed, 14 May 2025 00:59:23 +0000

As Go engineers, we take pride in the language and our experience with it. Yet, many Go developers default to Python in technical interviews, often believing it's more interview-friendly.

But if you're applying to a Go-heavy team, there's no better way to win over your future coworkers than by showing you're fluent in Go — even under pressure.

There's a common perception that interviewing in Go puts you at a disadvantage compared to interviewing in Python. Python has built-ins such as reversed()—great for saving time and lines of code.

slices.Backward(): https://pkg.go.dev/slices#Backward (introduced in 1.23)

The following is a valid solution to leetcode 347: https://leetcode.com/problems/top-k-frequent-elements/description/

This solution:

Tracks frequencies in a single map pass
Groups numbers into frequency “buckets”
Uses slices.Backward() to iterate from highest frequency down
Stops early once k results are collected

import "slices"

func topKFrequent(nums []int, k int) []int {
    frequencies := make(map[int]int)

    for _, n := range nums {
        frequencies[n]++
    }

    buckets := make([][]int, len(nums)+1)
    for n, freq := range frequencies {
        buckets[freq] = append(buckets[freq], n)
    }

    results := make([]int, 0, k) 

// Reverse-iterate the buckets slice. Comparable to Python's reversed.
    for _, b := range slices.Backward(buckets) {
        if len(results) == k {
            return results
        }

        if len(b) <= k-len(results) {
            results = append(results, b...)
        } else {
            results = append(results, b[:k-len(results)]...)
        }
    }

    return results
}

Compared to for i := len(nums) - 1; i >= 0; i-- {}, using slices.Backward() is easier to read, more expressive of intent, and shows fluency with Go’s modern standard library.

Stop OOMs with Semaphores

Kyle Grah — Mon, 12 May 2025 23:32:08 +0000

Go makes it easy to write concurrent code — just add go doSomething() and you're off. But if you're not careful, you can overwhelm your own service with too many goroutines. Here's how to avoid accidentally DDoSing yourself using a simple, effective semaphore.

Semaphore is a concurrency pattern that has existed long before Go did, but is exceptionally easy to implement with Go’s channels.

There are many use cases for semaphores in computer science, but one of the most practical in Go is limiting the number of goroutines your program spawns.

Goroutines are cheap but not free. Unbounded goroutines can lead to degraded performance due to CPU contention, runaway memory usage (heap and stack), and even goroutine leaks — where goroutines silently keep running forever.

Example:
The following code snippet was adapted from go-chi: https://github.com/go-chi/chi. It creates a simple web server with one http endpoint to process large files provided as multipart requests, and uses a semaphore to limit global concurrency, ensuring the service never processes more than a fixed number of files at once — regardless of how many users hit the endpoint.

func main() {
    maxGoroutinesEnv := os.Getenv("MAX_GOROUTINES")
    maxGoroutines, err := strconv.Atoi(maxGoroutinesEnv)
    if err != nil {
        log.Fatalf("failed to load MAX_GOROUTINES env var %w", err)
    }

    // create semaphore
    sem := NewSemaphore(maxGoroutines)

    r := chi.NewRouter()
    r.Use(middleware.Logger)
    r.Get("/", func(w http.ResponseWriter, r *http.Request) {
        processListOfLargeCustomerProvidedConfigs(w, r, sem)
    })
    http.ListenAndServe(":3000", r)
}

func processListOfLargeCustomerProvidedConfigs(
    w http.ResponseWriter,
    r *http.Request,
    sem *Semaphore,
) {
    err := r.ParseMultipartForm(50 << 20)
    if err != nil {
        errMsg := fmt.Sprintf("could not parse multipart form: %w", err)
        http.Error(w, errMsg, http.StatusBadRequest)
        return
    }

    files := r.MultipartForm.File["configs"]
    if len(files) == 0 {
        http.Error(w, "no files in request", http.StatusBadRequest)
        return
    }

    for _, f := range files {
        // blocks if the semaphore is "full"
        sem.Acquire(1)

        go func(f *multipart.FileHeader) {
            defer sem.Release(1)
            // memory and cpu intensive task
            processFile(f)
        }(f)
    }
}

As you can see above, every time we attempt to create a goroutine to process a file, we block if the semaphore is "full" and automatically continue once a piece of work has been released.

A Minimal Semaphore Implementation:
Here’s the full implementation used in the example:

type Semaphore struct {
    c chan struct{}
}

func NewSemaphore(w int) *Semaphore {
    return &Semaphore{
        // create a buffered channel with capacity
       // equal to the weight of the semaphore
        c: make(chan struct{}, w),
    }
}

func (s *Semaphore) Acquire(w int) {
    for range w {
        // Send an empty struct to the channel.
        // Blocks if the channel is full — meaning we've  reached our   concurrency limit.
        // We use `struct{}` to avoid extra allocations.
        s.c <- struct{}{}
    }
}

func (s *Semaphore) Release(w int) {
        // pull the desired amount of work
        // out of the semaphore channel
    for range w {
        <-s.c
    }
}

📦 Prefer a Library?
And if you want to get a semaphore up and running even faster, you can find one here: https://pkg.go.dev/golang.org/x/sync/semaphore

Stop OOMs with Semaphores

Kyle Grah — Mon, 12 May 2025 23:32:08 +0000

Semaphore is a concurrency pattern that has existed long before Go did, but is exceptionally easy to implement with Go’s channels.

There are many use cases for semaphores in computer science, but one of the most practical in Go is limiting the number of goroutines your program spawns.

func main() {
    maxGoroutinesEnv := os.Getenv("MAX_GOROUTINES")
    maxGoroutines, err := strconv.Atoi(maxGoroutinesEnv)
    if err != nil {
        log.Fatalf("failed to load MAX_GOROUTINES env var %w", err)
    }

    // create semaphore
    sem := NewSemaphore(maxGoroutines)

    r := chi.NewRouter()
    r.Use(middleware.Logger)
    r.Get("/", func(w http.ResponseWriter, r *http.Request) {
        processListOfLargeCustomerProvidedConfigs(w, r, sem)
    })
    http.ListenAndServe(":3000", r)
}

func processListOfLargeCustomerProvidedConfigs(
    w http.ResponseWriter,
    r *http.Request,
    sem *Semaphore,
) {
    err := r.ParseMultipartForm(50 << 20)
    if err != nil {
        errMsg := fmt.Sprintf("could not parse multipart form: %w", err)
        http.Error(w, errMsg, http.StatusBadRequest)
        return
    }

    files := r.MultipartForm.File["configs"]
    if len(files) == 0 {
        http.Error(w, "no files in request", http.StatusBadRequest)
        return
    }

    for _, f := range files {
        // blocks if the semaphore is "full"
        sem.Acquire(1)

        go func(f *multipart.FileHeader) {
            defer sem.Release(1)
            // memory and cpu intensive task
            processFile(f)
        }(f)
    }
}

As you can see above, every time we attempt to create a goroutine to process a file, we block if the semaphore is "full" and automatically continue once a piece of work has been released.

A Minimal Semaphore Implementation:
Here’s the full implementation used in the example:

type Semaphore struct {
    c chan struct{}
}

func NewSemaphore(w int) *Semaphore {
    return &Semaphore{
        // create a buffered channel with capacity
       // equal to the weight of the semaphore
        c: make(chan struct{}, w),
    }
}

func (s *Semaphore) Acquire(w int) {
    for range w {
        // Send an empty struct to the channel.
        // Blocks if the channel is full — meaning we've  reached our   concurrency limit.
        // We use `struct{}` to avoid extra allocations.
        s.c <- struct{}{}
    }
}

func (s *Semaphore) Release(w int) {
        // pull the desired amount of work
        // out of the semaphore channel
    for range w {
        <-s.c
    }
}

📦 Prefer a Library?
And if you want to get a semaphore up and running even faster, you can find one here: https://pkg.go.dev/golang.org/x/sync/semaphore