Forem: Harutyun Mardirossian

Anti-pattern: Overwriting return value inside defer

Harutyun Mardirossian — Wed, 09 Jul 2025 15:08:16 +0000

Over the years, I have observed numerous examples of code overriding the return value within a defer statement. This pattern is quite common in my professional experience. In almost every project I have been involved in, I have encountered this exact scenario at some point.


func doSomething() error {
    return errors.New("something went wrong")
}

func doSomethingElse() error {
    return errors.New("something else went wrong")
}

func run() (err error) {
    defer func() {
        err = doSomethingElse()
    }()

    if err = doSomething(); err != nil {
        return err
    }

    return nil
}

Many believe that the f.run() function will return errors.New(“something went wrong”), as the err = doSomethingElse() is considered the "root cause" of the error. However, the actual output of this function is errors.New(“something else went wrong”) and here's why.

The f.run() function returns a named parameter err (Result Parameter) that is overwritten within the defer statement. This approach is intended to stop the program’s execution if the defer statement fails. While this may appear to be a clever solution, it can result in unexpected behavior and introduce bugs into the code.

The first time I encountered this issue was while debugging a pool of workers that were randomly causing invalid memory address or nil pointer dereference. My team and I were relatively new to Go. It was my first year after switching from PHP, and it took almost a week to identify the root cause of the problem.

A few days ago, I came across a similar concept in my ongoing project. I posted a question on LinkedIn to understand how many people are aware of this anti-pattern. This pattern can lead to unexpected behavior and bugs in the code.

The Core Mechanism

In the function signature func run() (err error), the variable err is a result parameter. According to the Go specification:

It is declared and initialized to its zero value (nil for error types) upon entry to the function.
It is treated like any other local variable within the function body. You can read from it and assign to it.
Crucially, if the function executes a return statement without arguments (a "naked" return), the current value of the result parameter is what's returned.

When function returns err, it's explicitly returning the current value of this specific variable. This variable err lives in the function's stack frame and acts as the designated memory location for the return value.

Let's trace the execution of f.run() step-by-step.

func run() (err error) {                                // Step 1
    defer func() {                                              // Step 2
        err = doSomethingElse()
    }()

    if err = doSomething(); err != nil {    // Step 3
        return err                                                  // Step 4
    }

    return nil
}

STEP 1: The run function is called and the result parameter err is declared and initialized within function's stack frame. Its initial value is nil and is part of this frame.

+------------------------------------+
| run() Stack Frame                  |
+------------------------------------+
| err (Result Parameter): nil        | <-- the return slot
+------------------------------------+

STEP 2: The defer statement compiles into a closure. The closure captures a reference to the err variable. This closure is then pushed onto a per-goroutine stack of deferred calls.

STEP 3: The expression err = doSomething() is executed. The error value is assigned to the result parameter err. The value of err in the stack frame is now errors.New("something went wrong").

+------------------------------------+
| run() Stack Frame                  |
+------------------------------------+
| err (Result Parameter): "err_A"    | <-- "something went wrong"
+------------------------------------+

STEP 4: In this step things are getting complicated. The return statement triggers a two-phase process:

The return expression is evaluated and locks in its current value as the value to be used for the return. errors.New("something went wrong") for now.
Before the function f.run() officially returns control to f.main(), the runtime executes any deferred calls in LIFO order. Inside the closure, the statement err = doSomethingElse() is run. Because the closure holds a reference to the result parameter err, this assignment overwrites the value in f.run()'s stack frame. The value of the result parameter err is now errors.New("something else went wrong").

+------------------------------------+
| run() Stack Frame                  |
|                                    |
|   +----------------------------+   |
|   | defer() closure executing  |   |
|   |                            |   |
|   | err = doSomethingElse()    | --+-\
|   +----------------------------+   | |
|                                    | |
| err (Result Parameter): "err_A"    | | <-- overwrites err
+------------------------------------+ |
                                       |
<--------------------------------------+

When defer completes the value of the result parameter err is overwritten.

+------------------------------------+
| run() Stack Frame                  |
+------------------------------------+
| err (Result Parameter): "err_B"    | <-- "something else went wrong"
+------------------------------------+

The function now completes its return sequence, returning the current value from the err slot. The value returned is "err_B" or "something else went wrong".

The Danger

At this point, you might ask a question: "But I don't see anything wrong here." Perhaps, if you have noticed the danger, my congratulations. Let’s have a beer together.

Let’s take a look at the scenario I faced five years ago and explore the reasons behind the week-long debugging process during my junior year.

A pool of parallel workers processing a huge file containing a list of JSON parameters. The idea was simple: read -> unmarshal into struct -> notify -> return the result in a channel.

The f.notify function was responsible for sending a message to Kafka. The f.process() function itself was executed by the worker.

func process() (result SomeType, err error) {
    defer func {
        err = notify()
    }()

    res, err := readAndUnmarshal()
    if err != nil {
        return
    }

    return
}

func worker(resChan chan SomeOtherType) {
    res, err := process()
    if err != nil {
        resChan <- SomeOtherType{Err: err}
    }
    resChan <- SomeOtherType{Result: res}
}

We were not provided with the exact content of the JSON file we were reading. Instead, we were given a small chunk, which were used to construct our result struct. The JSON keys may contain invalid values. For example, instead of an object, there might be a number. This will result in the unmarshaling failing, and an error will be returned.

res, err := readAndUnmarshal()
if err != nil {
    return   // this return well be triggered
}

This return statement will initiate the deferred closure’s execution. The f.notify() will be executed, overriding the error returned by the f.readAndUnmarshal() function with nil. The return value of the f.process() function when f.readAndUnmarshal() fails will be nil, nil. The worker will then push a nil value to the channel SomeOtherType{Result: nil}.

In the runtime, when accessing the field within the result of f.worker(), the program will cause a panic.

// panic: runtime error: invalid memory address or nil pointer dereference
value := msg.Result.SomeField

The defer block completely broke the error path of the program. The required object was not initialized but was still returned. This error required a significant amount of time and effort to identify and rectify. Even experienced developers overlooked this error. I was able to reproduce this error by accidentally passing an empty JSON to be parsed.

Honestly, I have no idea what the workers initially wrote in such a way. I also don't know the intention behind this design decision. The project was handed over in the ready-to-production state. Even unit tests were written in a way that f.notify() guaranteed to fail, and this case was never tested.

Unnamed return value scenario

Let's also discuss the case when a function returns a local variable as an error. Here, the f.run() function will return errors.New(“something went wrong”).

func doSomething() error {
    return errors.New("something went wrong")
}

func doSomethingElse() error {
    return errors.New("something else went wrong")
}

func run() error {
    var err error // error is a local variable this time

    defer func() {
        err = doSomethingElse()
    }()

    if err = doSomething(); err != nil {
        return err
    }

    return nil
}

In this scenario, when f.run() is called and A stack frame is created. It contains a slot for the local variable err and a separate, anonymous slot for the return value.

+------------------------------------+
| run() Stack Frame                  |
+------------------------------------+
| __return_value_0 (hidden): nil     | <-- return slot
| err (local variable):     nil      | <-- local variable
+------------------------------------+

After executing err = doSomething() the local err variable is updated.

+------------------------------------+
| run() Stack Frame                  |
+------------------------------------+
| __return_value_0 (hidden): nil     |
| err (local variable):     "err_A"  | <-- "something went wrong"
+------------------------------------+

At this point return is triggeted. This is the most important difference. The copy the value of the local err variable into the hidden return slot." This action happens before the defer is executed.

+------------------------------------+
| run() Stack Frame                  |
+------------------------------------+
| __return_value_0 (hidden): "err_A" | <-- RETURN VALUE IS NOW LOCKED IN
| err (local variable):      "err_A" |
+------------------------------------+

The deferred closure runs. It has a reference to the local err variable, not the hidden return slot.

+------------------------------------+
| run() Stack Frame                  |
+------------------------------------+
| __return_value_0 (hidden): "err_A" | <-- Unchanged
| err (local variable):      "err_B" | <-- Overwritten
+------------------------------------+

The function returns the value from its hidden return slot. The value returned is "err_A".

The return mechanism in Go is more complex because defer and named return values create a multi-step process that gives the programmer explicit control over the function's exit logic. This explicit two-phase process is a distinguishing feature of Go. In other languages, the process is more opaque. When a return is hit in a try block, the language runtime knows a finally block must run, but the interaction with the return value itself is often less defined and considered an anti-pattern to exploit.

Contexts: To Cancel or Not to Cancel

Harutyun Mardirossian — Mon, 09 Jun 2025 07:26:24 +0000

In Go, the context package provides a mechanism to propagate cancellation signals, deadlines, and request-scoped values across API boundaries and goroutines. It enables graceful termination of operations by allowing parent operations to cancel child operations. This prevents goroutine leaks and ensures resources are cleaned up efficiently when work is no longer needed.

To shut down a chain of goroutines using context in Go, you create a cancelable context that propagates cancellation signals through the chain. Each goroutine monitors ctx.Done() to exit cleanly when cancellation is requested.

Each caller must be able to cancel its callee, use context derivation and hierarchical cancellation. Each function creates a cancellable context for its callee, enabling independent cancellation at any level.

