That’s where select comes in. In this article, we’ll break down select in Go from scratch—with simple explanations, real-world analogies, and practical examples you’ll actually remember.

Why Do We Need select?

Let’s start with a basic problem

In Go, receiving from a channel looks like this

msg := <- ch

This works fine when

• You’re listening to one channel

• You’re okay with blocking

But what if you want

• Listen to multiple channels.

• Handle timeouts

• Support cancellation

• Avoid blocking forever

select solve all this problems.

What is select in Go?

select lets a goroutine wait on multiple channel operations and execute the one that becomes ready first.

Think of it as:

• switch → works on values

• select → works on channels

Basic Syntax of select

select {
case v := <- ch1:
    // receive from ch1
case v := <- ch2:
    // receive from ch2 
}

Important rules:

• select blocks until at least one case is ready

• Only one case runs

• If multiple cases are ready. Go picks one randomly

Real-World Analogy: Restaurant Kitchen

Imagine a chef in a restaurant kitchen

• New customer orders may arrive.

• Ingredient deliveries may arrive.

• The restaurant may close.

The chef reacts to whatever happens first.

That’s exactly how select works.

select {
case order := <-orders:
    cook(order)
case delivery := <- deliveries;
    store(delivery)
case <- closeShop:
    return
}

Example: Waiting on Multiple Channels

package main
import (
    "fmt"
    "time"
)
func main() {
    ch1 := make(chan string)
    ch2 := make(chan string)
    go func() {
        time.Sleep(1 * time.Second)
        ch1 <- "message from ch1"
    }()
    
    go func(){
        time.Sleep(2 * time.Second)
        ch2 <- "message from ch2"
    }()

    select {
    case msg := <-ch1
        fmt.Println(msg)
    case msg : <-ch2
        fmt.Println(msg)
    }
}

What happens?

• ch1 sends first

• select receives from ch1

• Program exits

What If Multiple Cases Are Ready?

If more than one channel is ready:

select {
    case <-ch1:
        fmt.Println("ch1")
    case <-ch2:
        fmt.Println("ch2")
}

In this case Go randomly chooses one. It will never rely on order inside select

Non-Blocking select with default

Sometimes you don’t want to block.

select {
case msg := <-ch:
    fmt.Println(msg)
default:
    fmt.Println("No message available")
}

Why this matters:

• Prevents deadlocks

• Useful for polling

• Makes select non-blocking

Common Beginner Mistake

This can deadlock

select {
case msg := <-ch:
    fmt.Println(msg)
}

If ch never sends, the program blocks forever.

Always consider:

• done channel

• timeout

• default

Done Channel (Cancellation Pattern)

This allows external control to stop waiting

package main

import (
	"fmt"
	"time"
)

func main() {
	ch := make(chan string)
	done := make(chan struct{})

	go func() {
		time.Sleep(2 * time.Second)
		close(done) // signal cancellation
	}()

	select {
	case msg := <-ch:
		fmt.Println("Received:", msg)

	case <-done:
		fmt.Println("Operation cancelled")
	}
}

What happens?

• ch never sends

• After 2 seconds, done closes

• select exists safely

Use Timeout (time.After)

very common in production systems.

package main

import (
    "fmt"
    "time"
)

func main() {
    ch := make(chan string)
    
    select {
    case msg := <-ch:
        fmt.Println("Received:",msg)
    case <-time.After(3 * time.Second)
        fmt.Println("Timeout occurred")
    }

}

What happens?

• ch never sends

• After 3 seconds -> timeout case executes

• Program continues safely

This prevents waiting forever.

Use default (Non-Blocking Select)

This makes select run immediately if no case is ready.

package main

import "fmt"

func main() {
    ch := make(chan string)
    select {
    case msg := <- ch:
        fmt.Println("Received:", msg)
    default:
        fmt.Println("No message available")
    }
}

What happens?

• ch has no data

• default runs immediately

• Program does NOT block

How select Is Evaluated in Go

Many developers use select in Go, but very few truly understand how it is evaluated internally.

This is an important concept especially for interviews and writing correct concurrent code.

Let's break it down clearly.

When Go executes a select statement, it does NOT check cases one-by-one from top to bottom. Instead, it follows this process:

Step-by-Step Evaluation

Step 1: Evaluate All Case Expressions

Before choosing any case, Go:

• Evaluates all channel expressions

• Evaluates all values being sent

• Executes any function calls inside the cases.

This happens before Go decides which case to run.

Example: Function Calls Run First

package main

import "fmt"

func getValue(name string) string {
    fmt.Println("Evaluating: ",name)
    return name
}

func main() {
    ch1 := make(chan string, 1)
    ch2 := make(chan string, 1)

    select {
    case ch1 <- getValue("A"):
    fmt.Println("ch1 case is selected")
    case ch2 <- getValue("B"): 
    fmt.Println("ch1 case is selected")
    }
    
    fmt.Println("Done")

}

Output:

Evaluating:  A
Evaluating:  B
ch1 case is selected
Done

Even through only once case is selected, and both functions executed. You can see that is output.

This proves evaluation happens before selection.

Step 2: Check Which Cases Are Ready

After evaluation:

• Receive case is ready if channel has data.

• Send case is ready if receiver exists (or buffer has space).

• Closed channel receive is always ready.

• Nil channel is never ready.

Receive Case Ready (Channel Has Data)

package main
import "fmt"

func main() {
    ch := make(chan string,1)
    ch <- "Hello"
    
    select {
    case msg := <-ch:
        fmt.Println("Received:",msg)    
    }
}

Output:

Received: Hello

Channel has data -> receive case is ready.

Send Case Ready (Buffered Channel Has Space)

package main

import "fmt"

func main(){
    ch := make(chan string,1)
    select {
    case ch <- "Hi":
        fmt.Println("Send successfully")
    }
}

Output:

Sent successfully

Closed Channel Receive Is Always Ready

package main

import "fmt"

func main() {
	ch := make(chan string)
	close(ch)

	select {
	case msg := <-ch:
		fmt.Println("Received from closed channel:", msg)
	}
}

Output:

Received from closed channel:

Closed channel immediately returns zero value.

Nil Channel Is Never Ready

package main

import "fmt"

func main() {
	var ch chan string // nil channel

	select {
	case msg := <-ch:
		fmt.Println(msg)

	default:
		fmt.Println("Nil channel blocks forever")
	}
}

Output:

Nil channel blocks forever

Step 3: Chose a case

• If one case is ready -> execute it.

• If multiple are ready -> pick once randomly

• If none are ready:

  • If default exists -> run default

  • Otherwise -> block until one becomes ready.

When Should you Use select?

• Listening to multiple channels

• Implementing timeouts

• Handling cancellation

• Writing long-running goroutines

Interview FAQs

1. Does select check cases in order?

   -> No - selection random if multiple are ready.

2. Can select block forever?

   -> Yes, if no case is ready and no default.

3. Can select send and receive?

   -> Yes - both are supported.

4. What happens if no case in select is ready?

   -> If there is no default case, select blocks forever until one case becomes ready.
   If there is a default case, it executes immediately (non-blocking behaviour).

5. What happens if multiple cases are ready?

   -> Go chooses one randomly.
   It does not:
   - Check in order
   - Prioritise top case
   - Execute multiple cases

6. Does select execute all ready cases?

   -> No. It executes only one case per select execution
   To process continuously, you must use it inside a loop:

   for {
     select {
     case msg := <- ch:
           fmt.Println(msg)
    
     }
    
   }
   
   
   

7. How would you design a worker pool using select?

   ->
   - job channel
   - result channel
   - done channel
   - timeout
   - context cancellation

Conclusion

select is the idiomatic tool in Go for waiting on multiple channel operations: it enables listening to several channels at once, implementing timeouts, and responding to cancellation in a clear, concurrent-safe way. Remember the core rules—select blocks until a case is ready, only one case runs, and if multiple are ready Go picks one at random—and use those guarantees to design predictable, non-blocking goroutines.

Practical tips

• Use a for { select { ... } } loop to keep a goroutine responsive to new events.

• Use default sparingly to avoid unintended busy-waiting; use it when you explicitly want non-blocking behavior.

• Prefer context.Context (or time.Timer/time.After) for cancellation and timeouts instead of ad-hoc channel hacks.

• Be careful with nil channels and closed channels—both affect readiness and can cause selects to behave unexpectedly.

• Ensure selects can exit to avoid leaking goroutines (handle shutdown cases explicitly).

• Test concurrency with the race detector (go test -race) and static tools (go vet, linters).

Mastering select will make your concurrent Go code more robust and easier to reason about. Practice with small examples and read the official docs and examples to reinforce these patterns.

But why do they exist?

Because when multiple goroutines run at the same time, you need a safe way to share data between them without using locks, mutexes, or shared memory headaches.

So Go follows:

“Do not communicate by sharing memory; share memory by communicating.”

This is exactly what channels provides.

What Is a Channel?

A channel is a pipe that lets one goroutine send data to another goroutine.

Goroutine A  ---- data ---->  Goroutine B
              (via channel)

You can think of it like a water pipe for values.

Creating a Channel

ch := make(chan int)

This creates a channel that can send / receive integers.

Sending & Receiving

package main
import "fmt"

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

    // Sender goroutine
    go func() {
        ch <- 10 // sending data
    }()

    v := <-ch //receiving data
    fmt.Println(v)
}

What happens?

• The goroutine sends 10 into the channel.

• The main goroutine waits until it receives that value.

• Output :10

Channels block by default → meaning the sender waits until someone receives the data.

This prevents many concurrency bugs automatically.

Why Blocking Is Actually Useful

Blocking ensures synchronisation without locks.

done: make(chan bool)

go func() {
    fmt.Println("Task running...")
    done <- true // signals completion
}()
<- done // waits for task
fmt.Println("Task finished!")

No mutex. No busy waiting. The channel does all the synchronisation.

Buffered vs Unbuffered Channels

By default, channels are unbuffered i.e send blocks until receive happens.

Let’s under this with Restaurant Analogy.

Unbuffered Channel = Chef hands plate directly to waiter

Senario

The kitchen has no counter, no shelf, no tray to place food on.

Only option → Chef must hand the plate directly to a waiter

What happens?

• Chef prepares the dish.

• Chef extends the plate to give it to a waiter.

• If no waiter is available, the chef cannot let go of the plate.

• So the chef stands and waits until a waiter arrives and takes it.

• Once the waiter grabs the plate, both continue.

Meaning in GO

• Sender waits until the receiver is ready.

• Receiver waits until the sender sends.

• Communication is synchronous.

ch := make(chan string) // unbuffered

go func() {
    ch <- "Pasta"
    // waits until someone receives
}()

fmt.Println(<-ch) // receives and unblocks chef

“Serving must happen instantly — no place to put the dish.“

Buffered Channel = Chef places plates on a counter (tray / shelf)

senario

Now the kitchen has a food counter with space for 3 plates.

• Chef puts dishes on the counter.

• Waiters pick them up later.

What happens?

• Chef finishes dish and places it on counter.

• No need to wait for a waiter.

• Chef continues cooking.

• Waiter picks plates when free.

• If the counter becomes full chef must stop and wait.

Meaning in go

• Sender places data in buffer does not wait.

• Receiver picks up whenever ready.

• Only blocks when buffer is full.

Buffered Channel

ch := make(chan int, 2)

This channel can hold 2 values without blocking.

ch := make(chan int, 2)

ch <- 1
ch <- 2 // ok

// ch <- 3 // would block because buffer is full

fmt.Println(<- ch) // 1
fmt.Println(<- ch) // 2

Use buffered channels when you want to control throughput.

Final Understanding

Unbuffered

“Chef waits until a waiter is RIGHT THERE to take the dish.“

Buffered

“Chef places dish on counter and keeps cooking - unless counter fills up.“

Directional Channels

In Go, channels can be restricted so a function can only send or only receive.
This improves safety by preventing incorrect usage.

Why Use Directional Channels?

• Prevent accidental receiving when a goroutine should only send.

• Improve readability like “this function only sends data”.

• Allow the compiler to catch misuses early.

func worker(id int, jobs <- chan int, results chan <- int) {
    for j := range jobs {
        results <- j * 2
    }
}

• jobs <-chan int → receive only

• results chan <- int → send only

In this implementation worker cannot misuse channels

• If it tries to send on jobs, compiler error.

• If it tries to receive from results, compiler error.

Why It Matters?

In large systems:

• Directional channels enforce correctness.

• They reduce bugs caused by wrong channel usage.

Closing a Channel

Closing a channel signals:

“No more values will be sent“

Workers can safely stop processing when the channel is closed.

Example — Using close()

close(jobs)

Now workers reading from jobs will keep receiving until all values are consumed, then exit gracefully.

How receivers detect closure

v, ok := <-jobs
if !ok {
    fmt.Println("channel closed")
}

Key Rules:

• Only the sender should close the channel.

• Closing a channel twice → panic.

• Receiving from closed channel → zero-value but safe.

Deadlocks

A deadlock happens when goroutine are stuck waiting on each other forever.

Go detect this and panics.

func main() {
    ch := make(chan int)
    ch <- 1 // no receiver -> deadlock
}

In this above code the main goroutine is waiting to send, but no goroutine is receiving.

Deadlock in Receivers

func main() {
    ch := make(chan int)
    fmt.Println(<-ch) // no sender
}

Goroutine Leaks

A goroutine leak occurs when a goroutine is started but then enters a permanent waiting state, unable to complete its execution, and there is no mechanism to stop it. It remains alive until the entire program terminates.

func worker(ch <-chan int) {
    for v := range ch { // here waits forever if channel never closed
        fmt.Println(v)
    }
}

func main() {
    ch := make(chan int)
    go worker(ch)
    // forgot to close or send
}

In this example, after calling the worker in another goroutine, we are not sending any values to that channel. To fix these leaks, always close channels when no more values will be sent.

Resources Consumed by a Leaked Goroutine

A leaked goroutine is not free. It continuously holds onto system resources, which can lead to prerfromance degradation. Below are resources consumed by the leaked goroutine.

