April 19, 2025

Wrapping Goroutines to Handle Return Values in Go

Introduction

Concurrency is one of Go’s superpowers, enabling developers to run tasks in parallel using goroutines. A goroutine is launched with the go keyword followed by a function call, as shown below:

package main

import (
	"fmt"
	"time"
)

func say(s string) {
	for i := 0; i < 5; i++ {
		time.Sleep(100 * time.Millisecond)
		fmt.Println(s)
	}
}

func main() {
	go say("world")
	say("hello")
}

Go playground link to the example

This simple example prints “hello” and “world” concurrently. However, the Go language specification notes that if a function called in a goroutine returns values, those values are discarded. This raises a question: how can we capture and use return values from a goroutine?

April 14, 2025

Embracing 'Share By Communicating' in Go

Introduction

Concurrency is a core strength of Go, and one of its standout principles is “Share By Communicating.” Unlike traditional approaches that rely on shared memory and locks, Go encourages developers to share data between goroutines by passing it through channels. This method simplifies concurrent programming and helps avoid common issues like race conditions, making your code safer and easier to maintain.

Why does this matter? In many languages, concurrent programs share memory directly, requiring locks to prevent conflicts. This can lead to complex, error-prone code, think deadlocks or subtle bugs that only appear under specific conditions. Go flips this on its head: instead of locking memory, you communicate data through channels, ensuring only one goroutine accesses it at a time by design.

February 10, 2024

Experience with Go workspace

Introduction

Go 1.18 added the workspace mode to Go, allowing you to work on multiple modules simultaneously without having to edit the go.mod file.

Module is a folder having go.mod file

Earlier if you are working with multiple modules the flow would look like below

Make the change in module1.
Update the go.mod file of module2 with replace directive for your local, unpublished changes.
Make the changes in module2.
Before pushing to remote remember to remove the replace from the go.mod.

What workspace allows you to do is allow you to access the changes from module1 in module2 without updating the go.mod files. Thus allowing developers to fully focus on writing code, only when you are going to complete your local development flow and are going to push to remote, we need to update the version tag of module1 in module2’s go.mod file.