func A(ctx context.Context) {
    // Create child context for B (cancels when A exits or manually cancelled)
    ctxA, cancelA := context.WithCancel(ctx)
    defer cancelA() // Cancel B when A exits

...

func B(ctx context.Context) {
    // Create child context for C
    ctxB, cancelB := context.WithCancel(ctx)
    defer cancelB() // Cancel C when B exits

Hierarchy Creation:

main → A with ctx
A → B with ctxA (child of ctx)
B → C with ctxB (child of ctxA)

The code below demonstrates hierarchical cancellation of goroutines using Go's context package.

package main

import (
    "context"
    "fmt"
    "time"
)

func A(ctx context.Context) {
    // Create child context for B (cancels when A exits or manually canceled)
    ctxA, cancelA := context.WithCancel(ctx)
    defer cancelA() // Cancel B when A exits

    go B(ctxA) // Start B (no need to track separately)

    // A's work
    for i := 0; ; i++ {
        select {
        case <-ctx.Done(): // Main cancelled us
            fmt.Println("A: shutdown signal received")
            return
        case <-time.After(500 * time.Millisecond):
            fmt.Println("A: working", i)

            // Example: A decides to cancel B after 3 iterations
            if i == 2 {
                fmt.Println("A: manually cancelling B")
                cancelA() // Cancel only B (not A itself)
            }
        }
    }
}

func B(ctx context.Context) {
    // Create child context for C
    ctxB, cancelB := context.WithCancel(ctx)
    defer cancelB() // Cancel C when B exits

    go C(ctxB) // Start C

    // B's work
    for i := 0; ; i++ {
        select {
        case <-ctx.Done(): // A cancelled us
            fmt.Println("B: shutdown signal received")
            return
        case <-time.After(500 * time.Millisecond):
            fmt.Println("B: working", i)
        }
    }
}

func C(ctx context.Context) {
    // C's work
    for i := 0; ; i++ {
        select {
        case <-ctx.Done(): // B cancelled us
            fmt.Println("C: shutdown signal received")
            return
        case <-time.After(500 * time.Millisecond):
            fmt.Println("C: working", i)
        }
    }
}

func main() {
    ctx, cancel := context.WithCancel(context.Background())
    go A(ctx) // Start chain

    // Let run for 5 seconds
    time.Sleep(5 * time.Second)
    fmt.Println("\nmain: cancelling entire chain")
    cancel() // Cancel everything

    // Allow time for shutdown messages
    time.Sleep(500 * time.Millisecond)
}

A explicitly cancels B after 3 iterations using its cancel function (cancelA), which automatically propagates to C since C's context is derived from B's. Meanwhile, the main function cancels the entire chain after 5 seconds by calling its root cancel function, which propagates downward through all derived contexts.

Each function monitors its own context's Done() channel, allowing immediate termination when cancellation occurs. The defer cancel() statements ensure child contexts are always properly cancelled when parents exit, preventing goroutine leaks. The output shows work progress interleaved with shutdown messages, demonstrating both targeted cancellation (A→B) and full-chain cancellation (main→A→B→C).

My Everyday Tools

Harutyun Mardirossian — Sun, 17 Nov 2024 13:33:56 +0000

A craftsman is known by his tools.
Jean de La Fontaine, a 17th-century French fabulist and poet

As a software engineer navigating the ever-evolving landscape of development, having a reliable toolchain is crucial to staying efficient and maintaining high-quality code. Over the years, I’ve curated a set of tools that streamline my workflow, from coding and testing to deployment and monitoring. Each tool in my arsenal serves a distinct purpose, and together, they form a cohesive ecosystem that boosts productivity while tackling complex projects. I’ll dive into the tools that shape my daily workflow as a developer, focusing on three key areas: my terminal setup, the TUI applications I rely on, and the desktop applications that streamline my tasks.

Apps

1. iTerm2 https://iterm2.com

iTerm2 is my terminal of choice because it combines power, flexibility, and convenience, making it indispensable for my workflow.

For someone who spends a lot of time on the command line, iTerm2 strikes the ideal balance between performance and user-centric features, which is why it remains my go-to terminal. Here are some of its key features I really like:

Split Panes: Divide your terminal window into multiple panes, allowing you to run several sessions simultaneously within a single window.
Hotkey Window: Access a terminal window instantly from any application using a customizable keyboard shortcut.
Search Functionality: Perform on-page searches with immediate highlighting of matches, including support for regular expressions.
Paste History: Access a history of copied or pasted text, with options to save this history to disk for future reference.
Instant Replay: Rewind the terminal display to view past outputs, even if they've been overwritten or cleared.
Triggers: Set up actions that execute when specific text patterns appear, such as highlighting keywords or sending notifications.

2. Boop https://github.com/IvanMathy/Boop

Boop is a free, open-source macOS application designed to simplify text manipulation tasks for developers.

It offers a straightforward interface where users can paste text and apply various operations, such as decoding URLs, formatting JSON, or converting data formats. Boop supports custom scripts, allowing users to extend its functionality to meet specific needs. By handling text processing locally, it enhances efficiency and security, eliminating the need to use online tools for these tasks. Boop offers a clean, minimalist interface where users can paste text and apply transformations with ease.

3. Zed https://zed.dev

As a developer who’s deeply passionate about Rust and its potential, I couldn’t be more excited about Zed, the new high-performance code editor built entirely in Rust.

The creators of Atom and Tree-sitter have truly outdone themselves, crafting an editor that isn’t just fast, it’s lightning fast, leveraging multi-core CPUs and GPUs to redefine responsiveness. Zed’s real-time collaborative editing, or "multiplayer" mode, feels like the future of pair programming, seamlessly blending human collaboration with AI-powered code assistance. Features like multibuffers and inline evaluation take productivity to new heights, offering intuitive ways to navigate and edit sprawling codebases. The extensibility powered by Tree-sitter and WebAssembly is a dream for developers who love tinkering. For me, Zed represents everything I admire about Rust: speed, safety, and a focus on engineering excellence. It’s more than an editor; it’s a glimpse into the future of coding.

4. Obsidian http://obsidian.md

Obsidian has become an indispensable tool for me, serving as both a note-taking powerhouse and my go-to platform for writing articles.

Built on Markdown files, it allows me to create, edit, and link notes seamlessly, creating a network of interconnected ideas that I can visualize through its interactive graph view. This non-linear approach is perfect for organizing thoughts and exploring relationships between concepts.

Key features like local storage ensure my notes are private and accessible offline, while its extensive customization options, including themes and plugins, let me tailor the app to fit my unique workflow. The active community around Obsidian adds to its power, offering plugins and themes that continually enhance its functionality. With optional features like Obsidian Sync for cross-device synchronization and Obsidian Publish for sharing notes online, it’s a truly flexible platform. Every article I write starts here, in the robust and distraction-free environment Obsidian provides, making it a cornerstone of my creative and professional workflow.

Terminal tools

1. Ollama http://ollama.com

Ollama is a game-changer for developers, offering an always-accessible AI companion that runs entirely on your local machine.

With support for macOS, Linux, and Windows, it ensures data privacy while delivering the speed and flexibility developers need. Ollama's extensive library of large language models, including Llama and Mistral, can be seamlessly integrated into existing workflows thanks to its compatibility with the OpenAI Chat Completions API. Whether you need an AI to assist with coding, debugging, or brainstorming, Ollama is ready to work alongside you, on-demand, without relying on the cloud. Its ability to run locally makes it the perfect tool for privacy-conscious developers looking for a powerful yet customizable AI assistant. Some key features:

Local Execution: Ollama allows users to run LLMs directly on their machines, mitigating privacy concerns associated with cloud-based solutions and providing faster processing speeds.
Model Library: It provides access to a diverse collection of models, including Llama 3.2, Phi 3, Mistral, and Gemma 2, among others, allowing users to choose models that best fit their needs.
Customization: Users can customize and create their own models, tailoring them to specific tasks or preferences.

2. Oh my zsh https://ohmyz.sh

Oh My Zsh is a powerful, open-source framework that elevates the Z shell (Zsh) into a highly customizable and efficient command-line environment.

Designed to simplify the management of Zsh configurations, it boasts an extensive library of over 300 plugins and themes, making it an indispensable tool for developers and power users. With support for popular tools and languages like Git, Docker, and Python, Oh My Zsh streamlines workflows and boosts productivity. By combining flexibility with ease of use, Oh My Zsh empowers users to create a personalized terminal setup that is both functional and visually appealing. Whether you're optimizing your workflow or simply sprucing up your terminal, Oh My Zsh provides the perfect balance of form and function.

3. LazyDocker https://github.com/jesseduffield/lazydocker

Lazydocker is an open-source terminal user interface (TUI) that simplifies managing Docker and Docker Compose environments.

It provides a centralized interface where users can easily monitor and interact with containers, images, volumes, and networks. With features like real-time monitoring of logs and resource usage, container management tools for restarting or rebuilding services, and customizable commands, Lazydocker streamlines Docker workflows and enhances productivity. As a Go developer, I’m especially excited about Lazydocker because it showcases the power and versatility of Go in building practical, user-friendly tools that make everyday tasks more efficient and enjoyable. This tool is a perfect example of how Go can be leveraged to create something truly impactful for developers.

4 NuShell https://www.nushell.sh

Nushell is a modern, cross-platform shell that revolutionizes the command-line experience by introducing structured data handling and a rich programming language. Unlike traditional shells, Nushell processes data as typed tables, allowing seamless filtering, sorting, and transformations directly within the shell.

It supports various data formats, including JSON, YAML, and Excel, and features built-in commands for tasks like HTTP requests, directory navigation, and file manipulation. Designed for Linux, macOS, Windows, and BSD, Nushell offers a unified, extensible experience across platforms. What makes Nushell even more exciting is that it’s written in Rust.

5. Helix Editor https://helix-editor.com

Helix is the final tool I recommend, and as a Vim alternative with batteries included, it’s a game-changer for modern developers. Built in Rust, Helix brings the speed, safety, and efficiency Rust is known for to the world of text editing.

It features a modal editing interface, inspired by Vim and Kakoune, that feels intuitive yet powerful, while offering advanced capabilities right out of the box. With multiple selections for simultaneous editing, Tree-sitter integration for precise syntax highlighting, and robust Language Server Protocol (LSP) support for code completion and diagnostics, Helix eliminates the need for extensive configuration or plugins. If you’re looking for a sleek, modern editor that pairs Vim’s philosophy with built-in features for today’s workflows, Helix is a must-try.

Conclusion

I deliberately chose not to mention popular tools like VS Code, JetBrains, or mainstream database tools in this article. Instead, my focus was on highlighting processes and the lesser-known but equally powerful tools that often go unnoticed in the shadow of widespread hype. While those well-known tools are excellent, they’ve already had more than their share of attention on the web. My goal was to shine a light on the hidden gems that can truly enhance your workflow but might have been overlooked due to the overwhelming buzz surrounding the usual suspects. By exploring these alternatives, I hope to offer a fresh perspective and inspire you to discover tools that could revolutionize your approach to development.

Understanding sync.Cond in Go: Synchronizing Goroutines in Producer-Consumer Scenarios

Harutyun Mardirossian — Wed, 06 Nov 2024 07:51:17 +0000

In concurrent programming, synchronization is key to preventing data races and ensuring threads or goroutines operate in a coordinated manner. Imagine you have a problem to coordinate multiple producers and consumers accessing a shared resource, such as a buffer or queue. This classic concurrency challenge is known as the producer-consumer problem. In this scenario, synchronization is essential to ensure that producers do not overwrite data and consumers do not read invalid or stale data. Synchronisation is necessary, because without proper synchronization, simultaneous access to shared data can lead to race conditions, data corruption, or crashes. Producers need to wait if the buffer is full, and consumers need to wait if the buffer is empty. There might be scenarios where you have a bounded buffer with a fixed size, and you need to manage access to it among multiple producers and consumers.

What is `sync.Cond`?

sync.Cond in Go is a signaling mechanism that allows goroutines to wait until a specific condition is met. It’s particularly useful for coordinating complex workflows where some goroutines need to pause execution and wait until other goroutines complete certain actions. The ideas behind the sync.Cond are pretty simple and easy to understand:

Blocking: Goroutines can wait for a signal, pausing execution until notified.
Signaling: Other goroutines can signal waiting goroutines to proceed when a condition is met.
Efficiency: Reduces busy waiting by letting goroutines sleep until signaled.

How `sync.Cond` Works

sync.Cond Initialization: It requires a Locker, usually a sync.Mutex or sync.RWMutex, to control access. This Locker helps guard shared resources.
Wait(): When a goroutine calls Wait(), it:
- Releases the associated lock, allowing other goroutines to access the resource.
- Waits (blocks) until another goroutine signals it to continue.
Signal() and Broadcast():
- Signal() wakes up one waiting goroutine, allowing it to acquire the lock and continue.
- Broadcast() wakes up all waiting goroutines.

Problem: Producer-Consumer with Mutex and Condition Variable

Imagine you have a buffer (or queue) with a fixed size. Multiple producers generate items and add them to the buffer, while multiple consumers remove items from it. The challenge is to:

Ensure producers only add items if there’s space in the buffer.
Ensure consumers only remove items if the buffer is not empty.
Signal producers and consumers when they can add or remove items.

Here’s the initial code structure:

package main

import (
    "fmt"
    "sync"
    "time"
)

const bufferSize = 5

type Buffer struct {
    data []int
    mu   sync.Mutex
    cond *sync.Cond
}

func (b *Buffer) produce(item int) {
    // Producer logic to add item to the buffer
}

func (b *Buffer) consume() int {
    // Consumer logic to remove item from the buffer
    return 0
}

func main() {
    buffer := &Buffer{data: make([]int, 0, bufferSize)}
    buffer.cond = sync.NewCond(&buffer.mu)
    var wg sync.WaitGroup

    // Start producer goroutines
    for i := 1; i <= 3; i++ {
        wg.Add(1)
        go func(id int) {
            defer wg.Done()
            for j := 0; j < 5; j++ { // Each producer creates 5 items
                buffer.produce(id*10 + j) // Produce unique items based on id and j
                time.Sleep(100 * time.Millisecond)
            }
        }(i)
    }

    // Start consumer goroutines
    for i := 1; i <= 3; i++ {
        wg.Add(1)
        go func(id int) {
            defer wg.Done()
            for j := 0; j < 5; j++ { // Each consumer consumes 5 items
                item := buffer.consume()
                fmt.Printf("Consumer %d consumed item %d\n", id, item)
                time.Sleep(150 * time.Millisecond)
            }
        }(i)
    }

    wg.Wait()
    fmt.Println("All producers and consumers finished.")
}

Our task, as an engineer, is to implement produce and consume methods to achieve these requirements. The the produce method adds items to the buffer and notifies consumers when an item is added. The consume method removes items from the buffer and notifies producers when an item is removed. This problem can be seamlessly solved using sync.Cond to wait and signal when the buffer is full or empty.

Using `sync.Cond` in the Example

Here’s a breakdown of how sync.Cond is used in the produce and consume methods:

Initialization:

buffer.cond = sync.NewCond(&buffer.mu)

Here, sync.NewCond(&buffer.mu) creates a new condition variable associated with the mu mutex. The condition variable enables waiting and signaling around changes to the buffer (like adding or removing items).

Producer Method (produce):

func (b *Buffer) produce(item int) {
    b.mu.Lock()
    defer b.mu.Unlock()

    // Wait if the buffer is full
    for len(b.data) == bufferSize {
        b.cond.Wait() // Release lock and wait until signaled
    }

    // Add item to the buffer
    b.data = append(b.data, item)
    fmt.Printf("Produced item %d\n", item)

    // Signal a consumer that an item is available
    b.cond.Signal()
}

Lock: The producer locks mu to ensure it has exclusive access to b.data.
Wait if Full: If the buffer is full, the producer calls b.cond.Wait():
- This releases the lock on b.mu, allowing a consumer to consume an item from the buffer.
- It waits (blocks) until a consumer signals that there’s now space in the buffer.
Add Item and Signal: Once there’s space in the buffer, the producer:
- Adds the item to the buffer.
- Calls b.cond.Signal() to notify one waiting consumer (if any) that there’s now an item to consume.

Consumer Method (consume):

func (b *Buffer) consume() int {
    b.mu.Lock()
    defer b.mu.Unlock()

    // Wait if the buffer is empty
    for len(b.data) == 0 {
        b.cond.Wait() // Release lock and wait until signaled
    }

    // Remove item from the buffer
    item := b.data[0]
    b.data = b.data[1:]
    fmt.Printf("Consumed item %d\n", item)

    // Signal a producer that space is available
    b.cond.Signal()

    return item
}

Lock: The consumer locks mu to ensure exclusive access to b.data.
Wait if Empty: If the buffer is empty, the consumer calls b.cond.Wait():
- This releases the lock on b.mu, allowing a producer to produce an item and signal when it’s ready.
- The consumer waits until there’s an item to consume.
Consume Item and Signal: Once there’s an item in the buffer, the consumer:
- Removes it.
- Calls b.cond.Signal() to notify a waiting producer that there’s now space in the buffer.

Why `sync.Cond` Is Effective Here

In this example:

Condition Variable: sync.Cond provides an efficient way to handle cases when the buffer is full or empty without looping unnecessarily.
Wait and Signal Mechanism: Wait() automatically releases the lock, which prevents deadlocks by allowing other goroutines to proceed when appropriate.
Coordination: By using Signal(), we coordinate the actions of producers and consumers, ensuring that each waits only when necessary, preventing them from operating on an empty or full buffer.

This coordination allows the producers and consumers to share the buffer without interference or deadlock, efficiently managing access based on the buffer’s state.

Producers wait if the buffer is full, and signal consumers after producing an item.
Consumers wait if the buffer is empty, and signal producers after consuming an item.

Other Scenarios for `sync.Cond`

Imagine you have tasks where multiple goroutines need to wait for a specific condition before proceeding, such as:

Batch Processing: Waiting until a certain number of tasks have accumulated before processing them together.
Event Coordination: Waiting for an event to occur (e.g., data to be loaded, a resource to become available).
Rate Limiting: Controlling the number of concurrent operations to prevent resource exhaustion. In these scenarios, sync.Cond provides an efficient way to manage goroutine synchronization based on conditions, making it a right fit for problems requiring coordination among concurrent tasks.

Tricky Golang interview questions - Part 8: Max goroutine number

Harutyun Mardirossian — Wed, 30 Oct 2024 13:24:06 +0000

In Go interviews, one question that sometimes catches candidates off guard is about the "maximum number of goroutines that can be spawned." The answer isn’t as simple as stating a specific number. Instead, this question is typically used by interviewers to assess your understanding of Go’s concurrency model, memory management, and practical experience with goroutines.

Here’s a concise guide to answering this question effectively:

Understanding Go’s Concurrency Model and Goroutine Efficiency

To start, it’s helpful to clarify that:

Goroutines are lightweight, user-space threads managed by the Go runtime, making them much more efficient than traditional OS threads.
Go doesn’t impose a strict cap on goroutines, and under the right conditions, you can spawn thousands or even millions of goroutines concurrently.

A solid response would note that the practical limit largely depends on available system resources, especially memory, as each goroutine starts with a small stack size (about 2 KB). This lightweight design is why Go applications can handle massive concurrency.

System and Practical Limitations

However, it’s crucial to acknowledge the limitations:

Memory Consumption: Each goroutine uses a small amount of memory for its stack, which grows as needed. While theoretically feasible to spawn millions, in practice, this can lead to high memory usage, especially when goroutines grow due to more complex processing.
Scheduler Overhead: Go’s runtime scheduler efficiently manages goroutines across OS threads, but with too many goroutines, it might become overwhelmed with scheduling, leading to context switching and potential performance issues.

This insight tells interviewers that you’re aware of Go’s scheduling efficiency, but also its boundaries in handling very high concurrency.

GOMAXPROCS and the Scheduler

Next, demonstrate your understanding of Go’s scheduling mechanics by mentioning GOMAXPROCS. This setting determines the number of OS threads that can execute goroutines concurrently, based on the number of logical CPUs. While GOMAXPROCS doesn’t cap the number of goroutines, it does influence the level of concurrency.

Practical Tips and Best Practices

It’s also beneficial to mention strategies for managing goroutines in real applications:

Use patterns like worker pools or rate limiting to avoid unbounded goroutine creation, which can lead to resource exhaustion and degraded performance.
Monitor goroutine usage in production with runtime.NumGoroutine() to help keep tabs on active goroutines and identify potential leaks or excessive spawning.

Sample Answer Structure

Here’s a sample answer that conveys a well-rounded understanding:

Go doesn’t set a hard limit on the number of goroutines; theoretically, you could spawn millions. However, the practical limit depends on factors like available memory and the scheduler’s ability to manage them efficiently. Each goroutine requires a small amount of memory, so with excessive goroutines, memory usage increases, and context switching can affect performance. GOMAXPROCS controls concurrent OS threads for goroutines, but not the number of goroutines themselves.

This answer demonstrates a strong grasp of Go’s concurrency model, understanding system limitations, and showcases practical experience with goroutines a rounded response that interviewers will appreciate.

Bonus Section

Lets calculate how may goroutines can we run on specific hardware

The theoretical number of goroutines a system can handle may be high, but real-world factors limit this number. Memory and CPU resources are the primary bottlenecks when running a large number of goroutines.

Example Scenario: Cloud Environment with 2 CPU Cores and 100 MB of RAM

Let’s assume a cloud environment with 2 CPU cores and 100 MB of RAM. Here’s how to estimate the maximum number of goroutines:

Memory Constraints:
- Each goroutine begins with an approximate 2 KB stack, though it may grow depending on workload.
- With 100 MB of RAM, reserve 20 MB for Go’s runtime and system overhead, leaving around 80 MB for goroutines.
- Based on this, the theoretical upper bound would be: $M a x G oro u t in es = 80 MB /0.002 MB (2 K B) = 40.000$
- However, 40,000 is a rough estimate, assuming each goroutine’s stack size stays minimal. This number decreases if goroutines require more stack space.
CPU Constraints:
- With 2 CPU cores, Go’s runtime can only execute 2 OS threads concurrently (if GOMAXPROCS is set to 2).
- The Go scheduler handles goroutines across these threads, so if thousands of goroutines are running CPU-intensive tasks, context switching will add overhead, affecting performance.
- For a cloud instance with 2 cores, a practical goroutine count is often around 1,000 to 5,000 depending on workload.

Result type in PHP

Harutyun Mardirossian — Sat, 26 Oct 2024 10:14:20 +0000

I've always been a huge fan of both Rust and GoLang. Their approaches to programming, particularly in error handling, have resonated with me throughout my career. After dedicating over four years to GoLang development, I recently transitioned to a project where I'm refactoring legacy PHP code into a newer, more robust version. This shift has been both exciting and challenging, especially when it comes to adapting to PHP's traditional error-handling mechanisms.

Having grown accustomed to Go's "errors as values" concept, switching back to languages that rely on the conventional try-catch paradigm has been a significant adjustment. The idea of expecting the unexpected through exceptions feels counterintuitive. In GoLang, errors are treated as explicit return values that functions can produce, requiring developers to handle them directly. This explicitness promotes clarity and encourages thorough error checking at every function call.

In contrast, exception-based error handling can sometimes lead to overlooked edge cases. It's possible to call a function that throws an exception and only discover the oversight in production when the application crashes a scenario every developer aims to avoid.

To address this challenge, I decided to introduce a Rust-inspired Result type in my PHP controller methods. Rust's approach to error handling, much like Go's, emphasizes returning results that explicitly indicate success or failure. By implementing a Result type in PHP, I aimed to bring this level of explicitness and safety to my current project.

For instance, in the user registration endpoint, I wrapped Laravel’s validator to return a Result containing either a valid value or an error. This modification allows me to explicitly handle validation failures, enabling the application to return a 422 Unprocessable Entity status code when appropriate. Not only does this make the error handling more transparent, but it also improves the API's reliability by ensuring that all potential errors are accounted for and managed properly.

Here are some key benefits I've observed from this approach:

Enhanced Readability: By handling errors explicitly, the code becomes more readable and maintainable. Developers can see at a glance where errors might occur and how they're managed.
Improved Reliability: Explicit error handling reduces the risk of uncaught exceptions causing unexpected crashes in production environments.
Consistency Across Languages: Adopting a Result type in PHP brings the language's error-handling closer to that of Rust and GoLang, which can be beneficial for teams working across multiple languages.

To provide a clearer picture of this methodology, I've prepared three code examples to highlight the contrasts and similarities between the languages and showcase how adopting certain patterns can lead to more robust and maintainable code.

Golang

Rust

I'm curious to hear your thoughts on this approach. Do you think incorporating concepts from one language into another is beneficial in the long run?

Feel free to share your experiences or ask any questions.

The Best Resources for Learning Golang

Harutyun Mardirossian — Sat, 07 Sep 2024 15:13:21 +0000

Hi there! I haven’t introduced myself yet, as I haven’t had the chance. My name is Harutyun {ha.root.eeoon}, and I’m a Software Engineer and passionate Golang Developer. I really adore the language and enjoy working with its toolchain. I’ve been working with Go for the past five years. Before switching to Golang, I worked as a Full Stack Developer, with PHP as my main backend language and JS + jQuery for the frontend.

At that time, I noticed that many companies were transitioning to Golang from Ruby, NodeJS, and PHP to improve latency, introduce concurrency, and enable background task execution for their products. The first article I came across was on Shopify’s blog, explaining how switching to Golang improved their service latency by 80%. I was fascinated by the article and began reading up on references, language concepts, and Golang’s official blog to better understand the language.

After PHP, Golang felt like a breath of fresh air—everything was fast, incredibly fast. I remember the first program I wrote: a file checksum validator for some open-sourced NASA data from the Apollo mission. It involved a collection of five files, each around 2GB in size. Seeing an execution time of 1.4 seconds blew my mind. At that moment, I knew I had to switch my stack to Golang to create and develop awesome software.

In this article, I want to share some resources that helped me become a Golang Engineer and continue to help me develop new skills while staying up to date with the latest technologies.

Books: The Saint Triada

Get Programming with Go by Nathan Youngman and Roger Peppé

If you’re just getting started with Go and want a book that makes the learning process easy and approachable, I highly recommend “Get Programming with Go” by Nathan Youngman and Roger Peppé. This book is perfect for beginners because it really focuses on the basics without overwhelming you with too much information at once. What’s great about this book is how clearly it explains everything. It starts right from the ground up, walking you through the core concepts of Go step-by-step. You’ll learn the essentials like how to declare variables, use loops, and write functions, but the authors do it in a way that’s super accessible—even if you don’t have a ton of programming experience.

If you’re new to Go or even new to programming in general, “Get Programming with Go” is one of the best places to start. It’s designed to help you build a strong foundation in the language without feeling lost or frustrated, and by the time you’re finished, you’ll have a solid understanding of how Go works. One thing I really liked is that the book doesn’t assume you already know a bunch of other programming languages. It’s written in plain language and focuses on helping you understand Go’s syntax and structure in a simple, straightforward way. It also covers Go’s unique approach to things like error handling and memory management, but again, in a way that’s very beginner-friendly.

Learning Go by Jon Bodner

If you’ve already gone through “Get Programming with Go” and are looking to take your Go skills to the next level, I highly recommend following up with “Learning Go” by Jon Bodner. While “Get Programming with Go” gives you a solid foundation and introduces the language in a very beginner-friendly way, “Learning Go” goes deeper into the more complex aspects of the language, perfect for when you’re ready to explore Go in greater detail.

This book builds on the basics and really helps you understand the intricacies of Go, like its concurrency model, interfaces, and error handling. Where the first book focuses on helping you get started, “Learning Go” dives deeper into Go’s unique features, and it gives you a much clearer picture of how to write more efficient, maintainable code. The explanations are still very approachable, but they’re more comprehensive, covering concepts that you might not have tackled yet. So if you’ve finished “Get Programming with Go” and are ready for more depth, “Learning Go” is the perfect next step. It’s a great way to continue your Go journey and really master the language.

100 Go Mistakes and How to Avoid Them by Teiva Harsanyi

After building a solid foundation with “Get Programming with Go” and diving deeper into Go’s core concepts with “Learning Go”, the next logical step in mastering the language is “100 Go Mistakes and How to Avoid Them” by Teiva Harsanyi. This book is the perfect continuation of your Go journey because it shifts the focus from learning the language to refining your skills and avoiding common pitfalls that even experienced developers encounter.

Where the previous two books helped you understand how Go works and how to use its features, “100 Go Mistakes” takes a more practical, hands-on approach by highlighting real-world mistakes that often trip up developers and how to steer clear of them. It’s a fantastic resource for developers who want to sharpen their expertise by learning from others’ experiences. The book covers mistakes across a wide range of topics, including concurrency, error handling, testing, and memory management, giving you insights into how to write more robust, efficient, and bug-free Go code. It’s not just about coding best practices, but about understanding the deeper reasons behind why certain approaches might seem right at first but can lead to subtle errors later. This book is invaluable for improving your Go skills, helping you think more critically about your code, and ensuring you avoid common traps as you progress toward writing more professional-level Go programs.

Each book builds upon the previous one, ensuring a comprehensive learning journey from the basics to mastering Go’s intricacies. You start with “Get Programming with Go” to establish a solid foundation, as it introduces the language in a simple, beginner-friendly way. “Learning Go” then takes you deeper into Go’s core features and concepts, giving you a more thorough understanding of the language’s capabilities. Finally, “100 Go Mistakes and How to Avoid Them” focuses on practical, real-world advice, helping you identify and avoid common pitfalls, making you a more efficient and confident Go developer.

BONUS Book

Test-Driven Development in Go by Adelina Simion

"Test-Driven Development in Go" by Adelina Simion is the latest addition to my collection. With its fresh perspective and modern approach to TDD, this book will further solidify developers ability to write reliable, thoroughly tested Go code while keeping up with the latest development practices. This book will guide you through adopting test-driven development, ensuring that your Go code is not only functional but also robust and maintainable. By focusing on writing tests first and using them to guide your coding process, you’ll gain deeper insights into producing higher-quality code.

Blogs: Go Wisdom and Witty Wonders

research!rsc: Thoughts and links about programming, by Russ Cox

https://research.swtch.com

It’s the personal blog of Russ Cox, a key contributor to the Go programming language. Russ Cox is one of the original developers of Go and has written extensively about the language, its development, and software engineering concepts in general. His blog covers deep technical topics, particularly around Go’s design decisions, tooling, concurrency model, and performance optimizations. It’s an excellent resource for gaining insight into Go’s evolution and understanding the rationale behind many of the language’s features. Cox also writes about broader topics related to programming languages, compilers, and computer science theory. It’s a go-to for developers who want to dive into the intricacies of Go, and it offers unique perspectives on how Go is designed to solve practical problems.

Dave Cheney: The acme of foolishness

https://dave.cheney.net

Dave Cheney is a prominent figure in the Go community and has contributed significantly to the language, particularly in areas like performance optimization, error handling, and best practices. His blog is well-known for providing in-depth, practical advice on writing idiomatic and efficient Go code. Topics he covers include Go’s concurrency model, memory management, testing strategies, and performance tuning. Dave is also known for breaking down complex topics in an accessible way, making his blog an excellent resource for both beginner and advanced Go developers. He has written about common Go design patterns, performance pitfalls, and how to get the most out of the language’s features, offering tips that help developers write more robust and maintainable Go programs. If you’re looking to deepen your understanding of Go or explore advanced techniques, Dave Cheney’s blog is a fantastic resource.

Julia Evans' Blog

https://jvns.ca

While Julia’s blog isn’t exclusively about Go, it’s well-known for its approachable and insightful posts on a wide range of technical topics, including systems programming, debugging, networking, and sometimes Go. Her writing style is casual and highly readable, making complex subjects easier to understand, even for beginners. One of the things that sets Julia apart is her ability to take intricate concepts whether it’s networking fundamentals or how operating systems work and break them down into simple, digestible posts. She often uses zines and illustrations to make technical content more engaging, which is a unique aspect of her blog. Even though Go is not the primary focus, when she does write about Go, it’s from a practical, systems-level perspective. If you’re into systems programming and want to see how Go fits into that world, Julia Evans’ blog is a great resource!

The Go Blog

https://go.dev/blog/

The official blog for the Go programming language, maintained by the Go team at Google. This blog covers new releases, features, design decisions, and community updates. It’s a great source for understanding Go from the perspective of the core developers. It’s the primary source of updates, news, and in-depth posts about the Go programming language, maintained by the core Go development team at Google. This blog covers a wide range of topics, including:

New Go releases: Detailed explanations of what’s new in each version, including features, bug fixes, and improvements.
Language design decisions: Insights into why certain features were added or how Go continues to evolve.
Best practices: Articles on how to use Go more effectively, including tips on performance optimization, memory management, and concurrency.
Community and ecosystem updates: Highlights of community projects, Go conferences, and tools that enhance the Go ecosystem.

Useful Telegram channels

Unfortunately, these are Russian-only channels, and most of the posts come from Russian sources, so they may not be a good fit for many. But if you know Russian, you’re all set!

@goproglib - All the most useful things for a Go developer in one channel.
@go_in_action - Everything about the Go programming language in Russian and English
@golangtests - Golang challenges
@golang_interview - Golang challenges and interview preparation resources

Conclusion

Learning Go is a rewarding journey, and having the right resources makes all the difference. Whether you’re just starting out or looking to dive deep into more advanced concepts, the blogs and books mentioned here offer invaluable insights and guidance. From mastering the basics to avoiding common pitfalls, these resources have been carefully curated to ensure you can develop your Go skills effectively and confidently.

As you continue exploring Go, remember that the strength of the Go community lies not only in its powerful language but also in its willingness to share knowledge. The resources available today reflect the hard work and dedication of countless contributors who want to help you succeed. Dive in, keep learning, and enjoy the process because with Go, the possibilities are endless!

A Huge Thank You to the Go Community!

I want to take a moment to express my appreciation for the incredible resources that have made learning Go such a rewarding experience. From in-depth blog posts on language design and performance to practical advice on writing efficient, idiomatic code, the contributions of so many in the community have been invaluable. The clarity, passion, and dedication behind these resources have helped countless developers, including myself, improve and grow.

Thank you for making Go such an enjoyable and enriching journey for all of us!

Tricky Golang interview questions - Part 7: Data Race

Harutyun Mardirossian — Fri, 06 Sep 2024 12:44:34 +0000

Here is another code review interview question for you. This question is more advanced than the previous ones and is targeted toward a more senior audience. The problem requires knowledge of slices and sharing data between parallel processes.

If you're not familiar with the slices and how they are constructed, please check out my previous article about the Slice Header

What is a Data Race?

A data race occurs when two or more threads (or goroutines, in the case of Go) concurrently access shared memory, and at least one of those accesses is a write operation. If there are no proper synchronization mechanisms (such as locks or channels) in place to manage access, the result can be unpredictable behavior, including corruption of data, inconsistent states, or crashes.

In essence, a data race happens when:

Two or more threads (or goroutines) access the same memory location at the same time.
At least one of the threads (or goroutines) is writing to that memory.
There is no synchronization to control the access to that memory.

Because of this, the order in which the threads or goroutines access or modify the shared memory is unpredictable, leading to non-deterministic behavior that can vary between runs.

     +----------------------+      +---------------------+
     | Thread A: Write      |      | Thread B: Read      |
     +----------------------+      +---------------------+
     | 1. Reads x           |      | 1. Reads x          |
     | 2. Adds 1 to x       |      |                     |
     | 3. Writes new value  |      |                     |
     +----------------------+      +---------------------+

                    Shared variable x
                    (Concurrent access without synchronization)

Here, Thread A is modifying x (writing to it), while Thread B is reading it at the same time. If both threads are running concurrently and there’s no synchronization, Thread B could read x before Thread A has finished updating it. As a result, the data could be incorrect or inconsistent.

Question: One of your teammates submitted the following code for a code review. Please review the code carefully and identify any potential issues.
And here the code that you have to review:

package main  

import (  
    "bufio"  
    "bytes"
    "io"
    "math/rand"
    "time"
)  

func genData() []byte {  
    r := rand.New(rand.NewSource(time.Now().Unix()))  
    buffer := make([]byte, 512)  
    if _, err := r.Read(buffer); err != nil {  
       return nil  
    }  
    return buffer  
}  

func publish(input []byte, output chan<- []byte) {  
    reader := bytes.NewReader(input)  

    bufferSize := 8  
    buffer := make([]byte, bufferSize)  

    for {  
       n, err := reader.Read(buffer)  
       if err != nil || err == io.EOF {  
          return  
       }  
       if n == 0 {  
          break  
       }  
       output <- buffer[:n]  
    }  
}  

func consume(input []byte) {  
    scanner := bufio.NewScanner(bytes.NewReader(input))  
    for scanner.Scan() {  
       b := scanner.Bytes()  
       _ = b  
       // does the magic  
    }  
}  

func main() {  
    data := genData()  
    workersCount := 4  
    chunkChannel := make(chan []byte, workersCount)  

    for i := 0; i < workersCount; i++ {  
       go func() {  
          for chunk := range chunkChannel {  
             consume(chunk)  
          }  
       }()  
    }  

    publish(data, chunkChannel)  
    close(chunkChannel)  
}

What we have here?

The publish() function is responsible for reading the input data chunk by chunk and sending each chunk to the output channel. It begins by using bytes.NewReader(input) to create a reader from the input data, which allows the data to be read sequentially. A buffer of size 8 is created to hold each chunk of data as it’s being read from the input. During each iteration, reader.Read(buffer) reads up to 8 bytes from the input, and the function then sends a slice of this buffer (buffer[:n]) containing up to 8 bytes to the output channel. The loop continues until reader.Read(buffer) either encounters an error or reaches the end of the input data.

The consume() function handles the data chunks received from the channel. It processes these chunks using a bufio.Scanner, which scans each chunk of data, potentially breaking it into lines or tokens depending on how it’s configured. The variable b := scanner.Bytes() retrieves the current token being scanned. This function represents a basic input processing.

The main() creates a buffered channel chunkChannel with a capacity equal to workersCount, which is set to 4 in this case. The function then launches 4 worker goroutines, each of which will read data from the chunkChannel concurrently. Every time a worker receives a chunk of data, it processes the chunk by calling the consume() function. The publish() function reads the generated data, breaks it into chunks of up to 8 bytes, and sends them to the channel.

The program uses goroutines to create multiple consumers, allowing for concurrent data processing. Each consumer runs in a separate goroutine, processing chunks of data independently.

If you run this code, noting suspicious will happen:

[Running] go run "main.go"

[Done] exited with code=0 in 0.94 seconds

But there is a problem. We have a Data Race Risk. In this code, there’s a potential data race because the publish() function reuses the same buffer slice for each chunk. The consumers are reading from this buffer concurrently, and since slices share underlying memory, multiple consumers could be reading the same memory, leading to a data race. Let's try to use a race detection. Go provides a built-in tool to detect data races: the race detector. You can enable it by running your program with the -race flag:

go run -race main.go

If we add the -race flag to the run command we will receive the following output:

[Running] go run -race "main.go"

==================
WARNING: DATA RACE
Read at 0x00c00011e018 by goroutine 6:
  runtime.slicecopy()
      /GOROOT/go1.22.0/src/runtime/slice.go:325 +0x0
  bytes.(*Reader).Read()
      /GOROOT/go1.22.0/src/bytes/reader.go:44 +0xcc
  bufio.(*Scanner).Scan()
      /GOROOT/go1.22.0/src/bufio/scan.go:219 +0xef4
  main.consume()
      /GOPATH/example/main.go:40 +0x140
  main.main.func1()
      /GOPATH/example/main.go:55 +0x48

Previous write at 0x00c00011e018 by main goroutine:
  runtime.slicecopy()
      /GOROOT/go1.22.0/src/runtime/slice.go:325 +0x0
  bytes.(*Reader).Read()
      /GOROOT/go1.22.0/src/bytes/reader.go:44 +0x168
  main.publish()
      /GOPATH/example/main.go:27 +0xe4
  main.main()
      /GOPATH/example/main.go:60 +0xdc

Goroutine 6 (running) created at:
  main.main()
      /GOPATH/example/main.go:53 +0x50
==================
Found 1 data race(s)
exit status 66

[Done] exited with code=0 in 0.94 seconds

The warning you’re seeing is a classic data race detected by Go’s race detector. The warning message indicates that two goroutines are accessing the same memory location (0x00c00011e018) concurrently. One goroutine is reading from this memory, while another goroutine is writing to it at the same time, without proper synchronization.

The first part of the warning tells us that Goroutine 6 (which is one of the worker goroutines in your program) is reading from the memory address 0x00c00011e018 during a call to bufio.Scanner.Scan() inside the consume() function.

Read at 0x00c00011e018 by goroutine 6:
  runtime.slicecopy()
  /GOROOT/go1.22.0/src/runtime/slice.go:325 +0x0
  bytes.(*Reader).Read()
  /GOROOT/go1.22.0/src/bytes/reader.go:44 +0xcc
  bufio.(*Scanner).Scan()
  /GOROOT/go1.22.0/src/bufio/scan.go:219 +0xef4
  main.consume()
  /GOPATH/example/main.go:40 +0x140
  main.main.func1()
  /GOPATH/example/main.go:55 +0x48

The second part of the warning shows that the main goroutine previously wrote to the same memory location (0x00c00011e018) during a call to bytes.Reader.Read() inside the publish() function.

Previous write at 0x00c00011e018 by main goroutine:
  runtime.slicecopy()
  /GOROOT/go1.22.0/src/runtime/slice.go:325 +0x0
  bytes.(*Reader).Read()
  /GOROOT/go1.22.0/src/bytes/reader.go:44 +0x168
  main.publish()
  /GOPATH/example/main.go:27 +0xe4
  main.main()
  /GOPATH/example/main.go:60 +0xdc

The final part of the warning explains that Goroutine 6 was created in the main function.

Goroutine 6 (running) created at:
  main.main()
  /GOPATH/example/main.go:53 +0x50

In this case, while one goroutine (Goroutine 6) is reading from the buffer in consume(), the publish() function in the main goroutine is simultaneously writing to the same buffer, leading to the data race.

+-------------------+               +--------------------+
|     Publisher     |               |      Consumer      |
+-------------------+               +--------------------+
        |                                   |
        v                                   |
1. Read data into buffer                    |
        |                                   |
        v                                   |
2. Send slice of buffer to chunkChannel     |
        |                                   |
        v                                   |
 +----------------+                         |
 |  chunkChannel  |                         |
 +----------------+                         |
        |                                   |
        v                                   |
3. Consume reads from slice                 |
                                            v
                                    4. Concurrent access
                                    (Data Race occurs)

Why the Data Race Occurs

The data race in this code arises because of how Go slices work and how memory is shared between goroutines when a slice is reused. To fully understand this, let’s break it down into two parts: the behavior of the buffer slice and the mechanics of how the race occurs. When you pass a slice like buffer[:n] to a function or channel, what you are really passing is the slice header which contains a reference to the slice’s underlying array. Any modifications to the slice or the underlying array will affect all other references to that slice.

buffer = [ a, b, c, d, e, f, g, h ]  <- Underlying array
           ↑
          Slice: buffer[:n]

func publish(input []byte, output chan<- []byte) {  
    reader := bytes.NewReader(input)  

    bufferSize := 8  
    buffer := make([]byte, bufferSize)  

    for {  
       // ....
       output <- buffer[:n] // <-- passing is a reference to the underlying array
    }  
}

If you send buffer[:n] to a channel, both the publish() function and any consumer goroutines will be accessing the same memory. During each iteration, the reader.Read(buffer) function reads up to 8 bytes from the input data into this buffer slice. After reading, the publisher sends buffer[:n] to the output channel, where n is the number of bytes read in the current iteration.

The problem here is that buffer is reused across iterations. Every time reader.Read() is called, it overwrites the data stored in buffer.

Iteration 1: publish() function reads the first 8 bytes into buffer and sends buffer[:n] (say, [a, b, c, d, e, f, g, h]) to the channel.
Iteration 2: The publish() function overwrites the buffer with the next 8 bytes, let’s say [i, j, k, l, m, n, o, p], and sends buffer[:n] again.

At this point, if one of the worker goroutines is still processing the first chunk, it is now reading stale or corrupted data because the buffer has been overwritten by the second chunk. Reusing a slice neans sharing the same memory.

How to fix the Data Race?

To avoid the race condition, we must ensure that each chunk of data sent to the channel has its own independent memory. This can be achieved by creating a new slice for each chunk and copying the data from the buffer to this new slice. The key fix is to copy the contents of the buffer into a new slice before sending it to the chunkChannel:

chunk := make([]byte, n)    // Step 1: Create a new slice with its own memory
copy(chunk, buffer[:n])     // Step 2: Copy data from buffer to the new slice
output <- chunk             // Step 3: Send the new chunk to the channel

Why this fix works? By creating a new slice (chunk) for each iteration, you ensure that each chunk has its own memory. This prevents the consumers from reading from the buffer that the publisher is still modifying. copy() function copies the contents of the buffer into the newly allocated slice (chunk). This decouples the memory used by each chunk from the buffer. Now, when the publisher reads new data into the buffer, it doesn’t affect the chunks that have already been sent to the channel.

+-------------------------+           +------------------------+
|  Publisher (New Memory) |           | Consumers (Read Copy)  |
|  [ a, b, c ] --> chunk1 |           |  Reading: chunk1       |
|  [ d, e, f ] --> chunk2 |           |  Reading: chunk2       |
+-------------------------+           +------------------------+
         ↑                                    ↑
        (1)                                  (2)
   Publisher Creates New Chunk          Consumers Read Safely

This solution works is that it breaks the connection between the publisher and the consumers by eliminating shared memory. Each consumer now works on its own copy of the data, which the publisher does not modify. Here’s how the modified publish() function looks:

func publish(input []byte, output chan<- []byte) {
    reader := bytes.NewReader(input)
    bufferSize := 8
    buffer := make([]byte, bufferSize)

    for {
        n, err := reader.Read(buffer)
        if err != nil || err == io.EOF {
            return
        }
        if n == 0 {
            break
        }

        // Create a new slice for each chunk and copy the data from the buffer
        chunk := make([]byte, n)
        copy(chunk, buffer[:n])

        // Send the newly created chunk to the channel
        output <- chunk
    }
}

Summary

Slices Are Reference Types:
As mentioned earlier, Go slices are reference types, meaning they point to an underlying array. When you pass a slice to a channel or a function, you’re passing a reference to that array, not the data itself. This is why reusing a slice leads to a data race: multiple goroutines end up referencing and modifying the same memory.

Memory Allocation:
When we create a new slice with make([]byte, n), Go allocates a separate block of memory for that slice. This means the new slice (chunk) has its own backing array, independent of the buffer. By copying the data from buffer[:n] into chunk, we ensure that each chunk has its own private memory space.

Decoupling Memory:
By decoupling the memory of each chunk from the buffer, the publisher can continue to read new data into the buffer without affecting the chunks that have already been sent to the channel. Each chunk now has its own independent copy of the data, so the consumers can process the chunks without interference from the publisher.

Preventing Data Races:
The main source of the data race was the concurrent access to the shared buffer. By creating new slices and copying the data, we eliminate the shared memory, and each goroutine operates on its own data. This removes the possibility of a race condition because there’s no longer any contention over the same memory.

Conclusion

The core of the fix is simple but powerful: by ensuring that each chunk of data has its own memory, we eliminate the shared resource (the buffer) that was causing the data race. This is achieved by copying the data from the buffer into a new slice before sending it to the channel. With this approach, each consumer works on its own copy of the data, independent of the publisher’s actions, ensuring safe concurrent processing without race conditions. This method of decoupling shared memory is a fundamental strategy in concurrent programming. It prevents the unpredictable behavior caused by race conditions and ensures that your Go programs remain safe, predictable, and correct, even when multiple goroutines are accessing data concurrently.

It's that easy!

Tricky Golang interview questions - Part 6: NonBlocking Read

Harutyun Mardirossian — Wed, 10 Jul 2024 08:11:36 +0000

This problem is more related to code review. It requires knowledge about channels and select cases, also blocking, making it one of the most difficult interview questions I faced in my career. In these kinds of questions, the context is unclear at first glance and requires a deep understanding of blocking and deadlocks. While previous articles mostly targeted advanced junior or entry-level middle topics, this one is a more senior-level problem.

Question: One of your teammates submitted this code for a code review. This code has a potential threat. Identify it and give a solution to solve it.

package main

import (
    "fmt"
    "time"
)

func main() {
    ch := make(chan int)

    go func() {
        time.Sleep(2 * time.Second)
        ch <- 42
        fmt.Println("Sent: 42")
    }()

    val := <-ch
    fmt.Println("Received:", val)

    fmt.Println("Continuing execution...")
}

At first glance nothing suspicious in this code. If we try to run it it will actually compile and run without any noticeable problem.

[Running] go run "main.go"

Sent: 42
Received: 42
Continuing execution...

[Done] exited with code=0 in 2.124 seconds

The code itself also seems fine. We have concurrent consumption implemented correctly with 2 goroutines working independently. Let's break down the code and see what's happening:

A channel ch is created with make(chan int). This is an unbuffered channel.
A goroutine is started that sleeps for 2 seconds and then sends the value 42 to the channel.
The main function performs a read operation on ch with val := <-ch.

Again seems fine. But what we actually have here is, that the send operation is delayed. The anonymous goroutine waits for 2 seconds before sending the value into the channel. So when we run this code the main function starts reading the channel and expects a value in there before the channel gets populated with a value. This operation blocks the further execution of the code.

Read operations on empty channels

In Go, when you try to read from an empty channel, the read operation blocks until a value becomes available. This means that the goroutine performing the read will be paused and will not proceed with further operations until it can successfully read a value from the channel.

When the code performs a read operation on a channel:

Unbuffered Channel: If the channel is unbuffered and no value is available, the read operation will block until another goroutine sends a value to the channel.
Buffered Channel: If the channel is buffered, the read operation will block if the buffer is empty.

The delay of 2 seconds won't be that noticeable in this case and the one who observes the execution won't even notice the gap, but from the runtime perspective, the whole execution flow was stalled for 2 seconds. Until the value 42 is sent after 2 seconds, the main goroutine is blocked on val := <-ch. A blocking read halts all subsequent code execution until the read operation completes. This can lead to a program that appears to be frozen if there is no other goroutine sending data to the channel. If more operations are supposed to follow, they are delayed.

In the real-world scenarios, for example, we have created a mini-Youtube application. One of the heaviest components for Youtube is the video encoder, which, for example, is represented as a pool of worker services.

The process of video encoding can take anywhere from a few minutes to several hours. Imagine our main function sends a 24-hour long video to the encoder, which might take 3-4 hours to process. Everything written after the channel read line will be blocked for hours. Consequently, your backend will be unable to perform any other tasks until the video encoding is complete. If you increase the sleep timer to 20 seconds time.Sleep(20 * time.Second) you will notice how long it takes until the last print statement appears in the output log.

Consequences of Blocking

As we already discussed, a blocking read halts all subsequent code execution until the read operation completes. This can lead to a program that appears to be frozen if there is no other goroutine sending data to the channel.
May cause serious concurrency issues. If the main goroutine (or any critical goroutine) blocks indefinitely waiting for data, it can prevent other important tasks from executing, leading to deadlocks or unresponsive behaviour.
Resource utilization problems. While blocked, the goroutine does not consume CPU resources actively, but it ties up logical resources like goroutine stacks and potentially other dependent tasks.

Non-blocking Alternatives

To avoid blocking reads, you can use non-blocking alternatives like the select statement with a default case. The select statement in Go is a powerful feature that allows a goroutine to wait on multiple communication operations, making it possible to perform non-blocking operations and handle multiple channels. The select statement works by evaluating multiple channel operations and proceeding with the first one that is ready. If multiple operations are ready, one of them is chosen at random. If no operations are ready, the default case, if present, is executed, making it a non-blocking operation.

The basic syntax of the select statement:

select {
case <-ch1:
    // Do something when ch1 is ready for receiving
case ch2 <- value:
    // Do something when ch2 is ready for sending
default:
    // Do something when no channels are ready (non-blocking path)
}

Code review

As a code reviewer, you must be able to identify this potentially dangerous code, provide a good explanation of how to avoid it and encourage the teammate to fix the problem. To fix the problem let's implement a select statement. The fix will look like the following:

package main

import (
    "fmt"
    "time"
)

func main() {
    ch := make(chan int)

    // Goroutine to send data to the channel after 2 seconds
    go func() {
        time.Sleep(2 * time.Second)
        ch <- 42
        fmt.Println("Sent: 42")
    }()

    // Main function performing a non-blocking read
    for {
        select {
        case val := <-ch:
            fmt.Println("Received:", val)
            fmt.Println("Continuing execution...")
            return
        default:
            fmt.Println("No value received")
            time.Sleep(500 * time.Millisecond) // Sleep for a while to prevent busy looping
            // handle the execution flow of instructions and operations that must continue
        }
    }
}

Now if we run this, we'll see the following behaviour:

[Running] go run "main.go"

No value received
No value received
No value received
No value received
Received: 42
Continuing execution...

[Done] exited with code=0 in 2.31 seconds

The main function will repeatedly print “No data received” during the times when the channel is empty, interspersed with “Received: 42” as values become available. The default case ensures the main function does not block and can perform other operations (like printing “No data received” and sleeping). This mechanism ensures that the main function remains responsive, even if one or both channels do not have data available.

It's that easy!

Tricky Golang interview questions - Part 5: interface == nil

Harutyun Mardirossian — Wed, 26 Jun 2024 14:09:30 +0000

Another topic I would like to discuss in these series is the interface to nil comparison problem. This question is frequently asked during many golang interviews and requires an understanding of how types are constructed under the hood.

Question: Which if statements will be evaluated as true?

package main  

import "fmt"  

type SomeType interface {  
    Get()  
}  

type SomeImpl struct {...}  
func (i SomeImpl) Get() {...}  

func main() {  
    var aType SomeType  
    if aType == nil {
       fmt.Println("nil interface")  
    }  

    var aImpl *SomeImpl  
    if aImpl == nil {
       fmt.Println("nil struct")  
    }  

    aType = aImpl  
    if aType == nil {
       fmt.Println("nil assignment")  
    }  
}

As we all know (hope so) the empty interface in golang holds a nil value. The default value of an empty interface is nil. This means the uninitialised variable var aType SomeType holds a nil value because it has a type of empty (nil) interface. In this case, the if condition is fulfilled, we will see a print statement in the terminal:

[Running] go run "main.go"

nil interface

Good, let's continue further.
We have another uninitialised variable var aImpl *SomeImpl which is a pointer to the struct. As you know in golang all memory is initialised (zeroed) this means that the pointers, even if they are uninitialised, will have a default value, which is nil. So we have one more fulfilled if condition:

[Running] go run "main.go"

nil interface
nil struct

For the last, we see a value assignment (value initialisation) of a struct pointer value to the interface variable aType = aImpl. Judging by the earlier made statements it is logical to assume that we assign a nil value to the var aType and in the result, aType will remain nil.

[Running] go run "main.go"

nil interface
nil struct
nil assignment

[Done] exited with code=0 in 0.318 seconds

This sounds logical, so the confident answer is:
The program will output all print statements into the terminal because all if statements will be fulfilled during the execution!

Okay, that sounds good (would say the interviewer). Let's run the program and check the results. The actual result looks like this:

[Running] go run "main.go"

nil interface
nil struct

[Done] exited with code=0 in 0.318 seconds

As you already noticed, the output does not contain the last nil assignment print statement. So, why this happened?
To answer this question we must dig deeper into the language to understand how interfaces are constructed in golang.

Interface

In golang, an interface is a type that specifies a set of method signatures. When a value is assigned to an interface, golang constructs an interface value that consists of two parts: the dynamic type and the dynamic value. This is commonly referred to as the “interface tuple.”

Dynamic Type: This is a pointer to a type descriptor that describes the type of the concrete value stored in the interface.
Dynamic Value: This is a pointer to the actual value that the interface holds.

The interface tuple can be represented as the following structs:

type iface struct {
    tab  *itab
    data unsafe.Pointer
}

type itab struct {
    inter *interfacetype
    _type *_type
    hash  uint32
    _     [4]byte
    fun   [1]uintptr  // variable sized, actually [n]uintptr
}

tab: A pointer to an itab structure that contains information about the type and the methods that the type implements for the interface.
data: A pointer to the actual data held by the interface.

When a value is assigned to an interface, golang finds the type descriptor for the concrete type being assigned to the interface. Then sets up the method table (itab) that allows method calls through the interface to be dispatched to the correct implementation and finally stores a pointer to the actual value in the data field of the interface.

When aType = aImpl is executed

Determining Interface Implementation: golang first determines that *SomeImpl (a pointer to SomeImpl) implements the SomeType interface because *SomeImpl has a method Get() with the correct signature.
Looking Up the Type Descriptor: golang looks up the type descriptor for *SomeImpl.
Creating the itab: golang creates an itab structure
Assigning the Pointer: golang assigns the pointer to the SomeImpl value to the data field of the interface.

interface (aType)
+------------+           +-----------+
| tab        |---------->|  itab     |
|            |           |-----------|
| data       |--+        |  inter    |
+------------+  |        |  _type    |
                |        |  fun[0]   |
                |        +-----------+
                |
                v
         +---------------+
         |   *SomeImpl   |
         +---------------+
         |   ........    |
         +---------------+

Summary

To sum up, what we learned, the previous explanation in short means:

+ uninitialised +-------------+ initialised +

interface (aType)             interface (aType)
+------------+                +--------------------------------+
| tab:  nil  |                | tab:  type of *SomeImpl        |
| data: nil  |                | data: value of *SomeImpl (nil) |
+------------+                +--------------------------------+

Now the tricky part.
In golang when checking if an interface is nil, both the tab and data fields must be nil. If an interface holds a nil pointer of a concrete type, the tab field will not be nil, so the interface itself will not be considered nil.

This is the reason why we don't see the last print statement inside the terminal. After execution of aType = aImpl the variable aType is no longer considered as a nil / empty interface.

It's that easy!

Tricky Golang interview questions - Part 4: Concurrent Consumption

Harutyun Mardirossian — Mon, 24 Jun 2024 15:28:39 +0000

I want to discuss an example that is very interesting. I was surprised that many experienced developers were unable to answer it correctly. This example involves buffered channels and concurrency.

Question: What will happen when we run this code?

package main

import "fmt"

func main() {
    ch := make(chan int, 4)

    go func() {
        ch <- 1
        ch <- 2
        ch <- 3
        ch <- 4
        ch <- 5
        close(ch)
    }()

    for num := range ch {
        fmt.Println(num)
    }
}

Let's analyse this piece of code. What we have here:

a buffered channel ch of type int with a capacity of 4 is created
a goroutine that sends values
a goroutine sends five values to the channel
the first 4 sends will fill the channel
the fifth send operation will be blocked because the channel is at capacity

This idea seems straightforward, and you give the interviewer a confident answer: Since the buffer capacity is only 4, the fifth send operation will block, causing a deadlock. Channels in go block when they are full and more values are being sent.

fatal error: all goroutines are asleep - deadlock!

At this point, the interviewer will kindly ask you to run the code and check the results.

[Running] go run "main.go"

1
2
3
4
5

[Done] exited with code=0 in 0.318 seconds

And surprise surprise we see that this code actually works without deadlocks. Many interviewees, even those with significant experience, struggle to explain this unusual behaviour. There must be a deadlock in this code!

This raises another question: What can you change to create a deadlock in this code? It's quite simple: just remove the anonymous goroutine and send integers into the channel directly within the main function.

package main

import "fmt"

func main() {
    ch := make(chan int, 4)

    ch <- 1
    ch <- 2
    ch <- 3
    ch <- 4
    ch <- 5 // deadlock at line:12
    close(ch)

    for num := range ch {
        fmt.Println(num)
    }
}

Now, we've created a deadlock:

[Running] go run "main.go"

fatal error: all goroutines are asleep - deadlock!

goroutine 1 [chan send]:
main.main()
        main.go:12 +0x78

[Done] exited with code=0 in 0.318 seconds

Let me explain why this is happening. Why does introducing a simple anonymous goroutine fix the problem?

Let's first define how concurrency works in go and what are channels:

Concurrency in Go is built around goroutines and channels, which provide a simple and powerful model for concurrent programming.
A goroutine is a lightweight thread managed by the Go runtime. Goroutines are created using the go keyword followed by a function call.
Channels provide a way for goroutines to communicate with each other and synchronize their execution. Channels can be used to send and receive values between goroutines.

Channels can be buffered or unbuffered:

Unbuffered channels have a capacity of 0. When a sender sends a value on an unbuffered channel, it will block until a receiver is ready to receive the value.
Buffered channels have a capacity greater than 0. When a sender sends a value on a buffered channel, it will only block if the buffer is full.

Now that we understand how concurrency works in Go, let’s explore an important concept related to channels.

Concurrent Consumption

The main idea behind concurrent consumption is to ensure that values sent to a channel are being read (or consumed) while they are being sent. This prevents the channel from getting full and blocking further send operations. Concurrent consumption in Go involves having one or more goroutines that send data to a channel while one or more other goroutines read from the same channel. This pattern is commonly used to handle situations where production (sending data) and consumption (receiving data) happen at different rates.

To ensure a smooth concurrent flow in this scenario, we need to clearly define producers and consumers that run concurrently. In go, the main function starts executing immediately upon the program's start, in its own goroutine.

In the example with a deadlock, there's a single goroutine that acts as both the producer and consumer. This means that within the same goroutine, values are being sent into a channel and simultaneously received from it. However, the deadlock occurs because the channel is filled with values before all it gets consumed. This results in a situation where the channel becomes blocked, preventing further operations.
In the first example the the producer and consumer are separated, they run in different goroutines. By using an anonymous goroutine to send values, the main function is free to read from the channel concurrently. This prevents the channel from getting full and blocking further sends, avoiding a deadlock situation.

So the correct answer is:
The program will output all values that were sent into the buffered channel.
Why?
Because we have 2 goroutines one to produce data (anonymous) and another to consume (main). This way we ensure a flawless execution that empties the channel on time.

It's that easy!

Tricky Golang interview questions - Part 3: nil receivers

Harutyun Mardirossian — Fri, 31 May 2024 17:04:28 +0000

I have one more tricky interview question to discuss in this series. This one is related to function receivers and methods in golang, often called nil receivers.

Question: What is the output of the following?

package main

import "fmt"

type gopher struct {
    name string
}

func (r *gopher) print() {
    fmt.Println("gopher-printer works!")
}

func main() {
    var gpr *gopher
    gpr.print()
}

A quick note here, this question has one of the highest failing rates when asked during the interviews. Most of the interviewees never tried or never experienced such behaviour.

Receiver

A receiver argument is what distinguishes a method from a regular function in GoLang. In essence, a method is simply a function that includes a receiver argument. A receiver can also be of a non-struct type. For example, in the code below, we have a method add() with a receiver of type Integer, which is an alias for int.

type Integer int

func (i Integer) add(j Integer) Integer {
    return i + j
}

Okay, that's a pretty straightforward representation of what a receiver is. Now, let's try answering this question. If you come from OOP languages like Java, C# or C++ you are familiar with the term null pointer exception. It means that you are trying to access a part of something that doesn't exist. Here's the classic example from Java:

public class NullPointer f
    public static void main(String[] args) {
        String a = null;
        System.out.println(a.length());
    }
}

Trying to compile this will throw the null pointer exception:

Exception in thread "main" java.lang.NullPointerException
        at NullPointer-main (NullPointer.java:7)

The developer familiar with this concept will shortly answer:
The program will panic with nil pointer dereference if we try to run this.

panic: runtime error: invalid memory address or nil pointer dereference

Let's actually run the program and make sure.

[Running] go run "main.go"

gopher-printer works!

[Done] exited with code=0 in 0.318 seconds

Here, most interviewees get confused by this behaviour and assume that the Go compiler initialises the struct when we create the variable with the type var gpr *gopher. To test this let's add a print line inside the print() function like this:

func (r *gopher) print() {
    fmt.Printf("receiver: %v \n", r)
    fmt.Println("gopher-printer works!")
}

and build the program again.

[Running] go run "main.go"

receiver: <nil>
gopher-printer works!

[Done] exited with code=0 in 0.318 seconds

Oops, the struct is not initialised, its value is nil. Again, if you come from OOP languages this may seem like a static method call, but it's far different from that concept. You see, receivers in Go act like a basic argument, and in this case, when we call a method on an uninitialised struct, inside the methods nil has passed as a receiver as if you do something like this instead:

package main

import "fmt"

type gopher struct {
    name string
}

func print(r *gopher)  {
    fmt.Println("gopher-printer works!")
}

func main() {
    var gpr *gopher
    print(gpr)
}

The nil receiver is just a parameter.

After we clear this out, you give a confident answer to the interviewer:
This will print a message "gopher-printer works!" into the console and will not cause a compile time panic
It's that easy!

Here some interviewers like to ask the following:
What will cause the program to panic?

The answer is very simple. Since the nil receiver is just a parameter, this panic will only occur if the method tries to access the struct fields, such as name in our case.

type gopher struct {
    name string
}

func (r *gopher) print() {
    fmt.Println(r.name) // <-- accessing the field
    fmt.Println("gopher-printer works!")
}

So the full answer to this tricky question is:
When you call this method from a nil pointer you will not get any compiler errors but you may get runtime panic if the method tries to access the struct fields.

Bonus section

Another interesting point to note is that a nil receiver can be initialized inside the method. However, this initialization has no effect outside of that method. Check the following code, I initialise the receiver inside the method:

package main

import "fmt"

type gopher struct {
    name string
}

func (r *gopher) print() {
    // init the receiver with a new struct and populate the field
    if r == nil {
        r = new(gopher)
        r.name = "crusty0gphr"
    }

    fmt.Printf("hi there %s \n", r.name)
}

func main() {
    var gpr *gopher
    gpr.print()
}

The result of this program will be:

[Running] go run "main.go"

hi there crusty0gphr

[Done] exited with code=0 in 0.318 seconds

But inside the main function, the variable gpr will remain nil and accessing its field will cause a compile time panic!
Now, It's that easy, finally!

Forem: Harutyun Mardirossian

Anti-pattern: Overwriting return value inside defer

The Core Mechanism

The Danger

Unnamed return value scenario

Contexts: To Cancel or Not to Cancel

Hierarchy Creation:

My Everyday Tools

Apps

1. iTerm2 https://iterm2.com

2. Boop https://github.com/IvanMathy/Boop

3. Zed https://zed.dev

4. Obsidian http://obsidian.md

Terminal tools

1. Ollama http://ollama.com

2. Oh my zsh https://ohmyz.sh

3. LazyDocker https://github.com/jesseduffield/lazydocker

4 NuShell https://www.nushell.sh

5. Helix Editor https://helix-editor.com

Conclusion

Understanding sync.Cond in Go: Synchronizing Goroutines in Producer-Consumer Scenarios

What is sync.Cond?

How sync.Cond Works

Problem: Producer-Consumer with Mutex and Condition Variable

Using sync.Cond in the Example

Why sync.Cond Is Effective Here

Other Scenarios for sync.Cond

Tricky Golang interview questions - Part 8: Max goroutine number

Understanding Go’s Concurrency Model and Goroutine Efficiency

System and Practical Limitations

GOMAXPROCS and the Scheduler

Practical Tips and Best Practices

Sample Answer Structure

Bonus Section

Lets calculate how may goroutines can we run on specific hardware

Example Scenario: Cloud Environment with 2 CPU Cores and 100 MB of RAM

Result type in PHP

Golang

Rust

The Best Resources for Learning Golang

Books: The Saint Triada

Get Programming with Go by Nathan Youngman and Roger Peppé

Learning Go by Jon Bodner

100 Go Mistakes and How to Avoid Them by Teiva Harsanyi

BONUS Book

Test-Driven Development in Go by Adelina Simion

Blogs: Go Wisdom and Witty Wonders

research!rsc: Thoughts and links about programming, by Russ Cox

Dave Cheney: The acme of foolishness

Julia Evans' Blog

The Go Blog

Useful Telegram channels

Conclusion

A Huge Thank You to the Go Community!

Tricky Golang interview questions - Part 7: Data Race

What is a Data Race?

Why the Data Race Occurs

How to fix the Data Race?

Summary

Conclusion

Tricky Golang interview questions - Part 6: NonBlocking Read

Read operations on empty channels

Consequences of Blocking

Non-blocking Alternatives

Code review

Tricky Golang interview questions - Part 5: interface == nil

Interface

Summary

Tricky Golang interview questions - Part 4: Concurrent Consumption

Concurrent Consumption

Tricky Golang interview questions - Part 3: nil receivers

Receiver

Bonus section

What is `sync.Cond`?

How `sync.Cond` Works

Using `sync.Cond` in the Example

Why `sync.Cond` Is Effective Here

Other Scenarios for `sync.Cond`