1. Memory (Stack)

   Every goroutine starts with a small amount of memory for its stack typically 2 KB while small, this memory is continuously allocated and reserved.

   • If you have a bug that causes a goroutine leak every time an event occurs, and that event happens frequently, the number of leaks goroutines will climb, and the total memory consumed by their stacks will grow linearly. For example 100,000 leaked goroutines will consume about 200 MB of stack memory alone.

2. CPU and Scheduling Overheads

   Even through a leaked goroutine and isn’t actively running code, it still costs the Go runtime (the scheduler) resources

   • Scheduler Management : The Go scheduler must maintain the data structure for every active goroutine. The scheduler periodically checks the status of these blocked goroutines to see if they can be unblocked.

   • Context Switching: While minimal, if the goroutine briefly wakes up due to a false signal or is examined by the scheduler, it can contribute to small, unnecessary context-switching overhead.

3. Channel Management

   The channel ch itself is also part of the resource consumption. The channel’s internal data structure must track that one goroutine is currently blocked waiting to receive from it.

To prevent the leak, must either:

1. Close the channel after sending all necessary data

2. Use a different synchronization primitive like a sync.WaitGroup if the worker should exit after completing a specific job instead of waiting for the channel to close.

How WaitGroup Prevents Premature Exit Leaks

sync.WaitGroup doesn’t directly stop a goroutine from getting stuck, it provides the mechanism to ensure the entire application waits for the worker to complete its execution path, which is key to avoid a leak if the program were to continue running.

In a simple scenario without a WaitGroup, if the main function finishes, the program terminates immediately, potentially killing active workers mid-execution, or, as in previous examples causing a deadlock.

1. Waiting for Known Finite Tasks

   If you know a goroutine’s job is finite, the WaitGroup guarantees the program won’t exit until that job is done.

   Example: Clean Exit without a Leak

   In this pattern, the worker has a clear, finite task. The WaitGroup ensures its completion.

    package main
   
    import (
        "fmt"
        "sync"
        "time"
    )
   
    func worker(id int, wg *sync.WaitGroup) {
        // The DEFER ensures wg.Done() is called no matter what.
        defer wg.Done() 
   
        fmt.Printf("Worker %d starting...\n", id)
        time.Sleep(time.Millisecond * 100) // Finite task
    }
   
    func main() {
        var wg sync.WaitGroup
        wg.Add(1) 
   
        go worker(1, &wg) 
   
        // Main blocks here, guaranteeing the worker finishes its task.
        wg.Wait() 
        fmt.Println("Program complete.")
    }
    // Outcome: The worker runs to completion, the counter reaches zero, 
    // and the program exits cleanly. No leak.
   

2. Preventing Leaks from Unclosed Channels Using WaitGroup with close

    func worker(ch <-chan int) {
        for v := range ch { // here waits forever if channel never closed
            fmt.Println(v)
        }
    }
   
    func main() {
        ch := make(chan int)
        go worker(ch)
        // forgot to close or send
    }
   

   In above leaky example involved a worker blocked on an unclosed channel. WaitGroup can’t fix that specific blocking mechanism, but it can work in conjunction with channel closing to provide robust leak-free concurrency.

   Example: Leak-Free Channel Consumption

   In this the WaitGroup ensures the main function waits long enough for the sender to complete and close the channel, which, in turn, allows the receiver (worker) to exit cleanly.

    package main
   
    import (
        "fmt"
        "sync"
    )
   
    func sender(ch chan<- int, wg *sync.WaitGroup) {
        defer wg.Done() // Signal completion of sending
   
        for i := 1; i <= 3; i++ {
            ch <- i // Send data
        }
        // Critical: Close the channel to signal EOD (End of Data)
        close(ch) 
        fmt.Println("Sender finished and closed channel.")
    }
   
    func receiver(ch <-chan int, wg *sync.WaitGroup) {
        defer wg.Done() // Signal completion of receiving
   
        // This loop will exit gracefully when 'ch' is closed
        for v := range ch { 
            fmt.Println("Received:", v)
        }
        fmt.Println("Receiver finished.")
    }
   
    func main() {
        var wg sync.WaitGroup
        ch := make(chan int)
   
        // Add for BOTH sender and receiver
        wg.Add(2) 
   
        go sender(ch, &wg)
        go receiver(ch, &wg)
   
        fmt.Println("Waiting for all tasks to complete...")
        wg.Wait() // Main waits for both goroutines to call Done()
        fmt.Println("All goroutines completed successfully.")
    }
    // Outcome: Both goroutines finish their work and exit gracefully. No leak.
   

   In this,

   1. sender goroutine sends its data and closes the channel.

   2. the receiver goroutine’s for v := range ch loop detects the close and exits cleanly, calling wg.Done().

   3. The main goroutine is guaranteed to wait until the receiver exits, preventing the program from termination early and leaving the receiver stuck.

Real World Example: Worker Pool Using Channels

This demonstrates how channels help coordinate many goroutines.

package main
import "fmt"

func worker(id int, jobs <-chan int,results chan<- int) {
    for j := range jobs {
        results <- j * 2 // processing
    }
}

func main() {
    jobs := make(chan int ,5)
    results := make(chan int, 5)

    // 3 worker
    for i := 1; i <=3; i++ {
        go worker(i,jobs, results)
    }

    // sending 5 jobs
    for j := 1; j<= 5; j++ {
        jobs <- j
    }
    close(jobs)

    // receiving results
    for r := 1; r <= 5; r++ {
        fmt.Println(<- results)
    }
}

Output

2
4
6
8
10

What is Above Code?

This is a worker pool example a very common concurrency pattern in Go.

• You have multiple worker (goroutines) ready to process jobs.

• Jobs are given through a channel.

• Workers take a job, process it, and send the result back.

This is used in real systems like

• Background job queues

• Web servers

• Task processors

• Email senders

• Image processing pipelines

Setp 1: Worker Function

func worker(id int, jobs <- chan int, results chan <- int) {
    for j := range jobs {
        results <- j * 2
    }
}

What is happening?

1. jobs <- chan int

   This worker can only receive jobs.

2. results chan <- int

   This worker can only send results.

3. for j := range jobs

   Keeps taking jobs until channel closes.

4. results <- j * 2

   “Processing“ the job (multiplying by 2)

Real-World analogy:

Think of these worker as 3 employees sitting in a factory taking tasks (jobs channel) and producing output (results channel)

Step 2: Creating Job and Result Channels

jobs := make(chan int, 5)
results := make(chan int, 5)

• Jobs channel holds up to 5 tasks.

• Results channel holds up to 5 outputs.

This buffer prevents workers from blocking too much.

Step 3: Starting 3 Workers

for i := 1; i <= 3; i++ {
    go worker(i, jobs, results)
}

This starts 3 goroutines, each running the worker function.

Step 4: Sending Jobs

for j: 1: j<=5; j++ {
    jobs <- j
}
close(jobs)

You are giving the workers 5 tasks: 1, 2, 3, 4, 5.

Once all jobs are send, you close the channel t signal

“No more tasks. Finish what you have and exit.“

Without closing, workers would wait forever and cause a deadlock.

Step 5: Receiving Results

for r := 1; r <= 5; r++ {
    fmt.Println(<-results)
}

You collect 5 results because you send 5 jobs.

Workers may complete jobs in any order, because they run concurrently.

Why Is This Example Important?

Because it teaches several core Go concurrency ideas

• Goroutines work independently.

• Channels coordinate data flow.

• Closing channels signals “no more work“

• Multiple goroutines can read from the same channel safely

• Worker pools improve performance automatically.

Let’s understand channel more by taking real world use cases.

Unbuffered Channel - Payment Confirmation System

Imagine you are making a payment on UPI / Paytm / Google Pay.

You press “Pay“, and your app waits until the bank says : Payment Success

It cannot move ahead until it receives a response.

This is exactly unbuffered behaviour.

• App = Sender

• Bank server = Receiver

• Confirmation = Data

• App must wait → It blocks

This ensures strict, synchronised communication.

package main
import (
    "fmt"
    "time"
)

func bankServer(confirm chan string) {
    time.Sleep(2 * time.Second) // Simulate processing
    confirm <- "Payment Successful"
}

func main() {
    confirm := make(chan string) // unbuffered
    fmt.Println("Initiating Payment...")
    go bankServer(confirm)
    // Waiting for confirmation (blocks)
    status := <- confirm
    fmt.Println("Bank Response:",status)
    fmt.Println("Order Placed!")
}

Explaination

1. User clicks pay → request goes to bank.

2. confirm := make(chan string) creates an unbuffered channel.

3. Your app sends the request and waits at:

    status := <-confirm
   

4. Bank server goroutine sleeps for 2 seconds (Payment process simulation)

5. Bank sends confirmation

    confirm <- "Payment Successful"
   

6. Your app resumes and continues processing.

Why Unbuffered is Best

• Payment must not continue without server confirmation.

• Forces Synchronous, guaranteed handover.

• Prevents inconsistency states like

  • Payment done but no order placed

  • Order placed twice

  • Payment timeout errors

Buffered Channel - Logging System

Imagine your service receives hundreds of requests per second.

Every request generates logs:

• “User logged in“

• “Payment initiated“

• “Order created“

If you write logs synchronously (unbuffered)

• Requests must WAIT until the log is written

• Reduces performance

• Causes slow API Response.

Instead, logs are pushed into a buffer, and a background goroutine writes them to file/database.

package main
import (
    "fmt"
    "time"
)

func logWriter(logs <- chan string) {
    for log := range logs {
        time.Sleep(500 * time.Millisecond)
        fmt.Println("Logged:",log)
    }
}

func main() {
    logs := make(chan string, 10) // buffered log queue

    go logWriter(logs)

    for i := 1; i <= 5; i++ {
        fmt.Println("Received request",i)
        logs <- fmt.Sprintf("Request %d processed",i)// fast enqueue
    }
    close(logs)
    time.Sleep(3 * time.Second)
}

Why buffered?

• Logging is slow

• Request processing is fast

• Buffered channel prevents the fast operation from blocking.

Buffered + Unbuffered Hybrid - Video Streaming Pipeline

In Youtube / Netflix video processing

• State 1: Video Upload

• State 2 : Video encoding

• State 3 : Thumbnail generation

These require different channel types

package main

import "fmt"

func uploader(file chan <- string){
    files <- "video1.mp4"
    files <- "video2.mp4"
    close(files)
}

func encoder(file <- chan string, processed chan <- string) {
    for file := files {
        processed <- file + "encoded"
    }
    close(processed)
}

func notifier(processed <- chan string) {
    for p := range processed {
        fmt.Println("Notify user:",p)
    }
}

func main() {
    files := make(chan string, 10) // buffered queue of uploaded videos
    processed := make(chan string)

    go uploader(files)
    go encoder(files,processed)
    notifier(processed)
}

FAQ (Interview - Focused)

1. Why do we need channels if we have goroutine?

   Because goroutines run independently. Channels allow safe communication and synchronization without mutex locks.

2. Are channels thread-safe?

   YES. Channels are fully managed by GO runtime.

3. When to use buffered vs unbuffered channels?

   Unbuffered → synchronization
   Buffered = Improve throughput / decouple sender & receiver

4. Is closing a channel mandatory ?

No. Only needed to signal “no more values will come“. Receivers can range over it.

5. Can a closed channel still send data?

   No → panic.

6. Is it safe to read from a closed channel?
   Yes. You ge the remaining buffered values and then zero-value.

7. Can we close a receive-only channel?

   No. Only senders should close channels.

8. Are channels FIFO?

   Yes. Go guarantees that channels are FIFO.

9. When should I use buffed channels?

   Use buffered channels when:

   • You need async processing.

   • Producers are faster than consumers.

   • Minor queueing is okay.

   • You want rate-limiting or batching

10. When should I use unbuffered channels?

    Use unbuffered when:

    • You need strict hand-off

    • Sync between two goroutines

    • Avoid queueing.

11. How to avoid goroutine leaks?

    • Always close channels when done

    • Use context.Context

    • Avoid infinite blocking receives.

12. Does reading from a nil channel block?

Yes.

    var ch chan int // nil
    <-ch            // blocks forever

13. What happens if no one receives from an unbuffered channel?

    Sending goroutine blocks forever leads to deadlock.

    ch := make(chan int)
    ch <- 10 // <— deadlock: nobody is receiving
    

14. Does closing a channel stop goroutines?

    No. Closing a channel only means:

    • No more sends allowed.

    • Receives will still return value until buffer empties.

    • After that, receives return the zero value

Goroutines don’t stop automatically you must explicitly handle it.

15. Buffered vs Unbuffered — Performance difference ?

    • Unbuffered channels → slow because sender + receiver must meet

    • Buffered channels → faster (asynchronous, less blocking)

16. Can I detect if a channel is full or empty?

    No. Go intentionally hides this to avoid race conditions. You must structure your program so you don’t need to check this.

17. Can channels replace queues or message brokers ?

    For small-scale in-memory concurrency, yes. For distributed systems, no.

    Channels are

    • In-memory

    • Single-process

    • Fast

    • Lightweight

But they cannot repleace kafka, RabbitMQ, NATS, REDIS streams
Use channels for in-process pipelines only.

Conclusion

Channels are one of Go’s most powerful concurrency features. They provide safe communication built-in synchronization, and easy coordination between goroutines without locks. Once you master channels, you unlock the real power of Go’s concurrency model.

Because of its importance, the fmt package is also a common topic in Go interviews, especially around formatting verbs, stringers, and error wrapping.

In this article, we’ll explore:

• What the fmt package does

• Printing functions

• Formatting verbs

• Creating formatted strings

• Scanning input

• Working with writers (Fprint, Fprintln, Fprintf)

• Error wrapping using fmt.Errorf

• Implementing the fmt.Stringer interface

• Width, padding & precision

• Struct, slice & map formatting

• A complete example

This article is ideal for beginners, intermediate developers, and anyone preparing for Go interviews.

What Is the fmt Package?

The fmt package provides a set of functions for:

• Formatted output (printing)

• Formatted input (scanning)

• Working with strings

• Working with I/O streams

• Error creation & wrapping

Import it using:

import "fmt"

Let’s explore everything in detail.

Printing in Go using fmt

fmt.Println() — Print with newline

fmt.Println("Hello", "World")

Output

Hello World

fmt.Print() — Print without newline

fmt.Print("Hello ")
fmt.Print("World")

fmt.Printf() — Formatted output

Uses formatting verbs like %s, %d, %v, etc.

name := "Rohit"
age := 24

fmt.Printf("My name is %s and I am %d year old\n", name,age)

Important fmt Format Verbs

General Verbs

Example:

type User struct {
    Name string
    Age int
}

u := User{"Rohit",24}

fmt.Printf("%v\n",u) // Default format
fmt.Printf("%+v/n",u) // Show struct field names
fmt.Printf("%#v\n",u) // Go-syntax representation
fmt.Printf("%T\n",u) // Prints the type

String Verbs

Number verbs

Building Strings Instead of Printing

Use the Sprintf family when you want to create a string instead of printing it.

fmt.Sprintf

msg := fmt.Sprintf("Hi %s, score: %d","Rohit",90)
fmt.Println(msg)

Writing to Files, Buffers & HTTP Responses — Fprint, Fprintf, Fprintln

These functions write to any io.Writer, not just stdout.

Example: Writing to a file

file,_ := os.Create("outout.txt")
fmt.Fprintf(file,"Hello %s!", "Rohit")

This is widely used in

• Web servers (http.ResponseWriter)

• Logging systems

• Buffers

• Files

Reading Input — Scan ScanIn, Scanf

fmt.Scan — space-separated input

var name string
var age int
fmt.Scan(&name,&age)

fmt.ScanIn (stops at newline)

var city string
fmt.Scanln(&city)

fmt.Scanf (formatted input)

var name string
var age int
fmt.Scanf("%s %d",&name,&age)

Error Handling with fmt.Errorf

creating errors

err := fmt.Errorf("invalid input")

Wrapping errors using %w

err := fmt.Errorf("db error: %w", originalErr)

Then unwrap

errors.Is(err,originalErr)

I have explained this error handling in detail in this article → https://blog.rohitlokhande.in/error-handling-in-go

Implementing fmt.Stringer — Customize Struct Printing

fmt.Stringer is an interface

type Stringer interface {
    String() string
}

Implement it on your struct:

type User struct {
    Name string
    Age int
}

func (u User) String() string {
    return fmt.Sprintf("User(Name=%s, Age=%d)",u.Name, u.Age)
}
func main() {
    u := User{"Rohit", 24}
    fmt.Println(u)
}

User(Name=Rohit, Age=24)

Formatting Width, Alignment,Padding & Precision

Width

fmt.Printf("|%10s|\n", "Go") // right-aligned
fmt.Printf("|%-10s|\n","Go") // left-aligned

Zero-padding

fmt.Printf("%05d\n",42) // 00042

Floating precision

fmt.Printf("%.2f\n",3.14159) // 3.14

Formatting Structs, Maps, Slices

user := map[string]string{"name":"Rohit"}
fmt.Printf("Map:%+v\n",user)

Output

Map:map[name:Rohit]

Using fmt With Buffers (io.Writer)

What is Buffer?

A buffer is a temporary storage area in memory used to hold data before it is processed, written, or read.

Think of a buffer like a bucket.

• You collect some data in the bucket (buffer).

• Once enough data is collected or when ready, you pour it out (write it somewhere).

• This avoids sending small pieces one by one.

Buffers help make input/output operations faster and more efficient.

Why Do We Need Buffers?

Because reading or writing small amounts of data very frequently is slow.

Example:

• Writing to a file every time you add a character will slow down the process.

• Instead, write to a buffer in memory and then flush it to a file in larger chunks. This speeds up the process.

import (
    "fmt";
    "bytes"
 )
var b bytes.Buffer
fmt.Fprintln(&b,"Hello Buffer")
fmt.Println("Buffer content:",b.String())

We have covered the basic concepts of the fmt package, which are widely used. There are also some less common but useful concepts that we will explore further.

fmt.GoStringer Interface

fmt.GoStringer is an interface similar to fmt.Stringer, but it is used when formatting a type using:

• %#v (Go-syntax representation)

• fmt.GoString()

Interface definition:

type GoStringer interface {
    GoString() string
}

If your type implements GoString() string, then %#v will call your custom method.

Example:

package main

import (
    "fmt"
)

type User struct {
    Name string
    Age  int
}

// Implementing GoStringer
func (u User) GoString() string {
    return fmt.Sprintf("User{Name: %q, Age: %d}", u.Name, u.Age)
}

func main() {
    u := User{"Rohit", 24}

    fmt.Println("Normal print:")
    fmt.Println(u) // does NOT use GoString

    fmt.Println("\nGo-syntax print using %#v:")
    fmt.Printf("%#v\n", u) // uses GoString()
}

Output

Normal print:
{Rohit 24}

Go-syntax print using %#v:
User{Name: "Rohit", Age: 24}

What happening here?

fmt.Println(u) → Uses the default structure formatting because we did not implement Stringer.

fmt.Printf("%#v", u) → Now Go sees that User implements the GoString() string method, so it prints the custom Go-like struct representation.

Why do we need GoString?

fmt.Stringer is for human-readable output.

fmt.GoStringer is for debugging, logging, and developer-friendly Go syntax output.

fmt.Appendf, Append, Appendln

These functions were added to Go to make it easier to append formatted data to a byte slice without using a bytes.Buffer or strings.Builder.

That means instead of

b := []byte{}
b = append(b,fmt.Sprintf("Hello %s",name))

You can directly do:

b = fmt.Appendf(b, "Hello %s", name)

fmt.Append

• Similar to fmt.Sprint.

• Converts arguments to string form.

• Appends to a byte slice,

• No formatting verbs required.

Example

package main
import (
    "fmt"
)

func main(){
    b := []byte("Start: ")
    b = fmt.Append(b,"Hello"," ",124)
    fmt.Println(string(b))
}

Output

Start: Hello 123

fmt.Appendln

• Similar to fmt.Sprintln.

• Appends arguments with spaces and a newline

Example

package main
import "fmt"

func main() {
    b := []byte{}
    b = fmt.Appendln(b,"Hello","world")
    b = fmt.Appendln(b,10, 20, 30)
    fmt.Println(string(b))
}

Output

Hello World
10 20 30

fmt.Appendf

• Similar to fmt.Sprintf

• You can use formatting verbs (%d,%s,%v etc)

Example

package main

import "fmt"

func main() {
    b := []byte("User: ")

    b = fmt.Appendf(b, "%s (%d years old)", "Rohit", 25)

    fmt.Println(string(b))
}

Output

User: Rohit (25 years old)

When to Use Append Functions?

These functions are useful when:

• You want zero allocation or minimal memory overhead.

• You want a lightweight alternative to bytes.Buffer.

• You want to efficiently build output in a byte slice.

• High-performance systems (servers, loggers, serializers).

FAQ: Frequently Asked Questions About Go’s fmt Package

1. What is the fmt package used for in Go?

   The fmt package is used for formatted I/O operations such as printing to the console, formatting strings, scanning input, and writing to buffers or byte slices. It provides functions like Println, Printf, Sprintf, Scan, and more.

2. What is the difference between Print, Println, and Printf?

3. What are formatting verbs in fmt?

   Formatting verbs are special placeholders (e.g., %d, %s, %v) used to format data.

   Example:

   • %s → string

   • %d → integer

   • %f → float

   • %v → value in default format

4. What is fmt.Stringer and why is it important

   fmt.Stringer is an interface with the method → String() string.
   If a type implements this method, fmt uses it to decide how that type should be printed.
   This is very helpful in debugging and logging.

5. What is fmt.GoStringer?

   fmt.GoStringer is an interface for generating Go-syntax-friendly output.

   It uses the GoString() string interface.

   This result is used when formatting with %#v.

6. What’s the difference between bus := bytes.Buffer{} and using fmt functions?

7. What are fmt.Append, Appendf, and Appendln ?

   These functions append formatted data directly to a byte slice.

   • Append → like Sprint

   • Appendln → like Sprintln

   • Appendf → like Sprintf

They are faster and avoid extra allocations, making them useful in logging or serialization.

8. Is fmt package slow compared other manual string concatenation?

   fmt is extremely optimised, but

   • It is slower than direct concatenation (+)

   • It is slower than strings.Builder

   • It is slower than bytes.Buffer

However, it providers:

• cleaner code

• safe formatting

• powerful formatting verbs

For performance-critical sections, avoid using fmt in tight loops.

9. What happens if formatting verbs don’t match the data type?

   fmt does not crash, unlike other languages. Instead, it prints a fallback format.

   Example:

    fmt.Printf("%d","hello")
   

    %!d(string=hello)
   

10. Can fmt print coloured output?

    No. fmt does not support ANSI colors. Use third-party libraries such as

    • github.com/fatih/color

    • github.com/mgutz/ansi

11. Why should I implement String() for custom structs?

    Because:

    • Your logs become cleaner

    • Your debugging becomes easier

    • fmt.Printf(“%v“) output readable data

Conclusion

The fmt package is one of the first tools every Go developer learns—and for good reason. It simplifies printing, formatting, scanning, and working with different data types. From basic functions like Println to advanced features like Stringer, formatting verbs, and the new Append functions, fmt makes everyday coding much easier and more readable.

If you understand how fmt works, you can write cleaner logs, better debug your programs, and format data more effectively. It’s a small package, but it plays a big role in every Go project.

But then comes Go, with a fresh take—simple, efficient, and elegant concurrency.
The magic ingredient? Goroutines.

In this post, we’ll break down how goroutines work, how they differ from threads or processes, and why Go’s approach is a game-changer for modern developers.

Before diving into goroutines, let's first understand multithreading and multiprocessing. I have created a separate blog for this, so check it out before moving forward.

👉 Multiprocessing vs Multithreading: Understanding Concurrency and Parallelism

If you've read that, let's move on to goroutines now.

What Are Goroutines?

A goroutine is a function that runs at the same time as other functions. You start one by adding the go keyword before a function call.

Example:

package main
import (
    "fmt"
    "time"
)

func printMessage(msg string) {
    for i := 1; i <= 3; i++ {
        fmt.Println(msg,i)
        time.Sleep(500 * time.Millisecond)
    }
}

func main() {
    go printMessage("Goroutine") // run concurrently
    printMessage("Main Function")
}

Output (order may vary)

Main Funtion 1
Goroutine 1
Main Function 2
Goroutine 2
Main Function 3
Goroutine 3

What’s happening here?

• The main function runs in the "main goroutine."

• go printMessage() creates a new concurrent goroutine.

• Both functions run concurrently — the interleaved output confirms that.

How Goroutines Differ From Multithreading in Other Languages

1. The core difference — who schedules work?

   Threads (Java/C++/pthreads):

   • Typically, there is a 1:1 mapping between a language thread and an OS thread.

   • The operating system kernel schedules threads onto CPU cores using its scheduler.

   • Creating a thread is relatively expensive — it involves memory and kernel bookkeeping.

   • The OS decides when to run, pause, or preempt each thread.

Goroutines:

• Go runtime uses a sophisticated work-stealing scheduler (M:N model) to distribute goroutines efficiently across the available CPU cores or OS threads maximising CPU utilisation and minimising the overhead of context switching.

• The M:N model is a scheduling approach used by the Go runtime to efficiently manage many goroutines (M) with a smaller, fixed number of operating system threads (N).

• In simple terms it’s like a team of highly adaptable workers (goroutines) sharing a fixed set of desks (OS threads) in an office.

Implication: Goroutines are extremely cheap to create and schedule compared to OS threads, allowing programs to scale to thousands or millions of concurrent tasks.

2. Memory cost and stacks

   OS Threads:

   • Each thread usually reserves a relatively large stack — often 1MB or more depending on the platform.

   • Creating many threads can quickly exhaust memory.

Goroutines:

• Start with a tiny stack — on the order of a few KB.

• Stacks grow and shrink dynamically as needed; the runtime transparently allocates a larger stack and copies frames.

• Because each goroutine consumes far less memory initially, creating thousands is feasible.

Why this matters: Goroutines let you model many independent tasks without paying huge memory costs per task.

3. Scheduling M:N work-stealing and GOMAXPROCS

   The M:N scheduling model in Go (many goroutines onto fewer OS threads) can be easily understood using a chef and kitchen analogy.

   Imagine a busy restaurant kitchen with:

   • Many Recipes/Orders (M) = Goroutines: There are potentially thousands of incoming food orders (goroutines), each representing a task that needs to be completed.

   • A Few Stoves/Cooking Stations (N) = OS Threads (CPU cores): The kitchen only has a limited number of physical cooking stations or stoves (OS threads) where actual cooking (CPU work) can happen simultaneously.

   • The Head Chef = The Go Runtime Scheduler: A highly efficient head chef manages the flow of orders and assigns them to the available cooking stations.

How the M:N Model Works

• Assigning Orders: The head chef gives an order to one of the assistant chefs at an empty cooking station.

• Handling “Waiting” (Blocking I/O): An assistant chef is working on a complex dish that requires 10 minutes to simmer unattended (a “blocking I/O” operation, like waiting for a database response).

• The Efficient Switch: The head chef immediately tells that assistant chef to step aside while the food simmers. The head chef then gives a new order to that now-empty cooking station. The original assistant chef returns to the station only when the 10 minutes are up and the dish needs attention again.

• Balancing Work: The head chef continuously monitors all stations, ensuring no station sits idle if there are orders waiting. If one station gets a backlog, the chef might even move orders to another, less busy station (work stealing).

What is Work-Stealing?

Imagine 4 chefs (P1, P2, P3, P4), each with their own queue of tasks (Gs).

If P1 finishes its work but P2 still has 20 tasks:

P1 takes some goroutines from P2’s queue to balance the load.

This keeps any CPU core from being idle.

In simpler words:

Idle Ps take work from busy Ps to keep the CPU fully utilized.

What is GOMAXPROCS?

GOMAXPROCS(n) sets how many Ps exist — i.e., how many OS threads can run Go code at the same time.

Default = number of CPU cores.

What is Preemption?

Imagine one task keeps running forever, like an infinite loop. Other tasks would never run unless Go can interrupt it. This is what preemption does: the scheduler interrupts a long-running goroutine to give others a turn. Because of this, no goroutine can hog the CPU forever.

Real-World Example — Concurrent Web Requests

package main
import (
    "fmt"
    "net/http"
)
func fetch(url string) {
    resp, err := http.Get(url)
    if err != nil {
        fmt.Println("Error fetching:", url)
        return
    }
    defer resp.Body.Close()
    fmt.Println(url, "->",resp.Status)
}

func main() {
    urls := []string{
        "https://golang.org",
        "https://google.com",
        "https://github.com",
    }
    for _, url := range urls {
        go fetch(url) // fetch all concurrently
    }
    fmt.Scanln() // block main goroutine
}

https://golang.org -> 200 OK
https://google.com -> 200 OK
https://github.com -> 200 OK

• All three requests run concurrently

• The program doesn't wait for one request to finish before starting another.

• This is Go’s concurrency power — simple syntax, massive performance gain.

Let’s understand this code using a kitchen analogy.

In this analogy:

• main() function: The owner of the restaurant.

• fetch() function: A detailed recipe for preparing one specific dish (fetching a URL).

• go fetch(url): Handling an order ticket to the head chef and asking for a dish to be prepared immediately.

• The websites (golang.org, etc.): Suppliers with whom the kitchen must communicate.

• fmt.Scanln(): The restaurant owner waiting patiently at the counter until all orders are confirmed complete.

1. Setting Up the Restaurant (The main function start)

    func main() {
        urls := []string{
            "https://golang.org",
            "https://google.com",
            "https://github.com",
        }
        // ...
    }
   

   The restaurant owner (the main function) writes down three specific orders on tickets: one for golang.org soup, one for google.com salad, and one for github.com steak.

2. Handling Off Orders to the Kitchen (The go keyword)

    for _,url := range urls {
        go fetch(url) // fetch all concurrently
    }
   

   The owner takes all three order tickets and hands them to the Head Chef (the Go Runtime Scheduler) simultaneously: “Start cooking all of these now!”

   The go keyword is crucial here. It tells the head chef to use the M:N scheduling model:

   • Each fetch(url) call becomes a separate recipe/order (goroutine).

   • The head chef immediately assigns these recipes to the available cooking stations (OS threads) in the kitchen.

3. Preparing a Single Dish (The fetch function)

    func fetch(url string) {
        resp, err := http.Get(url)
        // ...
    }
   

   This is where the magic of the M:N model happens:

   • Calling the Supplier (http.Get(url)): The assistant chef at a cooking station starts preparing the dish but immediately finds they need a specific ingredient from a supplier (making a network request).

   • The Head Chef Manages the Wait: The supplier is slow to respond (the network I/O is blocking). Instead of letting the assistant chef just stand there idly, blocking the entire cooking station, the Head Chef (Go Scheduler) switches them out.

   • Efficient Kitchen Use: The original assistant chef goes to wait by the back door for the supplier delivery. The cooking station they were using is immediately assigned to another recipe that is ready for CPU work. This keeps all stations busy!

   • Finishing the Dish (fmt.Println(…)): Once the supplier arrives with the data, the assistant chef returns to an available station and confirms the order status.
     (“https://golang.org“ → 200 OK)

4. The Owner Waits for Confirmation (fmt.Scanln())

     fmt.Scanln() // block main goroutine
   

   This line is necessary because the restaurant owner (main function) needs to stay in the building until all three orders are confirmed and served.

   Without this line, the owner would hand the tickets to the chef and immediately leave the restaurant, shutting everything down before the dishes are even started. (We are not using fmt.Scanln() here; there are other alternatives for this condition, which we will learn about later.)

In this analogy

And the assistant chefs are also part of the OS Threads (Cooking stations).

• OS Thread is the combination of the physical cooking station (the hardware resource) and the assistant chef working at it (the execution mechanism)

• The Head Chef (Go Runtime Schedular) is the management layer above the assistant chefs, telling them which recipes (goroutines) to work on.

Multiprocessing in Go

Go doesn’t provide true multiprocessing directly, but it achieves similar benefits using goroutines and OS threads. The Go runtime automatically schedules goroutines across multiple CPU cores using the GOMAXPROCS setting.

This means:

• Go can run goroutines in parallel on different CPU cores.

• The runtime handles thread creation, scheduling, and load balancing for you.

• Developers get parallel execution without manually managing processes or threads.

So even though you don’t explicitly create “processes,” Go delivers multiprocessing-like performance through its efficient runtime scheduler.

FAQ Section

1. Are goroutines the same as threads?

   No. Goroutines are not OS threads. They are lightweight functions managed by the Go runtime scheduler. Multiple goroutines run on top of a smaller set of OS threads.

2. How many goroutines can I run at once?

   Usually hundreds of thousands or even millions, depending on RAM. Threads cannot scale anywhere close to this.

3. Does each goroutine use its own thread?

   No. Goroutines are multiplexed onto a pool of worker threads using Go’s M:N scheduler. Multiple goroutines share a single thread (not simultaneously, but with fast switching).

4. Is Go single-threaded or multithreaded?

   Go is multithreaded under the hood. Your program uses multiple OS threads automatically; you don’t need to manage them.

5. Are goroutines good for CPU-intensive tasks?

   Yes, but you must understand that all CPU-bound goroutines compete for CPU cores. For heavy CPU work, increasing runtime.GOMAXPROCS() may help.

6. Do goroutines run in parallel?

   If your machine has multiple CPU cores, then yes, goroutines run in parallel. If not, they run concurrently (taking turns), but still efficiently.

7. Why are goroutines so lightweight?

   Because they use:

   • a tiny initial stack (2 KB).

   • dynamic stack resizing.

   • a user-space scheduler.

   • cooperative + async preemption.

Conclusion

Goroutines make concurrency in Go simple, lightweight, and incredibly scalable. Instead of dealing with heavy OS threads, Go gives you tiny, fast goroutines managed by an efficient runtime scheduler. This allows you to run thousands or even millions of concurrent tasks with minimal memory and almost no complexity.

What’s Next?

Now that goroutines are clear, the next step is understanding how they communicate and synchronize.
Up next, we’ll cover:

• Channels - How goroutines safely exchange data

• Select — handling multiple concurrent operations

• WaitGroup & Mutex - essential sync tools

• Real patterns like worker pools and pipelines.

This will complete your core understanding of Go’s concurrency model.

When we talk about performance in programming, terms like concurrency, parallelism, multithreading, and multiprocessing often come up together. They sound similar, but they describe different ways of doing multiple things at once.

We’ll break down these concepts in depth—how they work, how they differ, and when to use each.

The Core Idea: Doing Multiple Things at Once

Before diving into threads and processes, let's start with the core concept of doing more than one thing at the same time.

There are two main strategies to achieve this:

• Concurrency:

  Structuring your program so it can handle multiple tasks seemingly at the same time.

• Parallelism:

  Actually executing multiple tasks simultaneously using multiple CPUs or cores.

These two often overlap but are not the same thing.

Concurrency vs Parallelism: The Foundation

Concurrency

Concurrency means handling multiple tasks in overlapping time periods, not necessarily simultaneously.

Imagine a download manager that’s responsible for downloading five large files.
If your internet connection can only handle one download at a time, the manager might download a chunk from file 1, then switch to file 2, then file 3, and so on—cycling rapidly between them.

To you, it feels like all files are downloading at once, but in reality, the system is just switching quickly between tasks.

Concurrency is about efficient task-switching.

Even if only one task runs at any given moment, all of them make progress over time. In programming, concurrency.

In programming, concurrency is especially useful for I/O bound operations like making API calls, reading files, and waiting for network responses, where tasks spend most of their time waiting rather than computing.

Parallelism

Parallelism means doing multiple things truly at the same time.

Now, imagine that same download manager, but you have multiple network connections or threads, each downloading a file simultaneously.
In this case, all files are actively downloading in parallel, and there’s no switching involved.

Parallelism is about simultaneous execution using multiple cores or processors.

Parallelism is ideal for CPU-bound workloads, such as heavy computations like image rendering, large data processing, or complex simulations.

The image above illustrates that in concurrency, there is 1 chef (or 1 core) switching tasks back and forth. On the other hand, in parallelism, there are 3 different chefs (or 3 cores) working on different tasks at the same time.

What is Multithreading?

A thread is the smallest unit of execution within a process. By default, a program runs as a single main thread, executing code sequentially.
Using multithreading, we can create multiple threads that share the same memory space and work concurrently.

Example

Let’s say you’re building a web server in Go:

• One thread handles incoming HTTP requests.

• Another logs data to a file.

• A third manages background jobs.

Each thread runs independently, yet all share access to the same data and memory.

Advantages of Multithreading

• Threads are lightweight and fast to create.

• They share memory, making communication simple.

• Perfect for I/O-bound tasks like handling multiple web requests.

Drawbacks of Multithreading

• Shared memory can cause race conditions (two threads updating the same variable).

• Requires synchronization mechanisms (mutexes, locks).

• In some languages like Python, the Global Interpreter Lock limits true parallelism with threads.

What is Multiprocessing?

Multiprocessing takes a different approach; it runs multiple processes, each with its own memory and interpreter instance. They don’t share memory space, so they’re fully isolated and can run on different CPU cores.

Example:
When exporting a video in tools like Premiere Pro, Final Cut, or FFmpeg, the renderer splits the video into chunks and processes them simultaneously on multiple CPU cores.
Why multiprocessing?
Each chunk is CPU-heavy and independent. More cores = faster rendering.

Advantages of Multiprocessing

• True parallel execution across multiple cores.

• Each process has isolated memory, so there are no race conditions.

• Great for CPU-intensive workloads.

Drawbacks

• More overhead for creating and managing processes.

• Harder to share data (requires inter-process communication).

• Inter-process communication is slower than thread communication.

How Many Threads Can You Spawn?

This is one of the most misunderstood topics.
Developers try creating

• 1000 threads

• 10000 threads

And then wonder why the system slows down.

Let's break it down.

Thread Creation Depends on 2 Things

1. Memory

   Each thread needs its own stack.

   Default stack size:

   • Linux: 8 MB

   • Windows: 1 MB

   • Java: 1 MB

   • Python: 8 MB

   • Go Goroutines: 2 kB

2. OS Thread Limit

   Linux allows tens of thousands of threads
   Windows/macOS allow fewer (2000 - 10000)

Max Threads Formula

Max Threads = Total Memory / Thread Stack Size

Example:
If you have 32 GB RAM and threads require 8 MB stack

32768 MB / 8 MB = 4,096 threads

So theoretically you could spawn nearly 4000 threads.
But you should not.

Why You Shouldn’t Spawn Thousands of Threads

• Context switching

• Cache invalidation

• CPU time slice overhead

• Kernel thrashing

Beyond a certain point, more threads lead to worse performance.

How Many Threads Should You Spawn?

CPU-Bound Tasks

Example

• Image processing

• Compression

• Encryption

• Encoding

Optimal threads = number of CPU cores
If you have 8 cores → 8 threads.

More threads won’t increase speed.

I/O Bound Tasks

Example

• API calls

• DB queries

• File reading

• Network operations

Threads spend most of the time waiting, so you can use many more.

Formula:

Optimal threads = Cores * (1 + (IO wait / compute time))

Example:
Task waits 90% of the time

8 cores * (1 + 0.9/0.1) = 80 threads

Real Example: Web Scraper

Scraping 5000 URLs

• CPU usage is low

• Network wait is high

In this scenario, you can safely create 100-300 threads, or in Go, you can create 10,000+ goroutines.

Let's explore multithreading further by looking at real-world scenarios, such as how the system will perform when we run a "Reading 100 files" operation using a single thread versus multithreading.

Let’s say you write a program that needs to read 100 files from disk.

Reading a file is usually I/O-bound because:

• The thread asks the OS: “Please fetch file contents.”

• The OS works with storage hardware.

• The thread waits for disk I/O to finish.

So the real difference between single-threading and multithreading becomes HUGE.

Using Single Thread

In a single-threaded program:

1. The thread starts reading File 1

2. It waits for the disk to respond

3. When done, it moves to File 2

4. Waits again

5. File 3

6. Waits again

This is repeated for all 100 files. Only one file is being processed at any moment.

In the diagram above, using a single-thread approach, the thread is blocked and cannot do anything else during the wait time. Files are processed one after another.

This is simple but slow.

Using Multithreading

Now suppose we create 10 threads to read 100 files.

Each thread gets 10 files. So instead of reading files one by one, it reads like

In this,

• while Thread 1 waits for File 1, Thread 2 reads File 2.

• Thread 3 reads File 3, and so on.

So 10 files are being fetched I/O parallel, even on a single core — because disk I/O waits do not block other threads.

How They Look in Real Performance Terms

Single Thread

Total time = (Time to read 1 file) * 100

10 Threads

Total time = (Time to read 10 files in parallel batches)

If reading 1 file takes 30ms:

• Single thread → 100 × 30ms = 3,000 ms

• 10 threads → (100/10) × 30 ms = 300 ms

Notice the performance improvement with multithreading, which results in 10 times less time.

When One Thread Finishes Early but Other Threads Are Still Working

In a real-world multithreaded system, it’s very common for one thread to complete its work earlier than the others. This situation has an official name:

👉 It’s called Load Imbalance.

This happens when different threads do not get an equal amount of work, causing:

• Some threads to finish early.

• Some threads to keep working.

• CPU cores to remain partially idle.

• Total execution time to be determined by the slowest thread.

But what happens next depends on the threading model your program uses. Here’s how it plays out in practice.

1. Static Assignment → Idle Threads (Bad Scenario)

   In simple or naive multithreading designs, each thread gets a predefined chunk of work.

   Example:

   • Thread 1 → Files 1-25

   • Thread 2 → Files 26-50

   • Thread 3 → Files 51-75

   • Thread 4 → Files 76-100

If Thread 1 finishes early, it has nothing else to do.

• This is called Thread Idle Time

• The root cause is Load Imbalance

• The CPU core remains underutilized

• The program finishes when the slowest thread completes.

This is why static splitting is rarely used today for large workloads.

2. Dynamic Task Queue → Automatic Load Balancing (Good Scenario)

   Modern thread pools do not pre-assign tasks. Instead, all tasks are placed in a shared global queue.

   Each thread:

   • Takes a task

   • Executes it

   • Returns for more

👉 It simply grabs the next available task.

This technique is called Dynamic Load Balancing, Work Queue Model

Result:

• No idle threads

• All threads stay active

• Tasks finish at roughly the same time

• Total execution time is much shorter

3. Work-Stealing Scheduler → Smart Redistribution (Best Scenario)

   Go, Rust, Java ForkJoinPool, and modern runtimes use an even more advanced strategy:

   Work Stealing.

   Each thread has its own deque of tasks.

   If a thread finishes early:

   👉 It “steals” remaining tasks from other threads.

   This eliminates load imbalance almost entirely.

   Benefits:

   • Highly efficient

   • Minimizes idle time

   • Perfect for large, uneven workloads

   • Powers Go’s goroutines scheduler.

Conclusion

Concurrency is about handling multiple tasks at once, while parallelism is about executing them simultaneously. Multithreading is ideal for I/O-heavy tasks, whereas multiprocessing is best for CPU-heavy workloads that benefit from true parallel execution.

Modern runtimes use dynamic load balancing and work-stealing to avoid load imbalances, ensuring that threads don’t sit idle when others are still working. Choosing between threads, processes, or asynchronous patterns depends entirely on your workload, not on which technique is faster.

In this blog, we’ll dive deep into how Go handles errors, why this approach is brilliant, and how to master it in your code.

Understanding the error type

In Go, error is just an interface:

type error interface {
    Error() string
}

That’s it.
Any type that has an Error() method returning a string qualifies as an error.
This simplicity gives developers complete control over how errors are represented and handled.

Returning Errors from Functions

In Go, functions often return two values: one is the expected result, and the other is an error.

package main
import (
   "errors"
   "fmt"
)
func divide(a,b float64) (float64, error) {
    if b == 0 {
        return 0, errors.New("cannot divide by zero")
    }
    return a / b, nil
}

func main() {
    result, err := divide(10,0)
    if err != nil {
        fmt.Println("Error:", err)
        return
    }
    fmt.Println("Result:",result)
}

Output:

Error: cannot divide by zero

This pattern → value, err := function() is everywhere in Go.

It may seem verbose at first, but it makes error handling predictable and explicit. You always know which operations can fail and how they’re handled.

Creating Custom Error Types

Go allows you to define custom errors for more meaningful messages.

type DivideError struct {
    Dividend float64
    Divisor float64
    Message string
}

func (e *DivideError) Error() string {
    return fmt.Sprintf("cannot divide %.2f by %.2f: %s", e.Dividend, e.Divisor, e.Message)
}

func divide(a,b float64) (float64, error) {
    if b == 0 {
        return 0, &DivideError{a,b,"division by zero"}
    }
    return a / b, nil
}

Wrapping and Unwrapping Errors

The problem wrapping solves

When an error occurs deep in your call stack, you usually want to:

• Return the original error so callers can detect it, and

• Add context so logs/debugging are helpful

This lets you do both: attach context while preserving the original error for detection.

How to wrap an error

Use fmt.Errorf with the %w verb:

import (
    "errors"
    "fmt"
)
func readConfig() error {
    return errors.New("file not found")
}
func load() error {
    if err := readConfig(); err != nil {
        return fmt.Errorf("load failed: %w", err) // wrap
    }
    return nil
}

%w creates a wrapped error that keeps the original error inside.

Important: use %w (not %v) when you want the error to be unwrappable.

How to check wrapped errors

Use errors.Is to compare against the original error (or sentinel)

err := load()
if errors.Is(err, errors.New("file not found")) { // this won't match sentinel created here
    // BAD: errors.New returns a new value; comparison fails.
}

A better pattern is to have a package-level sentinel or typed error:

var ErrNotFound = errors.New("file not found")

func readConfig() error {
    return ErrNotFound
}

// later
if errors.Is(err, ErrNotFound) {
    fmt.Println("config missing")
}

errors.Is(err, target) walks the chain of wrapped errors and returns true if any match.

Typed errors and errors.As

If you have richer error types (structs), use errors.As to extract them.

type MyErr struct {
    Code int
    Msg string
}
func do() error {
    return &MyErr{Code: 42, Msg: "boom"}
}
func (e *MyErr) Error() string {
    return fmt.Sprintf("Code %d: %s", e.Code, e.Msg)
}
func main() {
    err := do()
    var me *MyErr
    if errors.As(err, &me) {
        fmt.Println("Got MyErr with code:",me.Code)
    }
}

errors.As finds the first error in the chain that can be assigned to the provided type.

How errors.As() uses the pointer

errors.As() works by attempting a type assertion internally.

• It checks the type of the incoming error (err).

• If the types match (i.e., err is a *MyErr), errors.As() needs a way to write the actual error data into a variable you control.

• By passing &me (which is a pointer to your pointer variable me), you are giving errors.As() the memory address where it should store the found error value.

Unwrapping manually

You can get the wrapped error directly.

w := fmt.Error("top %w", ErrorNotFound)
fmt.Println(errors.Unwrap(w)) // prints ErrNotFound

Now let's understand this wrapping and checking process with a complete example.

package main

import (
    "errors"
    "fmt"
)
var ErrorNotFound = errors.New("not found")

func readConfig() error {
    return ErrNotFound
}

func load() error {
    if err := readConfig(); err != nil {
        return fmt.Errorf("load config: %w", err)
    }
    return nil
}

func run() error {
    if err := load(); err != nil {
        return fmt.Errorf("run failed: %w", err)
    }
    return nil
}

func main() {
    if err := run(); err != nil {
        fmt.Println("error:", err) // prints full wrapped message
        if errors.Is(err,ErrNotFound) {
            fmt.Println("detect not found")
        }
    }
}

Expected output:

error: run failed: load config: not found
detect not found

You get the full human-readable context plus the ability to detect the original error programmatically.

Panic & Recover

What is Panic?

Panic stops normal execution and begins to unwind the stack, running deferred functions as it goes. It’s intended for programmer errors or truly unrecoverable conditions, not for normal error handling.

Example triggers:

• index out of range

• nil pointer deref

• explicit panic(“bad state“)

Recover: how to catch a panic

recover() can regain control only if it is called inside a deferred function on the same goroutine where the panic occurred.

If recover() returns non-nil, the panic is stopped, and normal execution resumes after that deferred function returns.

Important: recover() does not work across goroutines.

Basic pattern: graceful recovery at the boundary

Common usage: put a defer + recover() near the top-level of goroutine (HTTP handler, worker, CLI entry point) to prevent a panic from crashing the whole process and to transform it into an error or log.

func safeRun() {
    defer func() {
        if r := recover(); r != nil {
            fmt.Println("recovered from panic:",r)
            // optional: log stack trace: debug.PrintStack()
        }
    }()

    // Code that might panic
    mustDo()
    fmt.Println("safeRun completed")
}

If mustDo() panics, the deferred function sees it and recovers. The program continues, and you can convert the panic to a meaningful error.

Now that we understand what panic and recover are and how to use them, the next question is when does recover() return nil and when does it not? Let's explore that.

When recover() returns non-nil

It returns non-nil only when:

• a panic is currently in progress in the same goroutine,

• and you call recover() inside a deferred function.

That’s the only time recover actually “catches” a panic.

package main
import "fmt"
func main() {
    defer func() {
        if r := recover(); r != nil {
            fmt.Println("Recovered from panic:",r)
        }
    }()
    fmt.Println("Before panic")
    panic("Something went wrong!")
    fmt.Println("Before panic") // never runs
}

Output for above code

Before panic
Recovered from panic: Something went wrong!

Here, recover() returns "Something went wrong!" (the panic value), which is non-nil.

When recover() returns nil

There are three main cases when recover() returns nil

1. No panic is happening

   If you just call recover() normally—not during a panic—it always returns nil.

    func main() {
        fmt.Println(recover()) // nil - no panic is happening
    }
   

2. You call recover() outside a deferred function

   Recover only works when called from within a defer.

   If you call it outside, even if a panic happened earlier, it won’t stop the panic.

    func main() {
        panic("Boom!")
        fmt.Println(recover()) // never runs
    }
   

   This never runs—the program crashes because recover() must be inside a deferred function to intercept the panic.

3. Recover is in a defer but not executed during that panic

If your function has multiple defers, only those active during the panic’s unwinding can recover it.

func demo() {
    defer fmt.Println("First defer") // this runs
    defer func() {
        fmt.Println("Second defer - no panic now")
        fmt.Println("Recover here:", recover()) // returns nil
    }()
}

func main() {
    demo()
}

Second defer - no panic now
Recover here: <nil>
First defer

There’s no active panic when the defer runs, so recover() returns nil.

The last declared defer function will execute first.

Easy way to remember

recover() works only once, and only when it’s called inside a deferred function during the panic unwind.

If you call it:

• too early (no panic yet) → nil

• too late (panic already recovered or finished) → nil

• outside defer → nil

When to use panic + recover

• Use panic for programmer mistakes or invariant violations, e.g., impossible states.

• Use panic for unrecoverable system-level errors if the right thing is to crash, then rely on supervisors like systems or Kubernetes to restart.

• Use recover near goroutine boundaries to prevent a single goroutine panic from killing the whole process and convert panic into an error if appropriate.

• Don’t use panic for ordinary error handling—use error returns.

Real-World Use Cases for panic + recover

1. Graceful recovery in long-running servers like web servers

   Scenario:

   In production systems, e.g., web APIs and background workers, a single handler might panic because of a bug, nil pointer, or invalid operation.
   If we let that panic crash the entire process, it would take down the whole server.

   So, we use recover in middleware to catch panics per request, log them, and keep the server alive.

2. Handling unexpected panics in goroutines

   When you launch multiple goroutines, a panic in one goroutine doesn't automatically crash others, but if it happens in the main goroutine, it kills the program.

3. In frameworks and libraries

   When you build reusable libraries or frameworks like a task runner, job scheduler, or web framework, you often want to protect user-defined callbacks.

   If user code panics, your library should recover and report it as an error instead of dying.

Go’s Error Handling Philosophy

Go’s designers had one goal in mind — clarity and simplicity.
By making errors explicit, they eliminated the hidden complexity that comes with exception handling systems.

You’ll often see this idiom:

if err != nil {
    return err
}

At first, it may seem repetitive, but this repetition ensures predictability.
No hidden stack traces. No silent skips. Just clean, explicit logic.

Go vs Other Languages

Before wrapping up this blog, let's compare this with an example in JavaScript and Go to understand the differences.

Let’s take the scenario of fetching user data and saving it to a database.

We’ll build a small imaginary flow:

1. Fetch user data from an API

2. Validate it

3. Save it to a database

We’ll see how this looks in JavaScript (with try/catch) and Go (with explicit error handling).

Javascript Version (with async/await and try/catch)

async function fetchUser(id) {
  if (!id) throw new Error("Invalid user ID");
  // simulate API fetch
  return { id, name: "Alice" };
}

async function validateUser(user) {
  if (!user.name) throw new Error("User name missing");
  return user;
}

async function saveUserToDB(user) {
  if (user.name === "Alice") throw new Error("Duplicate user");
  return true;
}

async function main() {
  try {
    const user = await fetchUser(1);
    const validUser = await validateUser(user);
    await saveUserToDB(validUser);
    console.log("User saved successfully!");
  } catch (err) {
    console.error("Something went wrong:", err.message);
  }
}

main();

What’s happening here:

• Errors are thrown and caught in a try/catch block.

• If any function fails, JavaScript unwinds the stack until a catch is found.

• It looks clean, but:

  • The error origin (which function failed) may not always be clear.

  • If you forget one await or don’t wrap async code properly, the error might bubble silently.

  • Handling specific errors like network errors vs. validation errors requires manual parsing of err.message.

Go Version (explicit error handling)

package main

import (
    "errors"
    "fmt"
)

type User struct {
    ID   int
    Name string
}

func fetchUser(id int) (User, error) {
    if id == 0 {
        return User{}, errors.New("invalid user ID")
    }
    return User{ID: id, Name: "Alice"}, nil
}

func validateUser(user User) error {
    if user.Name == "" {
        return errors.New("user name missing")
    }
    return nil
}

func saveUserToDB(user User) error {
    if user.Name == "Alice" {
        return errors.New("duplicate user")
    }
    return nil
}

func main() {
    user, err := fetchUser(1)
    if err != nil {
        fmt.Println("Error fetching user:", err)
        return
    }

    if err := validateUser(user); err != nil {
        fmt.Println("Validation error:", err)
        return
    }

    if err := saveUserToDB(user); err != nil {
        fmt.Println("Database error:", err)
        return
    }

    fmt.Println("User saved successfully!")
}

What's happening here:

• Each function returns an error value—no throwing, no hidden jumps.

• You handle the error right where it happens.

• You can wrap or categorize errors easily using fmt.Errorf, errors.Is, or errors.As.

• The flow is fully predictable—no stack unwinding, no implicit control flow.

Conclusion

Error handling in Go isn’t just about catching problems; it’s about designing programs that expect and gracefully manage them.

By making errors explicit:

• Your code becomes more predictable

• Your debugging becomes simpler

• Your software becomes more robust

So the next time you write

if err != nil {
    return err
}

remember — this isn’t boilerplate.
It’s Go’s way of saying

Handle your problems, don’t hide them.

Generics make Go code more reusable, less repetitive, and safer — all without losing the language’s hallmark simplicity.

Why are Generics needed?

Imagine you want to write a function that finds the minimum value in a slice:

func MinInt(a, b int) int {
    if a < b {
       return a
    }
    return b
}

If you later need the same function for float64, you’d have to write another one.

func MinFloat(a,b float64) float64 {
    if a < b {
        return a
    } 
    return b
}

This is code duplication with the same logic, just different types.

Generics solve this problem.

What Are Generics?

Generics allow you to write functions, structs, and methods that can work with any type.
They do this using type parameters, which are placeholders for types that you define when using the function or struct.

Think of type parameters like "boxes" that hold different types, but still guarantee what kind of things they can hold.

Now let's make the above code example generic so we don't need to create two functions to find the minimum for int and float data types.

func Min[T any](a,b T) T {
    if a < b {
        return a
    }
    return b
}

Let’s break it down and understand each keyword:

• T → It is a type parameter, just like a variable name but for types.

• [T any] → Declares that this function uses a type parameter T, which can be any type.

• a, b T → Function arguments that must both be of type T.

• The function returns a value of type T.

We have made the function generic for all data types, but there’s a problem.
Not all types can use the < operator (like structs or slices), so it needs some constraints.

Type Constraints

A constraint defines what operations are allowed on a type parameter.

Built-in constraints

• any → allows any type

• comparable → allows types that can use == and !=

• Custom constraints can be created using interfaces

Built-in Constraints in Go

1. any

   Represents all possible types.
   It’s equivalent to an empty interface (interface{}) in older Go versions.

   Example:

1.  func PrintValue[T any] (v T) {
        fmt.Println(v)
    }
   

   Here, T can be any type — string, int, struct etc

2. Comparable

   Represents all types that can be compared using == and !=.

   That includes primitive types like int, string, bool, and even structs if all their fields are comparable.

   Example

    func AreEauqal[T comparable](a,b T) bool {
        return a == b
    }
   

   Usage:

    fmt.Println(AreEqual(10,10)) // true
    fmt.Println(AreEqual("go","rust")) // false
   

   This prevents you from accidentally using non-comparable types like slices or maps.

3. Custom Constraints

   You can create your own constraints using interfaces and type unions.

type Ordered interface {
    ~int | ~float64 | ~string
}
func Min[T Ordered](a, b T) T {
    if a < b {
        return a
    }
    return b
}

In the above code, only ordered types (numbers and strings) can use this Min function.

This is type safety + flexibility combined.

Here:

• ~ means “underlying type of”.

• The Ordered constraint allows types that are comparable using <.

Let’s dive deep into the ~ operator and underlying types.

The tilde (~) symbol in Go generics is used to match types that have a specific underlying type, even if they are custom type definitions.

What is an Underlying Type?

In Go, when you create a custom type, it's based on another existing type—that's its underlying type.

type MyInt int
type Score float64

Here,

• MyInt has an underlying type of int

• Score has an underlying type of float64

So even though MyInt and Score are distinct types, they are built on top of primitive types.

Why ~ Matters in Constraints

If you don’t use ~, your constraint only accepts exact matches.
If you use ~, it also accepts types derived from that underlying type.

Without

type Ordered interface {
    int | float64
}

Works for int, float64, but fails for MyInt (even though it’s based on int).

With

type Ordered interface {
    ~int | ~float64
}

• Works for int

• Works for MyInt

• Works for float64

• Works for any type whose underlying type is int or float64

Generic Structs

You can also define structs with type parameters.

type Pair[T, U any] struct {
    First T
    Second U
}

Usage:

p := Pair[string, int]{First: "Age", Second: 25}
fmt.Println(p.First, p.Second)

Generic Methods

You can also attach methods to generic types.

type Stack[T any] struct {
    items []T
func (s *Stack[T]) Push(item T) {
    s.items = append(s.items, item)
}

func (s *Stack[T]) Pop() T {
    n := len(s.items)
    item := s.items[n-1]
    s.items = s.items[:n-1]
    return item
}

Usage:

s := Stack[int]{}
s.push(10)
s.push(20)
fmt.Println(s.Pop()) // 20

Type Inference

You don’t always have to specify the type manually. Go’s compiler can infer the type from your arguments.

PrintSlice([]string{"Go","Rust","Python","JS"})

If the function is defined as:

func PrintSlice[T any](s[]T) {
    for _,v := range s {
        fmt.Println(v)
    }
}

Go automatically understands that T is a string.

Real-World Use Cases

• Utility functions (like Min, Max, contains)

• Data structures (Stack, Queue, Tree)

• Generic database models or repositories

• Writing reusable libraries

Performance and Limitations

Advantages:

• Compile-time type safety

• No need for reflection or type assertions

• Less code duplication

• Cleaner, reusable APIs

Limitations:

• Slightly more complex syntax

• May increase compile time for very large codebases

• Not ideal for every use case — sometimes interfaces are simpler

Analogy: Generics as Blueprints

Think of generics as a blueprint for a tool. You design one hammer template, and depending on the type (wood, metal, rubber), Go builds a hammer specialized for that material at compile time.

There's no need to make a separate hammer for each. Just one perfect template works.

Conclusion

Generics bring clarity, reusability, and type safety to Go. They eliminate repetitive code and make libraries more elegant.

If you’ve ever wished you could “write once, use for all types,” then Generics are the answer.

To truly understand how Go handles text, we need to dive into strings, bytes, and runes—three closely connected concepts that define how Go represents and processes data in memory.

Before we dive deep into how strings, bytes, and runes work in Go, we first need to understand the unsung hero that powers them all: UTF-8.

Every piece of text you see, whether it’s “Hello“, “नमस्ते“, or “🙂“, is nothing more than numbers stored in memory.
But how does the computer know which number means what character?
That’s where character encoding comes in.

The Problem From Letters to Numbers

In the early days, computers used a very limited language called ASCII, which could only represent 128 characters, mostly English letters, digits, and symbols. That worked fine until people wanted to write in other languages or include emojis.

ASCII couldn’t handle words like “ありがとう“ or “नमस्ते“ and definitely not emojis like “🙂“.

We needed something global—a universal system that could represent every character from every language.

That’s when Unicode came to the rescue.

Unicode

Unicode is like a massive multilingual dictionary. It assigns a unique number called a code point to every character on Earth.

Examples:

Now every character has an identity. But there’s still a problem: we need to store these numbers in memory as bytes (0s and 1s). To achieve this, UTF-8 comes into play.

UTF-8 How Go Stores Text

UTF-8 (Unicode Transformation Format - 8-bit) is a way to store Unicode characters as bytes.
It’s a variable-length encoding, meaning

• Some characters take 1 byte (like English letters)

• Some take 2, 3, or 4 bytes

In Short

UTF-8 is the bridge between human language and machine memory, and Go builds that bridge right into its foundation.

Why UTF-8 instead of UTF-16 or other?

1. Simplicity:

   UTF-8 is the most common encoding on the web and in Unix systems, so it fits Go’s design philosophy of simplicity and practicality.

2. Compatibility:

   ASCII characters are the same in UTF-8, making it backward compatible and efficient for English text.

3. Efficiency:

   Most programming identifiers, file names, and JSON data are mostly ASCII — UTF-8 uses 1 byte for them, while UTF-16 would use 2 bytes.

4. Interoperability:

   UTF-8 is the standard encoding for most APIs, web data, and Linux systems, making Go programs more portable.

What Exactly Is a String in Go?

In Go, a string is more than just text. It’s a read-only slice of bytes, a sequence of raw data stored in UTF-8 format.

That means:

• A string is immutable (you can’t change it after creation).

• It stores bytes, not characters.

• It’s UTF-8 encoded, meaning every character can take 1 to 4 bytes.

Example:

s := "Hello"
fmt.Println(s)
fmt.Println(len(s)) // 5 bytes

Here len(s) returns 5 because "Hello" uses one byte per character. It's simple ASCII code. But not all text is that simple.

Strings and UTF-8 Encoding

Go supports UTF-8 natively, meaning it can represent any character from any language, including emojis, but they may take more than one byte.

Example:

s := "A🙂"
fmt.Println(len(s)) // 5

Why 5 bytes?

• “A“ → 1 byte

• “🙂“ → 4 bytes (because it’s a Unicode character)

So the total is 5 bytes, not 2 characters.

len(s) gives the number of bytes, not characters. For plain English text, bytes = characters, because ASCII characters use 1 byte each.

Bytes — The Raw Data Layer

A byte in Go is just an alias for uint8, representing the raw binary data behind every string.

When you convert a string to a byte slice, you’re seeing its internal UTF-8 byte representation.

Example:

s := "Hi"
b := []byte(s)
fmt.Println(b) // [72 105]

Each number here is the ASCII code for the character:

• H → 72

• I → 105

Think of bytes as the DNA of your string — the smallest building blocks.

Runes — The Character View

While bytes represent raw data, runes represent characters specifically, as Unicode code points.

In Go:

type rune = int32

So each rune can represent one Unicode character, no matter how many bytes it takes.

Let’s understand with the example below.

s := "A🙂"
r := []rune(s)
fmt.Println(r) // [65 128578]

Here,

• A → Unicode 65

• 🙂 → Unicode 128578

And if we get bytes from the same string, we get the output below.

s := "A🙂"
b := []byte(s1)
fmt.Println(b) // [65 240 159 153 130]

Here in the above example:

• A → 65

• and the other bytes are for emojis.

So, a rune is what Go uses to correctly handle multilingual text and emojis.

String, Bytes, and Runes - The Comparison

Iterating Over Strings

When you use a for loop to range over a string, Go automatically decodes UTF-8 and gives you each rune, not each byte.

s := "Go🙂"
for i, r := range s {
    fmt.Printf("%d: %c\n", i, r)
}

Output:

0: G
1: o
3: 🙂

Notice how the emoji starts at index 3, not 2, because the emoji is 4 bytes long. This is Go’s built-in way of helping you iterate over characters safely, even for complex text.

Common Pitfalls

1. len(s) Gives Bytes, Not Characters

    s := "🙂🙂🙂"
    fmt.Println(len(s))                 // 12
    fmt.Println(utf8.RuneCountInString(s)) // 3
   

   Use utf8.RuneCountInString from the unicode / utf8 package when you want the character count, not byte count.

Strings Are Immutable

You can’t modify a string directly

s := "Go"
s[0] = 'N' // ❌ compile-time error

Instead, convert to a slice, modify and convert back:

b := []byte(s)
b[0] = 'N'
s = string(b)
fmt.Prinln(s) // "NO"

Understanding the Memory Representation

Here’s how Go internally stores and interprets text

String: "Go🙂"

Bytes: [71 111 240 159 153 130]
Runes: [71 111 128578]

'G'   = 1 byte
'o'   = 1 byte
'🙂'  = 4 bytes

When to Use What

Why This Matters?

Understanding strings, bytes, and runes helps you:

• Avoid bugs with Unicode text.

• Handle emojis and multilingual input correctly.

• Optimize performance when dealing with files or network data.

• Build a mental model of Go’s memory representation.

This is one of those small topics that quietly separates beginner Go programmers from intermediate ones.

Quick Recap

Conclusion

In conclusion, working with text in Go involves understanding the intricate relationship between strings, bytes, and runes, all of which are underpinned by UTF-8 encoding. This system allows Go to efficiently handle a wide range of characters, from simple ASCII to complex Unicode symbols like emojis. By grasping these concepts, you can effectively manage text data, avoid common pitfalls, and ensure your applications are robust and capable of handling multilingual and emoji-rich content. This knowledge is crucial for developing efficient and reliable Go programs, setting apart beginner programmers from those with a deeper understanding of the language's text processing capabilities.

In the last couple of blog posts, we delved into some fundamental concepts that are essential for anyone looking to get started with programming in Go. We covered how to declare variables, explored the various data types available, and examined control flow mechanisms such as loops and conditionals. Additionally, we discussed functions, which are crucial for organizing code and promoting reusability. These topics form the foundational building blocks necessary for creating robust and efficient programs in Go.

Now, as we continue our journey, it's time to explore one of the most critical and intriguing concepts in the Go programming language: Pointers. Understanding pointers is vital for grasping how Go manages variables and memory allocation behind the scenes. In this post, we will take a closer look at what pointers are, how they work, and why they are so important in Go. We will also discuss how pointers can be used to optimize performance and manage resources effectively. If you've ever been curious about the inner workings of Go's memory management, this post will provide you with a comprehensive explanation and equip you with the knowledge to use pointers confidently in your Go programs.

The Brain Analogy

Imagine your brain managing information like this:

• Your short-term memory helps you quickly process what's needed right now.

• Your long-term memory stores information you'll need later.

• Your subconscious decides when to remember or forget.

Go works in a similar way:

• Stack (Short-term memory): Like short-term memory in the brain, it's fast, temporary storage for active function calls.

• Heap (Long-term memory): It's slower, persistent storage managed by the garbage collector.

• Go Runtime (Subconscious brain): Decides where to store data and when to clean it up.

Let's dive deeper into each term.

Stack - Go’s Short-Term Memory

When you call a function in Go, it gets its own stack frame. This is where local variables, parameters, and return addresses reside.

After the execution of a function, Go automatically clears the stack frame—no manual cleanup required.

Example

func add(a,b int) int {
    sum := a + b
    return sum
}

In the above example,

• The data for a, b, and sum will live on the stack.

• When add() returns, all of them are automatically destroyed.

• Stack allocation is super fast because it’s managed like a simple “move up or down” pointer in memory.

Heap - Go’s Long-Term Memory

Now, what if your data needs to outlive a function call?

In that case, Go moves it to the heap memory. These heap allocations are managed by the Garbage Collector.

Example

func newInt() *int {
    x := 42
    return &x // returning a pointer
}

In this,

• x escapes to the heap because its pointer is returned.

• The pointer itself (&x) lives on the stack, but

• The actual data x= 42 lives on the heap.

Pointers — The Memory Address Messengers

A pointer is like your brain remembering where a fact is stored, not the fact itself.

Example:

a := 10
p := &a

• a holds the value 10.

• p holds the address of a.

When you use *p, you’re saying “go to this address and read the value.“

Garbage Collector - The Brain’s Cleanup Crew

The Garbage Collector is like your brain's cleanup process—it removes data you no longer use.

Go uses a concurrent tri-color mark-and-sweep garbage collector for cleanup.

1. Mark Phase:

   The GC scans your program's active references (roots) and marks reachable objects as "in use."

2. Sweep Phase:

   It removes any unmarked (unreachable) objects and reclaims their memory.

3. Concurrent Execution:

   This happens alongside your running program, so Go apps rarely pause for the Garbage Collector.

4. Write Barrier:

   When the Garbage Collector and your program run together, write barriers ensure memory consistency, so no pointer gets lost during cleanup.

We will explore this in more detail in another article that will focus solely on the garbage collector.

Escape Analysis - Go’s Subconscious Decision-Maker

Escape analysis is a process that Go uses during compilation to decide where a variable should be stored in memory, either on the stack or the heap.

In simple terms, escape analysis checks, "Does this variable leave its current function or not?"

• If yes, it stores it on the heap so it remains after the function returns.

• If no, it keeps it on the stack, which is faster and automatically cleaned up when the function ends..

Why Go Needs Escape Analysis

Unlike C++, Go doesn’t allow you to manually decide where to allocate memory. Therefore, the compiler must make that decision automatically. This is important because:

• Stack allocation is cheap and automatically cleaned up.

• Heap allocations are slower and managed by the Garbage Collector.

Escape analysis helps Go minimize GC pressure and improve performance.

Let’s understand this with some examples.

Example 1 - No Escape (Stack Allocation)

func add(a, b int) int {
    sum := a + b
    return sum
}

Here,

• a, b, and sum all stay on the stack.

• Nothing "escapes" the function—Go removes them as soon as add() returns.

This is fast and efficient. There's no involvement from the Garbage Collector here.

Example 2 - Variable Escapes (Heap Allocation)

func newInt() *int {
    x := 42
    return &x
}

Here’s what happens:

• x is created inside newInt(), but we return its pointer.

• The variable x must exist after the function ends because it's used outside.

• So, Go moves x from the stack to the heap.

This is called escaping to the heap.

Example 3 — Pointer Inside Function (No Escape)

func pointerInside() {
    x := 42
    p := &x
    fmt.Println(*p)
}

In this example:

• The x variable does not escape, even though we use a pointer.

• The pointer p never leaves the function. It is used only inside that function.

• So, both x and p stay on the stack.

From this example, we understand that using a pointer does not always mean heap allocation.

How to Check Escape Analysis in Action

You can see what Go decides using the compiler flag

go build -gcflags="-m" main.go

Output:

./main.go:5:6: moved to heap: x

This means: The variable x “escaped“ to the heap because its pointer was returned.

Common Escape Patterns

How Escape Analysis Helps Go’s Performance

• Avoid unnecessary heap allocations.

• Reduce Garbage Collector overhead.

• Optimize runtime performance.

Let's explore this further with a detailed example using the code below.

package main
import "fmt"

func newInt() *int {
    x := 42
    return &x // returning a pointer
}

func main() {
    p := newInt()
    fmt.Println(*p) // prints 42

    a := 1
    b := &a
    fmt.Println(b)
}

After running the command go build -gcflags="-m" main.go, you will receive the following analysis:

./main.go:4:6: can inline newInt
./main.go:9:16: inlining call to newInt
./main.go:10:16: inlining call to fmt.Println
./main.go:13:13: inlining call to fmt.Println
./main.go:5:5: moved to heap: x
./main.go:11:2: moved to heap: a
./main.go:10:16: ... argument does not escape
./main.go:10:17: *p escapes to heap
./main.go:13:13: ... argument does not escape

Let's break down the example step by step:

1. Function newInt():

    func newInt() *int {
        x := 42
        return &x
    }
   

   • x is a local variable inside the newInt function. Typically, local variables reside on the stack, and their memory is freed once the function execution completes. However, in this case, we return the address (&x) of x, meaning the pointer will outlive the function's scope. Since main() needs to access it after newInt() returns, Go performs escape analysis and determines that x cannot remain on the stack. It must be moved to the heap to stay valid for the pointer p.

   • Compiler Output: ./main.go:5:5: moved to heap: x

2. Pointer p:

    p := newInt()
   

   • The call to newInt() returns a pointer to an integer stored on the heap. The pointer variable p is stored on the stack in main(), but the data it points to (x) resides on the heap.

   • Compiler Output: ./main.go:10:17: *p escapes to heap

3. Dereferencing p:

    fmt.Println(*p)
   

   • *p dereferences the pointer to print the integer value. The argument (*p) does not escape, meaning fmt.Println only reads it and does not retain a reference beyond the call.

   • Compiler Output: ./main.go:10:16: ... argument does not escape

4. Variables a and b:

    a := 1
    b := &a
    fmt.Println(b)
   

   • a is a local stack variable in main(). When you take its address (b := &a) and pass b to fmt.Println, the compiler conservatively assumes that a might escape because it cannot guarantee that fmt.Println won’t keep a reference to it. Therefore, a is moved to the heap to be safe, even though fmt.Println does not retain the reference.

   • Compiler Output:

     • ./main.go:11:2: moved to heap: a

     • ./main.go:13:13: ... argument does not escape

This example illustrates how Go's escape analysis works to determine whether variables should be allocated on the stack or the heap, ensuring memory safety and efficiency.

Relationship Between Pointers and Memory Management

Now, let’s connect the dots.

1. Pointers control where data lives

   When you take a pointer (&x), you’re telling GO

   “Hey“, I want to keep track of this memory location.”

   Go checks if that pointer escapes its current scope:

   • If it doesn’t → keep it on the stack.

   • If it does → move it to the heap.

2. Pointers influence garbage collection

   If you still have a pointer to an object, the Garbage Collector won’t delete it.

   Once no active pointer references a heap object → It’s eligible for the Garbage Collector.

3. Pointer Storage location

   • The pointer variable itself (the address holder) is stored where it’s declared, usually on the stack.

   • The data being pointed to might be on the stack or heap, depending on escape analysis.

1. •    func example() *int {
            a := 10   // 'a' lives on stack initially
            p := &a   // 'p' (pointer) lives on stack
            return p  // 'a' moves to heap because 'p' escapes
        }
     

Stack Shrinking and Growth

Go’s stack isn’t fixed in size. Each goroutine starts with a small stack (2kb) and grows dynamically as needed.

When a function call needs more space:

• Go allocates a bigger stack.

• Copies the current stack content into it.

• Updates all stack pointers accordingly.

This flexibility ensures efficient memory usage across thousands of goroutines.

Conclusion

In conclusion, understanding Go's memory management is akin to understanding how our brain processes and stores information. By grasping the concepts of stack and heap memory, pointers, and escape analysis, you can write more efficient and optimized Go programs. This knowledge allows you to make informed decisions about memory allocation, helping to minimize unnecessary heap allocations and reduce the overhead of the garbage collector. Just as our brain seamlessly manages short-term and long-term memories, Go efficiently handles memory allocation and cleanup, allowing you to focus on building robust applications. Embracing these concepts will empower you to harness the full potential of Go's performance capabilities.

In this blog post, we will dive into the concept of Functions in Go, a powerful feature that significantly enhances code reusability and efficiency. Functions in Go allow developers to encapsulate a set of instructions or logic that can be executed whenever needed, without having to rewrite the same code multiple times. This not only makes the codebase cleaner and more organized but also reduces the chances of errors and inconsistencies. We will explore how to define functions, pass parameters, return values, and even how to work with anonymous functions and closures. By the end of this post, you will have a comprehensive understanding of how to effectively utilize functions in your Go programming projects to create more modular and maintainable code.

Functions help you break code into reusable blocks, making your program modular, readable, and maintainable.
Go also treats functions as first-class citizens, giving you flexibility in how you pass and use them.

Let’s explore everything you need to know about functions in Go.Basic Function Definition

Syntax

func functionName(parameters) returnType {
    // function body
    return value
}

Example

package main
import "fmt"
func add(a int, b int) int {
    return a+b
}
func main() {
    result := add(5,3)
    fmt.Println("Sum:",result)
}

// Output
// Sum: 8

Function Parameters

Multiple Parameters of Same Type

func greet(firstName, lastName string) string {
    return "Hello " + firstName + " " + lastName
}

Multiple Parameters of Different Types

func info(name string, age int) string {
    return fmt.Sprintf("%s is %d years old",name,age)
}

Return Value

Single Return Value

func square(x int) int {
    return x * x
}

Multiple Return Values

func divide(a,b int) (int, int) {
    quotient := a/b
    remainder := a % b
    return quotient, remainder
}

func main() {
    q, r := divide(10,3)
    fmt.Println("Quotient:",q,"Remainder:",r)
}

Named Return Values

You can name return variables directly in the function signature

func addAddSubtract(a,b int) (sum int, diff int) {
    sum = a + b
    diff = a - b
    return
}
func main() {
    s,d := addAndSubract(10,5)
    fmt.Println(s,d) // 15 5
}

In the example above, we have given names to the return values when declaring the function. This means that in the function body, we only need to assign data to those variables. At the end of the function, they are automatically returned. In the example, we declared two return variables, sum and diff, and assigned values to them within the function body. As a result, when the function is executed, we get the values of sum and diff.

Variadic Functions

Functions can accept any number of arguments using . . .

func sumAll(numbers ...int) int {
    sum := 0
    for _,num := range numbers {
        sum += num
    }
    return sum
}

func main() {
    total := sumAll(1,2,3,4)
    fmt.Println("Total:",total)
}

In the example above, we used ...int, which is a variadic parameter. This allows the function to accept zero or more arguments of type int. Inside the function, numbers is treated as a slice of integers ([]int).

Anonymous Functions

func() {
    fmt.Println("I am anonymous")
}() // immediately invoked

or assigned to a variable

greet := func(name string) {
    fmt.Println("Hello", name)
}
greet("Rohit")

Functions as First-Class Citizens

You can pass functions as arguments to other functions

func compute(a, b int,operation func (int,int) int) int {
    return operation(a,b)
}
func add(x,y int) int {
    return x + y
}

func main() {
    return := compute(5,3,add)
    fmt.Println(result) // 8
}

Defer in Functions

defer is a keyword in go which schedules a function call after the surrounding function finishes

func main() {
    defer fmt.println("This runs last")
    fmt.Println("This runs first")
}

//output 
// This runs first 
// This runs last

This is useful for cleanup tasks like closing files or releasing resources.

Higher-Order Functions

Functions that return another function.

func multiplier(x int) func(int) int {
    return func(y int) int {
        return x * y
    }
}
func main() {
    double := multiplier(2)
    fmt.Println(double(5)) // 10
}

Closure in Go

Closure is a function that captures variables from its surroundings scope.

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

func main() {
    c := counter()
    fmt.Println(c()) //1
    fmt.Println(c()) //2
}

This will used a lot in Go for maintaining state within functions.

Init Function

A special function that runs automatically when a package is initialized. It run before the main() function. Making it ideal for performing setup tasks, such as configuring variables, establishing database connections, or registering services.

func init() {
    fmt.Println("This runs before main()")
}

Key characteristics of init()

• No arguments or return values

• Automatic execution

• Multiple init()

• Guaranteed order of execution

  • Packages: The init() functions of imported packages are executed before the init() functions of the main package

  • Wishing a package: Go initialises variables and constants first, and then runs the init() functions. If there are multiple init() functions, they are executed in the order they appear in the source file. if spread across multiple files, they are run in alphabetical order of the filenames.

Conclusion

Functions in Go are the backbone of clean, modular programming.
With the flexibility to return multiple values, accept variable arguments, and even be passed as parameters, functions make Go both simple and powerful.

Once you master functions, you can start building more organized, reusable, and maintainable programs.

In the previous blogs, we covered the basics of Go, including variables, constants, and data types.

Now, it's time to explore one of the most important aspects of any programming language.

Control Flow

Control flow determines how your program makes decisions and repeats tasks. It helps decide what runs, when it runs, and how often it runs.

Let's explore all the control structures with their code snippets.

Conditional Statements in Go

The if statement

poackage main
import 'fmt'

func main() {
   num := 10
   if num > 0 {
     fmt.Println("Positive number")
   }
}

Short Statement in if

Go allows variable initialization directly inside if.

if num:= 10; num %2 == 0 {
    fmt.Println("Even number")
} else {
    fmt.Println("Odd numner")
}

The variable number is scoped only inside this if block.

Loops in GO

Go has only one loop, the for loop, but it's extremely flexible. You can use it as a traditional loop, a while-loop, or even create infinite loops.

Traditional for Loop

for i := 1; i <= 5; i++ {
  fmt.Println(i)
}

Structure of this for loop code

• initialisation → i := 1

• Condition → i <= 5

• Post statement → i++

While-like for Loop

You can skip initialisation and post expression.

i := 1
for i <= 5 {
    fmt.Println(i)
    i++
}

Infinite Loop

Omit all parts of for to create an infinite loop

for {
   fmt.Println("Running..")
   break
}

Switch Statement

day := 3
switch day {
case 1:
    fmt.Println("Monday")
case 2:
    fmt.Println("Tuesday")
case 3:
    fmt.Println("Wednesday")
default:
    fmt.Println("Invalid day")
}

Unique Features of switch in Go

• No break needed - Go automatically breaks after each case.

• Multiple values per case:

  •   day :=3
      switch day {
          case 1,2,3,4,5:
            fmt.Println("Weekday")
          case 6,7:
            fmt.Println("Weekend")
      }
    

• Expressionless switch - act like a chain of if-else:

    num := 42
    switch {
    case num < 0:
        fmt.Println("Negative")
    case num == 0:
        fmt.Println("Zero")
    default:
        fmt.Println("Positive")
    }
  

• fallthrough keyword - forces the execution of the next case:

    switch num := 2; num {
    case 1:
        fmt.Println("One")
    case 2:
        fmt.Println("Two")
        fallthrough
    case 3:
        fmt.Println("Three")
    default:
        fmt.Println("Other")
    }
  
    // Output
    Two
    Three
  

Goto Statement

This allows you to jump to a labeled statement. It’s rarely used but can help in breaking out of nested loops.

for i := 1; i <= 3; i++ {
    for j := 1; j <= 3; j++ {
        if i*j > 3 {
            goto end
        }
        fmt.Println(i, j)
    }
}
end:
fmt.Println("Loop ended")

// output
1 1
1 2
Loop ended

Conclusion

Control flow in Go is designed to be simple, readable, and minimalistic, yet powerful enough to handle all logical branching and looping needs. With just a few keywords—if, for, and switch—Go provides all the flexibility most programs need.

Understanding these concepts builds a strong foundation for writing clean, predictable, and efficient Go code.

What are Variables in Go?

A variable is a named memory location that stores a value.

In Go, we declare variables using the following syntax or keywords:

• var keyword

• := → using this syntax for short and fast declaration.

Declaring Variables Using var

package main
import "fmt"

func main() {
    var name string = "Rohit Lokhande"
    var age int = 25
    fmt.Println(name, age)
}

Declaring Variable Using Short Declaration Syntax

name := "Rohit"
age := 25

:= this will automatically infers the type based on the value.

Note := this declaration can only be used inside functions.

Grouped Variable Declaration

var(
   name="Rohit"
   age = 25
   city = "Pune"
)

Global vs Local Variable

Variables declared outside any function are package-level, which are accessible within the package.

package main
import "fmt"
var global = "I am global"
func main() {
   local := "I am local"
   fmt.Println(global)
   fmt.Println(local)
}

iota keyword

Go uses iota to create enumerated constants easily. It is a keyword in Golang that holds an integer value.

It is typically used within constant declarations to generate a series of related values, incrementing by 1 for each subsequent constant.

const (
   Sunday = iota
   Monday
   Tuesday
   Wednesday
)
fmt.Println(Sunday, Monday, Tuesday) // 0 1 2

Every new line with a constant increments iota by 1. This is used widely for status codes, enums etc

Using iota with Expressions

This is also used with expressions to define more complex constant values. Let’s understand with an example. If we want to define constants representing file sizes in bytes, kilobytes, megabytes, and so on, we can achieve this in a simple way using iota.

pacakge main
import "fmt"
const (
  _ = iota // Discard the first value (0)
  KB = 1 << (10 * iota) // 1 << (10 * 1)
  MB = 1 << (10 * iota) // 1 << (10 * 2)
  GB = 1 << (10 * iota) // 1 << (10 * 4)
)
func main() {
    fmt.Println("KB:", KB)
    fmt.Println("MB:", MB)
    fmt.Println("GB:", GB)
    fmt.Println("TB:", TB)
}

In this, we use bitwise left shifts (<<) in conjunction with iota to calculate the constant values for different file sizes.

Rules to Remember While Declaring Variable

• All variables must be used otherwise Go will throws a compile-time error.

• Variables are block-scoped.

• You can declare multiple variable together

•   var x, y = 10,20
  

Why does Go require you to use every declared variable?

• Catches mistakes early

  If you declare a variable but forget to use it, the compiler will let you know right away, preventing a runtime bug from hiding that mistake.

• Encourages clean code

  No unused variables mean the code is easier to read and has fewer maintenance issues.

• Smaller/safer binaries

  Unused imports and values can make builds more complicated or cause unexpected problems. Not allowing them helps keep builds straightforward and predictable.

Example for above rule

Broken- compiler error code

package main
func main() {
   var x int // declared but never using
   y := 10   // declared but never used
}

Compiler will complain: x declared and not used

Fixed - use the variables

package main

import "fmt"

func main() {
    var x int
    y := 10
    x = y * 2
    fmt.Println(x) // now both x and y are used
}

How to intentionally ignore a value

If you we really want to discard a value, we can use the black identifier _ . This tells the compiler “I intentionally don’t need this.“

• Ignore a return value:

    x, _ := someFunc() // ignore second return value
  

• Mark a value as used (silence unused variable):

    var x = someFunc()
    _ = x // explicitly mark "x" as used so compiler won't complain
  

Best Practices for Unused Compile Time Error

• • If the compiler says "declared and not used," either remove the declaration or actually use the variable.

    • While experimenting, _ = x is a quick way to silence errors, but prefer to remove dead code before committing.

    • For multi-value returns where only some values matter, use _ for the ones you want to drop.

Constants in Go

Constant is an immutable value - once defined, it cannot be changed.

Declaring Constants

const PI 3.14
const Greeting = "Hello, Go!"

Constants can also be grouped

const (
    StatusOK = 200
    StatusNotFound = 404
)

If you try to modify a constant, Go will throw an error:

PI =3.142145 // ❌ compile-time error

Data Types in GO

In this section, we won't dive deep into the differences between float32, float64, and other numeric types. We will discuss non-primitive data types like arrays and slices later.

Type inference

Go automatically infers type if not specified

count:= 10 // int
price:=99.99 // float64
message:="Hello" // string

What is Type Inference?

Type inference means Go can automatically determine the data type of a variable based on the value you assign to it, so you don’t have to explicitly write the type every time.

Even though Go is statically typed, meaning types are checked at compile time, not runtime, it doesn’t always require you to write them explicitly because the compiler can infer them.

Rules for Inference

1. Inference happens only during declaration, not late:

    var x int
    x = 10.5 // Error - 10.5 is float64, not int
   

2. You can’t mix inferred and explicit types in one declaration

    var a, b = 1, "hello"   // ✅ both inferred
    var c, d int = 1, "hi"  // ❌ type mismatch for d
   

3. Inference doesn’t mean dynamic typing

   Once inferred, the type is fixed and checked at compile time.

Zero Values for Uninitialized variables

In Go, uninitialized variables are not garbage they take zero values automatically

Type Conversion

Go doesn’t support implicit conversions you must convert explicitly

var a int = 10
var b float64 = float64(a)
fmt.Println(b)

Conclusion

Variables, constants, and data types form the foundation of any Go program. Go’s simple but strong type system encourages clean, predictable code, so you always know what’s stored where.

In the next post, we’ll dive into Functions in Go, where you’ll learn how to organize and reuse logic efficiently.

Deep linking is a technique that takes users directly to a specific page or screen of an app. A deep link is simply a regular web URL. When opened in a browser, it displays a webpage, like a specific post. However, in the context of a mobile app, it opens the app instead of the browser.

Let's look at a real-world example. Imagine you're scrolling through Instagram reels in your free time and come across a funny reel you want to share with a friend. You share the reel through a link on another platform, like WhatsApp. That link is a deep link. When your friend opens the link on their mobile app and already has Instagram installed, it will open in the app. If not, it will redirect them to the Play Store to install the app—this is called deferred deep linking. If your friend opens the link in a browser on a laptop or desktop, it will redirect to the same reel in the browser.

Now that you understand what deep linking is, we will move on to the implementation part. Before we start, let's discuss what we will use in this process.

Tech Used

• React Native : We have used this to build mobile app you can use other tech as well.

• Aws Ec2 : Cloud server hosting Nginx and your domain

• Nginx: Web server to serve Android, IOS configuration file

• Node js: Running Server with redirecting web page if application not available on mobile phone you can use any other backend tech as well instead of this.

Now that we understand what we are using and the alternatives, let's start the implementation.

First, we will begin with the backend implementation.

Creating an API Endpoint in Node.js

app.ts

Add below router in app.ts file

...OtherCode
app.use("/s", deeplinkRoutes);

routes/deep-linking.routes.ts

Setup deep linking routes

 import { Router } from "express";
import DeeplinkController from "../controllers/deeplink.controller";
const deeplinkRoutes = Router();

deeplinkRoutes.get("/:id", DeeplinkController.deeplink);
export default deeplinkRoutes;

controllers/deeplink.routes.ts

Create controller for deeplink

import { Request, Response } from "express";

class DeeplinkController {
  static async deeplink(
    req: Request<{ id: string }>,
    res: Response
  ) {
    const { id } = req.params;
    // Serve HTML page instead of JSON
    const htmlContent = `<!DOCTYPE html>
<html>
<head>
  <meta charset="utf-8">
  <title>TITLE</title>
  <script>
    // Try to open the app
    setTimeout(function() {
      window.location.href = "<APP_NAME>://s/${id}";
    }, 50);

    // Check if iOS
    var userAgent = navigator.userAgent || navigator.vendor || window.opera;
    if (/iPad|iPhone|iPod/.test(userAgent) && !window.MSStream) {
      // For iOS, redirect to App Store
      setTimeout(function() {
        window.location.href = <APP_STORE_LINK>;
      }, 2000);
    } else {
      // For Android, redirect to Play Store
      setTimeout(function() {
        window.location.href = <PLAY_STORE_LINK>;
      }, 2000);
    }
  </script>
</head>
<body>
  <div style="text-align: center; padding-top: 100px;">
    <h1>Opening App...</h1>
    <p>If the app doesn't open automatically, <a href="<PLAY_STORE_LINK>">download it from the Play Store</a> or <a href="<APP_STORE_LINK>">App Store</a>.</p>
  </div>
</body>
</html>`;

    res.setHeader("Content-Type", "text/html");
    res.status(200).send(htmlContent);
    return;
  }
}

export default DeeplinkController;

This endpoint will handle redirection to the Play Store or App Store if the app is not installed on the device.

Android: assetlinks.json

[
  {
    "relation": ["delegate_permission/common.handle_all_urls"],
    "target": {
      "namespace": "android_app",
      "package_name": "com.yourapp",
      "sha256_cert_fingerprints": ["YOUR_SHA256_CERT_FINGERPRINT"]
    }
  }
]

sha256_cert_fingerprints is used for app security. Get it using:

keytool -list -v -keystore my-release-key.keystore -alias my-key-alias

IOS: apple-app-site-association

{
  "applinks": {
    "apps": [],
    "details": [
      {
        "appID": "TEAM_ID.com.yourapp",
        "paths": []
      }
    ]
  }
}

These two files are needed for App Links and Universal Links to verify that your app has permission to open specific links.

Without these rules, when a user clicks a link like “https://myapp.com/s/:id”, it will always open in the browser instead of the app.

Why are these Files Needed?

Android: assetlinks.json

• Android needs this file to confirm that the domain (myapp.com) can open links in the app.

• It stops malicious apps from pretending to own other domains.

• It must be available at:

  https://myapp.com/.well-known/assetlinks.json

IOS: apple-app-site-association (AASA)

• IOS uses this file to link your domain (my app.com) with your app.

• Without this file, Universal Links will not open your app.

• It must be hosted at:

  https://myapp.com/.well-known/apple-app-site-association

How Do These Files Work?

• A user clicks a deep link (https://myapp.com/s/asf313ehvas56dshtfoisag).

• The OS checks if the app is installed:

  • If installed → It looks for the assetlinks.json (Android) or AASA (iOS) file.

  • If verified → The app opens.

  • If verification fails or the app is not installed → The link opens in a web browser.

• File Verification Steps:

  • Android/iOS checks https://myapp.com/.well-known/ for the file.

  • If the app’s package name (com.yourapp) or App ID matches, the OS allows deep linking.

Now that we understand the role of these two files, we will serve them through Nginx on an EC2 instance.Step 1: Prepare the apple-app-site-association file and assetlinks.json file

First, log in to the EC2 instance using SSH, then follow these steps:

Create the .well-known Directory

Run the following command on your EC2 instance:

sudo mkdir -p /var/www/html/.well-known

Now create assetlinks.json and apple-app-site-association in that path.

Set Correct permissions

sudo chmod 644 /var/www/html/.well-known/apple-app-site-association
sudo chown www-data:www-data /var/www/html/.well-known/apple-app-site-association
sudo chmod 644 /var/www/html/.well-known/assetlinks.json
sudo chown www-data:www-data /var/www/html/.well-known/assetlinks.json

Step 2: Configure Nginx to Serve the file

Go to nginx path

cd /etc/nginx

Create conf.d and application conf file if not available

ubuntu@EC2:/etc/nginx$ mkdir conf.d && cd conf.d
ubuntu@EC2:/etc/nginx/conf.d$ sudo vi app_name.conf

Find the server {} block and add this inside it:

location /.well-known/assetlinks.json {
    add_header Content-Type application/json;
    root /var/www/html;
}

Step 3: Restart Nginx

sudo systemctl restart nginx

Check if Nginx is running:

sudo systemctl status nginx

Step 4: Verify the File is Accessible

Now, visit:

https://mydomain.com/.well-known/apple-app-site-association
https://mydomain.com/.well-known/assetlinks.json

Note: Do add a SSL certificate

With this we are done with backend implementation now let’s implement on mobile app side.

Mobile Application Setup

Step 1: React Native Setup

Install Dependencies

npm install @react-navigation/native react-native-screens react-native-safe-area-context react-native-gesture-handler
npm install react-native-reanimated

Configure Navigation with Deep Linking

const linking = {
  prefixes: ['https://mydomain.com','<app_name>://'], // Also added custome schema for redirection from browser
  config: {
    screens: {
      Home: '',
      Profile: 's/:id',
    },
  },
};

<NavigationContainer linking={linking}>
  {/* Your Stack Navigator */}
</NavigationContainer>

Step 2: Android App Links Integration

Add Intent Filter to AndroidManifest.xml

inside<activity android:name=”.MainActivity:>:

<intent-filter android:autoVerify="true">
  <action android:name="android.intent.action.VIEW" />
  <category android:name="android.intent.category.DEFAULT" />
  <category android:name="android.intent.category.BROWSABLE" />
  <data android:scheme="<APP_NAME>" android:host="mydomain.com" />
</intent-filter>

Step 3: Universal Links Integration

Entroll in Apple Developer Program

You must enroll to get your Team ID and use Associated Domains.

Enable Associated Domains in Xcode

• Open your iOS project in Xcode.

• Select your app target.

• Go to the “Signing & Capabilities” tab.

• Click the “+ Capability” button.

• Select “Associated Domains” from the list.

• In the new “Associated Domains” section, click the + and add:

applinks:mydomain.com

That's it! Congratulations, you have successfully created a custom deep linking implementation. Now, if you open https://mydomain.com/s/f15f8008-c9ab-49b2-a995-4c8f488df2f6, it will open directly in the app.

Conclusion

Implementing deep linking in a React Native app using your own domain—without relying on Firebase—gives you complete control over link behavior, branding, and user experience. By integrating Android App Links and iOS Universal Links, and properly setting up domain verification through assetlinks.json and apple-app-site-association, your app can open specific screens directly from links shared via WhatsApp, email, or anywhere else.

Setting up custom deep linking requires some initial backend work (like SSL, hosting .well-known files, and domain verification), but it’s a future-proof and production-ready approach that works across platforms. Once everything is set up correctly, users with your app installed will enjoy seamless navigation, and those without it will be smoothly redirected to the App Store or Play Store.

If you’re building a serious mobile product, choosing this method ensures your linking experience is secure, fast, and completely under your control—with no third-party dependency.