DEV Community: Saiful Islam

golang beauty

Saiful Islam — Thu, 15 Jan 2026 05:54:10 +0000

Beyond the `go` Keyword: The Secret Life of Goroutines & The Go Runtime

Saiful Islam ・ Jan 14

#go #opensource #webdev #systems

Beyond the `go` Keyword: The Secret Life of Goroutines & The Go Runtime

Saiful Islam — Wed, 14 Jan 2026 18:46:23 +0000

The Complex and Beautiful Truth About Go's Concurrency Model

The Core Revelation: Goroutines Are Virtual, But Their Behavior Is Real

The most mind-bending insight: A goroutine has no physical form in your operating system. It is not in your process table. It is not a real OS resource.

A goroutine is a virtual thread.

Let me illustrate with a powerful analogy:

The Facebook Profile Analogy

Consider your social media profile. The profile itself is virtual—no flesh and blood. It's a logical construct. But when your virtual profile sends a message, a real person reads it. The behavior is real. The effect is real. The impact on the real world is undeniable.

Goroutines work the same way.

Virtual Profile → Sends Message → Real Person Reads It
Virtual Thread  → Executes Code  → Real Effect on State

A goroutine is logical. It exists as a concept within the Go Runtime. But when it executes, when it modifies variables, when it prints to stdout, when it sends over a network—those effects are profoundly real, executed by real OS threads on real CPU cores.

This distinction is not mere philosophy. It's the foundation for understanding everything that follows.

The Code Simulation: What Actually Happens

Let's trace through a simple example:

package main

import (
    "fmt"
    "time"
)

func main() {
    fmt.Println("main function started")
    go fmt.Println("hello this is Islam Saiful-5")
    goRoutine()
    time.Sleep(5 * time.Second)
    fmt.Println("main function ended")
}

func goRoutine() {
    go fmt.Println("hello this is saiful")
    fmt.Println("hello world")
    go fmt.Println("hello this is saiful2")
    go fmt.Println("hello this is saiful3")
    go fmt.Println("hello this is saiful4")
    fmt.Println("bye world")
}

Without the `go` Keyword (Sequential Execution)

If we remove all go keywords:

Output:
main function started
hello world
bye world
hello this is Islam Saiful-5
main function ended

The execution is linear, predictable, deterministic. One thing after another.

With the `go` Keyword (Concurrent Execution)

With the go keywords, multiple things happen "simultaneously":

Output (Run 1):
main function started
hello world
bye world
hello this is saiful
hello this is saiful2
hello this is saiful3
hello this is saiful4
hello this is Islam Saiful-5
main function ended

Output (Run 2):
main function started
hello this is Islam Saiful-5
hello world
hello this is saiful
bye world
hello this is saiful4
hello this is saiful3
hello this is saiful2
main function ended

Output (Run 3):
main function started
hello world
hello this is saiful3
hello this is saiful
bye world
hello this is saiful4
hello this is Islam Saiful-5
hello this is saiful2
main function ended

Notice: The order is different every time. The goroutines are executing concurrently, and their relative ordering is non-deterministic.

The Critical Question: Why Do We Need `time.Sleep`?

time.Sleep(5 * time.Second)  // Why is this line essential?

This is the barrier protecting you from a hard truth: The main goroutine is a tyrant. When it finishes, it terminates the entire process—no exceptions.

If main returns before other goroutines complete, they are instantly killed. The OS doesn't care about them. The Go Runtime doesn't get a say. The process exits. Period.

The time.Sleep is a crude but effective way to keep the main goroutine alive long enough for others to finish. Without it:

func main() {
    go fmt.Println("Will this print?")
    // Nope. Main returns, process dies.
}

The answer is no. You never see that output.

This is why understanding the main goroutine's dominance is crucial.

The Birth of a Process: Disk → Binary → RAM → Execution

Step 1: Compilation (`go build main.go`)

When you compile your Go code:

go build main.go

You create a binary executable file. This file is structured:

Binary File
├── Code Segment
│   ├── Machine instructions (functions)
│   └── Constants (read-only)
├── Data Segment
│   └── Global variables (initialized)
└── BSS Segment
    └── Uninitialized globals

This binary sits on your hard disk, inert and lifeless. It's potential energy.

Step 2: Execution (`./main`)

When you run the binary:

./main

The OS loader springs into action:

Loads the binary into RAM from the hard disk
Allocates memory for the process
Creates a process structure (virtual computer)
Creates the main thread (first execution context)
Jumps to the entry point (typically, the Go Runtime initialization)

Now the binary transforms:

┌──────────────────────────┐
│      Hard Disk           │ (Inert binary file)
└─────────┬────────────────┘
          │ OS Loader
          ↓
┌──────────────────────────┐
│    RAM (Memory Layout)   │
├──────────────────────────┤
│   Code Segment           │ ← Machine instructions
├──────────────────────────┤
│   Data Segment           │ ← Global variables
├──────────────────────────┤
│   Stack                  │ ← Function calls, local vars
├──────────────────────────┤
│   Heap                   │ ← Dynamic memory
└──────────────────────────┘
          ↓
┌──────────────────────────┐
│    CPU Execution         │
│  (Fetches, Decodes,      │
│   Executes instructions) │
└──────────────────────────┘

This is where your program comes alive.

Enter the Go Runtime: The Mini-Operating System

This is the game-changer. The Go Runtime is a mini operating system running inside your Go process.

Think about it: The OS is a program that manages hardware, schedules threads, allocates memory. The Go Runtime does the same thing, but at a higher level, with different resources (goroutines instead of threads, logical processors instead of physical cores).

Timeline of Execution

1. OS loads binary into RAM
2. Process created with main thread
3. Main thread starts at the entry point
4. Go Runtime INITIALIZES (before your code runs!)
5. Go Runtime sets up:
   - 8MB main stack
   - Goroutine Scheduler
   - Heap Allocator
   - Garbage Collector
   - Logical Processors
6. THEN your main() function executes
7. When main() returns, Go Runtime shuts down
8. Process terminates

Key insight: Your code doesn't have exclusive control. The Go Runtime is always present, always managing, always orchestrating.

The Four Core Components

1. Goroutine Scheduler

The traffic controller of your program. It:

Tracks all goroutines
Decides which goroutine runs when
Manages the G-M-P model (Goroutine-Machine-Processor)
Works like the OS kernel scheduler, but in user-space

2. Heap Allocator

The memory banker. It:

Allocates memory for goroutine stacks
Manages the make() and new() allocations
Tracks where every byte lives
Works alongside the Garbage Collector

3. Garbage Collector

The janitor of memory. It:

Identifies unreachable memory
Reclaims it automatically
Runs concurrently with your code
Uses mark-and-sweep algorithms

4. Logical Processors (P)

Virtual CPUs. They:

Correspond to your system's actual CPU cores
If your CPU has 4 cores, you get 4 Logical Processors
Each has a run queue of goroutines
Each is paired with an OS thread (M)

CPU has 4 cores
    ↓
Go Runtime creates 4 Logical Processors (P)
    ↓
OS creates 4 OS Threads (M)
    ↓
Each M executes goroutines from its P's queue

The Complete Layer Hierarchy: From CPU to Your Code

Understanding concurrent execution requires understanding all layers:

┌────────────────────────────────────────────┐
│         Your Go Code                       │
│  func main() { go doWork() }               │
└────────────────────────────────────────────┘
                    ↓
┌────────────────────────────────────────────┐
│      Goroutines (G)                        │
│  - Virtual threads                         │
│  - 2KB initial stack                       │
│  - Auto-growing stacks (heap)              │
│  - Thousands can exist                     │
└────────────────────────────────────────────┘
                    ↓
┌────────────────────────────────────────────┐
│  Logical Processors (P)                    │
│  - Virtual CPUs                            │
│  - Count = runtime.NumCPU()                │
│  - Each has a run queue of Gs              │
│  - Owned by Go Runtime Scheduler           │
└────────────────────────────────────────────┘
                    ↓
┌────────────────────────────────────────────┐
│    OS Threads (M)                          │
│  - Real OS threads                         │
│  - 8MB stack each (kernel memory)          │
│  - ~1 per P                                │
│  - Owned by OS Kernel                      │
└────────────────────────────────────────────┘
                    ↓
┌────────────────────────────────────────────┐
│  Go Runtime Scheduler                      │
│  - Maps G → P → M                          │
│  - User-space scheduling                   │
│  - Work-stealing algorithm                 │
└────────────────────────────────────────────┘
                    ↓
┌────────────────────────────────────────────┐
│  OS Kernel Scheduler                       │
│  - Schedules OS threads (M)                │
│  - Kernel-space scheduling                 │
│  - Preemptive scheduling                   │
└────────────────────────────────────────────┘
                    ↓
┌────────────────────────────────────────────┐
│    CPU Cores                               │
│  - Physical execution                      │
│  - Execute machine instructions            │
│  - Control Unit, Program Counter,          │
│    Registers                               │
└────────────────────────────────────────────┘

This is the symphony. Each layer abstracts the one below, providing a simplified interface. Your code sees only goroutines. The Go Runtime handles the rest.

The 2KB Secret: Why Goroutines Are Lightweight

This is where goroutines become magical.

OS Thread Stack: Fixed 8MB

When the OS creates a thread, it immediately allocates 8MB for its stack. This is fixed. Whether you use 1KB or 7.9MB, the OS has reserved 8MB.

Implication: You can create only thousands of threads. Beyond that, you run out of memory.

1,000,000 threads × 8 MB = 8,000,000 MB = 8 TB

No modern system has 8TB of memory for thread stacks.

Goroutine Stack: 2KB Initial, Dynamic Growth

A goroutine starts with 2KB—that's a 4000:1 ratio.

But here's the magic: It's not fixed. When a goroutine needs more stack (due to nested function calls), the Go Runtime reallocates:

2KB stack is full
    ↓
Go Runtime detects overflow
    ↓
Allocates new 4KB stack in heap
    ↓
Copies all data from old to new
    ↓
Deletes old stack
    ↓
Continues execution seamlessly

This is transparent to your code. You never see it. It just works.

Implication: You can create millions of goroutines.

1,000,000 goroutines × 2 KB = 2,000,000 KB = 2 GB

Most modern systems have 2GB of RAM available.

The Memory Efficiency Advantage

Aspect	OS Thread	Goroutine
Stack Size	8 MB (fixed)	2 KB (initial)
Stack Location	Kernel memory	Heap memory
Growth	None	Dynamic
Max Stack	Fixed	Up to 1 GB
Creation Overhead	High (syscall)	Low (runtime call)
Thousands Possible?	~4,000	Yes
Millions Possible?	No	Yes

This memory efficiency is why Go can handle massive concurrency. This is why you can build a server handling 1 million concurrent connections. This is why goroutines exist.

The Scheduling Model: (from BGCE ARCHIEVE)

The Go Runtime's scheduler implements the G-M-P model:

G = Goroutine (user-created concurrent units)
M = Machine (OS thread)
P = Processor (logical CPU)

How the Scheduler Works

You write: go printHello(1)
    ↓
Go Runtime creates Goroutine G1
    ↓
Scheduler adds G1 to a Processor's run queue
    ↓
When a Machine (OS thread) is free on that Processor
    ↓
M picks G1 from P's queue
    ↓
M executes G1 on the CPU
    ↓
When G1 blocks or finishes
    ↓
M picks next G from queue
    ↓
Repeat

Visual Example

Imagine a CPU with 4 cores:

Go Runtime Scheduler
         │
    ┌────┼────┬────┐
    ↓    ↓    ↓    ↓
   P1   P2   P3   P4  (4 Logical Processors)
   │    │    │    │
   M1   M2   M3   M4  (4 OS Threads)
   │    │    │    │
   G1,G5,G9 G2,G6,G10 G3,G7,G11 G4,G8,G12
   │         │        │        │
   (4 Gs per queue, 12 total goroutines)
   │         │        │        │
   ↓         ↓        ↓        ↓
 Core1    Core2    Core3    Core4  (Physical CPU Cores)

The scheduler's job: Keep those 4 cores busy by swapping goroutines in and out.

Scheduling Example: 100,000 Goroutines

100,000 goroutines on 4 cores:
- P1, P2, P3, P4 each have a queue of ~25,000 Gs
- M1, M2, M3, M4 rapidly swap goroutines
- If G1 blocks on I/O, M1 picks G2 from queue
- Context switching happens microseconds
- From CPU's perspective, all 4 cores are always busy
- From your perspective, 100,000 things happen "simultaneously"

This is the magic. It's not parallel (only 4 at a time). It's concurrent (interleaved, but appears simultaneous).

📚 Stack & Heap: Where Goroutines Live

Main Goroutine vs Other Goroutines

Main Goroutine:
  - Executes main() function
  - Stack in kernel memory (8MB)
  - Special status: only one per process
  - When it exits, process terminates

Other Goroutines:
  - Created with `go func()`
  - Stack in heap memory (2KB initial)
  - Completely interchangeable
  - Process continues even if they exit

Memory Layout During Execution

Process Memory
├─ Kernel Stack (8MB for main goroutine)
│  ├─ main()
│  ├─ printHello()
│  ├─ fmt.Println()
│  └─ ... (other function frames)
│
└─ Heap
   ├─ Goroutine 1 Stack (2KB → 4KB → 8KB)
   │  ├─ printHello(1)
   │  ├─ fmt.Println()
   │  └─ ...
   │
   ├─ Goroutine 2 Stack (2KB)
   │  ├─ printHello(2)
   │  └─ ...
   │
   ├─ Goroutine 3 Stack (2KB → grows)
   │  └─ ...
   │
   └─ ... (more goroutines)

Each goroutine is independent. Their stacks are separate, managed individually. When a goroutine needs more stack, the Go Runtime handles it—allocating new space, copying data, updating pointers.

Summarized

Goroutines are virtual threads
- Logical, not physical
- Managed by Go Runtime, not OS
- Their behavior is real, their existence is virtual
Go Runtime is a mini-operating system
- Initializes before your code
- Manages scheduler, allocator, garbage collector
- Orchestrates everything transparently
Memory efficiency is the secret
- 2KB goroutine vs 8MB OS thread (4000:1 ratio)
- Dynamic growth in heap memory
- Millions possible, not thousands
Scheduling is sophisticated
- G-M-P model: Goroutines → Processors → Machines → CPU
- Work-stealing algorithm for load balancing
- Non-deterministic by design, not accident
Main goroutine is your control point
- First goroutine to run
- Process persists while it's alive
- Control its lifetime via blocking mechanisms
Non-determinism is a feature
- Prevents race conditions by forcing safe code
- Scales with confidence
- Forces channels over shared memory
Layers of abstraction protect you
- You write code; don't manage threads
- Go Runtime handles scheduling
- OS Kernel handles execution
- CPU handles actual computation

Separate Stack for separate Thread.

Saiful Islam — Sat, 10 Jan 2026 08:31:05 +0000

Threads & Processes:

Core Concept: Each thread needs its own stack, but threads within a process share code, data, and heap. The OS Kernel orchestrates everything.

What is a Process?

A process is a running program isolated from other processes. When you open Chrome or Spotify, the OS creates a process. It starts with one thread (the main thread) and has its own memory space. The kernel creates a Process Control Block (PCB) to track everything about the process.

What is a Thread?

A thread is an execution path within a process. Multiple threads can exist in one process and share code and data, but each thread must have its own stack. The kernel creates a Thread Control Block (TCB) for each thread to track its state.

Process Memory Layout

Segment	Type	Shared?	Notes
Code	Compiled program instructions	✅ All threads	Read-only, fixed size
Data	Global variables	✅ All threads	Fixed size, initialized
Heap	Dynamic memory (malloc/new)	✅ All threads	Grows upward, managed by programmer
Stack	Local variables, function calls	❌ Per thread	Grows downward, isolated per thread

Why Separate Stacks?

If two threads shared one stack, their function calls would collide and corrupt each other's data. When Thread A calls a function, it creates a stack frame. If Thread B also calls a function and adds its frame to the same stack, the frames overlap and overwrite each other. When Thread B returns and pops its frame, Thread A's data becomes corrupted.

Solution: Each thread has its own stack for its function calls and local variables. This way, Thread A and Thread B can execute different functions simultaneously without interfering with each other. Both threads execute independently and safely.

Stack Frames and LIFO

Stack frames work with LIFO (Last In, First Out) order. When main() calls functionA(), which calls functionB(), a new frame is created for each function on the stack. When functionB() completes and returns, its frame is removed from the stack, revealing functionA()'s frame. Then functionA() returns and its frame is removed. This ensures proper return flow and variable access.

Each thread has its own stack, so multiple threads can call the same functions simultaneously without interference. Thread A's stack frames remain separate from Thread B's stack frames.

Thread Creation: Main vs. Sub-threads

When a process starts, the OS automatically creates one thread—the main thread. This main thread is the entry point for the program and begins execution at the main() function.

The main thread can then create additional threads by calling pthread_create(). These new threads are called sub-threads. However, once created, all threads are treated as peers by the kernel. The main thread is not special anymore—it has no more authority than the sub-threads.

Thread Hierarchy

Process Created by OS
    ↓
Main Thread (created automatically by kernel)
    ├─→ Sub-thread 1 (created by main thread)
    ├─→ Sub-thread 2 (created by any thread)
    └─→ Sub-thread 3 (created by any thread)

Each sub-thread receives its own stack (allocated by the kernel), its own TCB (Thread Control Block), and shares the process's code, data, and heap. Sub-threads can also create more sub-threads if needed.

Music Player Example

A music player demonstrates multi-threading well. The main thread handles the UI and user interactions. But instead of blocking on audio playback or file I/O, it creates sub-threads to handle these tasks concurrently. One sub-thread decodes and plays audio continuously. Another sub-thread handles file system operations like loading songs. A third sub-thread updates the timer display.

All threads share the music player's code and data (the song list, player settings, etc.). But each thread has its own stack for local variables and function execution. The kernel rapidly switches between threads, giving each one a time slice to execute. This makes it appear that all tasks happen simultaneously.

The OS Kernel: Central Orchestrator

The kernel is the central manager of the OS. It handles all resource allocation and coordination for processes and threads.

Process Management

The kernel creates a Process Control Block (PCB) for every process. This PCB stores the process's ID, state (running, waiting, ready, etc.), memory layout information, file descriptors, and signal handlers. The kernel uses this information to manage the process, isolate it from other processes, and enforce security.

Thread Management

For each thread, the kernel creates a Thread Control Block (TCB). The TCB stores the thread's ID, state, CPU registers (Program Counter, Stack Pointer), stack address and size, thread-local storage, and scheduling information. The kernel tracks all this information so it can schedule and manage threads properly.

Memory Management

The kernel allocates memory for thread stacks using system calls like mmap(). It reserves virtual address space for each thread's stack. The kernel also creates guard pages at the stack boundaries to detect stack overflow conditions. When a thread actually uses its stack, the kernel allocates physical memory on demand.

CPU Scheduling

The kernel decides which thread runs on which CPU core and for how long. It uses scheduling algorithms to fairly distribute CPU time among all threads. When a thread's time slice expires or it needs to wait for I/O, the kernel performs a context switch.

Context Switching

During a context switch, the kernel saves the current thread's CPU state (Program Counter, Stack Pointer, and all CPU registers) into the thread's TCB. It then loads the next thread's saved state from its TCB into the CPU registers. The CPU then resumes execution from the restored Program Counter, effectively transferring control to the next thread. The thread resumes as if it was never interrupted.

Default Stack Size by OS

Different operating systems allocate different amounts of stack space per thread. This is virtual address space, not physical RAM.

Linux: 8 MB per thread. For 10 threads, that's 80 MB of reserved virtual space, but actual physical RAM used is only what the threads actually consume (typically a few kilobytes per thread).

Windows: 1 MB per thread. For 10 threads, that's 10 MB of reserved space. Windows balances stack size with resource efficiency.

macOS: 512 KB per thread. For 10 threads, that's 5 MB of reserved space. macOS is more conservative with memory.

Java: 1 MB per thread on most systems. The JVM handles stack allocation for Java threads.

Go: Approximately 2 KB per goroutine. Go's goroutines are much lighter because Go's runtime manages them, not the operating system. A single Go program can have thousands or even millions of goroutines running efficiently.

Why Different Sizes?

Linux's larger 8 MB stack supports deep recursion and large local variables in complex applications. Windows's 1 MB stack balances stability with resource usage. macOS's smaller 512 KB stack reflects its design philosophy of resource efficiency. Go's tiny goroutine stacks work because the Go runtime manages memory and context switching with more efficiency than the OS kernel.

Virtual vs. Physical Memory

When the kernel allocates 8 MB of stack space for a thread, it reserves 8 MB of virtual address space. However, it doesn't immediately use 8 MB of physical RAM. Instead, it uses demand paging. Only when the thread actually writes to stack memory does the kernel allocate physical pages. If a thread only uses 100 KB of its 8 MB stack, then only 100 KB of actual RAM is used. The remaining 7.9 MB of virtual space uses no physical memory at all.

This allows the kernel to efficiently allocate stacks without wasting memory, even for systems with hundreds or thousands of threads.

Kernel Data Structures

Process Control Block (PCB)

The PCB contains the process ID, process state, memory layout (where code, data, heap, and stacks are located), file descriptor table, signal handlers, and a list of all threads in the process. The kernel uses this information to manage the process's lifecycle and resources.

Thread Control Block (TCB)

The TCB contains the thread ID, thread state, CPU registers (Program Counter, Stack Pointer, etc.), the address and size of the thread's user-mode stack, thread-local storage information, scheduling priority, and a pointer to the kernel stack. The kernel uses the TCB during context switches to save and restore thread state.

Kernel Stack vs. User Stack

Every thread actually has two stacks: a user-mode stack and a kernel-mode stack.

The user-mode stack is what we've been discussing. It's used when the thread executes user code. It holds local variables, function parameters, and return addresses. It's located in the process's virtual address space and has a typical size like 8 MB on Linux.

The kernel-mode stack is used when the kernel executes on behalf of the thread. This happens during system calls (like reading a file), handling interrupts, or other kernel operations. The kernel-mode stack is separate and in kernel memory, which is protected from user code. This prevents user code from corrupting kernel data structures.

When a thread calls a system call like read() or write(), the CPU switches to kernel mode, loads the kernel stack pointer for that thread, and the kernel code executes on the kernel stack. After the system call completes, the CPU switches back to user mode and restores the user stack pointer.

Key Late Flourish at once!

Processes are isolated: Each process has its own memory space and is protected from other processes. The kernel enforces this isolation.

Threads share resources: All threads within a process share the code, data, and heap. They cooperate to perform the process's tasks.

Each thread has its own stack: The stack is the only memory region per thread within a process. This ensures independent execution.

Main thread is special only initially: It's the entry point (at main()), but all threads become peers once created.

Sub-threads created via pthread_create(): The main thread or any other thread can create new threads.

Kernel allocates all stacks: Stack size defaults are 8 MB (Linux), 1 MB (Windows), 512 KB (macOS).

Kernel manages scheduling: The kernel controls which thread runs, for how long, and on which CPU core.

Context switching enables multitasking: Rapid context switches between threads create the illusion of parallel execution on a single core.

Stack frames implement LIFO: Function calls push frames, returns pop frames. This is fundamental to how program control flow works.

Demand paging saves RAM: Virtual stack space doesn't consume physical memory until actually used.

TCBs track all thread state: The kernel maintains TCBs to manage threads throughout their lifetime.

Understanding This Matters

Understanding how threads work at the operating system level is fundamental to computer science. It reveals how your code actually executes at the hardware level. You're not just using threading APIs—you're understanding the real mechanisms that make concurrent programming possible. This foundation is essential for building efficient, safe multithreaded applications and for understanding more advanced concurrency concepts like goroutines in Go.

Go's Defer: Simple Rules, Deep Runtime Truths with intuitions.

Saiful Islam — Fri, 09 Jan 2026 10:21:27 +0000

Introduction

defer schedules a function call to run just before the surrounding function returns. If you think it's just "a function that runs at the end," you're missing the important details about how Go actually executes your code.

This guide explains what defer really does and how it works at the runtime level.

Quick Mental Model

Before diving deep, understand this fundamental truth:

return x (unnamed): The value is copied immediately, frozen in a register
return with named result: The variable stays mutable until the function exits

This single insight explains 90% of defer behavior.

What `defer` Does

defer stores a function call and executes it when the function returns.

func basicExample() {
    defer fmt.Println("This runs last")
    fmt.Println("This runs first")
    // Output:
    // This runs first
    // This runs last
}

What actually happens:

The function call is stored (not executed)
Execution continues normally
At return time, all deferred calls execute

Argument Evaluation vs Execution Time

Arguments are evaluated immediately, not when the deferred function runs.

func argumentTiming() {
    i := 1
    defer fmt.Println("Deferred print:", i)  // i is evaluated NOW (value 1)
    i = 2
    // Output: Deferred print: 1
}

The value 1 is captured when defer is encountered. Changing i later has no effect.

Stack Frames and Execution

When a function is called:

A stack frame is created
Local variables are allocated
A defer list pointer is attached to the frame

When defer is encountered, the function call is stored in the defer list:

┌─────────────────────┐
│    Stack Frame      │
├─────────────────────┤
│ Local Variables     │
│ Return Address      │
│ Defer List Pointer──┼──→┌─────────────┐
└─────────────────────┘   │  Defer Node │
                          ├─────────────┤
                          │ Function    │
                          │ Arguments   │
                          │ Next ───────┼─→ [More Defers]
                          └─────────────┘

LIFO Order: Last-In, First-Out

Multiple defer statements execute in reverse order:

func lifoExample() {
    defer fmt.Println("First")
    defer fmt.Println("Second")
    defer fmt.Println("Third")

    // Output:
    // Third
    // Second
    // First
}

The last defer added is the first one to execute.

Named vs Unnamed Return Values

This is the core concept. Named and unnamed returns behave differently with defer.

Unnamed Return (Value is Captured)

func unnamedReturn() int {
    x := 5
    defer func() {
        x = x + 10  // Too late to affect return value
    }()
    return x  // Value 5 is captured here
}
// Returns: 5

When return x executes, Go immediately captures the value 5. Deferred functions run after, but they can't change what's already captured.

Named Return (Variable is Shared)

func namedReturn() (result int) {
    defer func() {
        result = result + 10  // Modifies the return variable!
    }()
    result = 5
    return // Returns the modified value
}
// Returns: 15

result is a variable in the stack frame that deferred functions can access and modify until the function actually returns.

Deep Dive: Named vs Unnamed Returns with Closures

Example 1: Named Return

package main

import "fmt"

func calculate() (result int) {
    result = 0
    fmt.Println("first", result)

    show := func() {
        result = result + 10
        fmt.Println("defer", result)
    }
    defer show()

    result = 5
    p := func(a int) {
        fmt.Println("me", a)
    }
    defer p(result)

    defer fmt.Println(result)

    fmt.Println("second", result)

    defer fmt.Println(5)

    return result
}

func main() {
    fmt.Println("calculate result:", calculate())
}

Output:

first 0
second 5
5
me 5
5
defer 15
calculate result: 15

Explanation:

result = 0 → prints "first 0"
defer show() → closure registered (captures reference to result)
result = 5
defer p(result) → function called with value 5 (argument captured immediately)
defer fmt.Println(result) → value 5 captured
defer fmt.Println(5) → literal 5
fmt.Println("second", result) → prints "second 5"
return result → return statement reached

Defers execute in LIFO order:

defer fmt.Println(5) → "5"
defer fmt.Println(result) → "5"
defer p(result) → "me 5"
defer show() → closure modifies result to 15, prints "defer 15"

Return value becomes 15 because the named return variable was modified by the closure before the function actually returned.

Example 2: Named vs Unnamed Comparison

package main

import "fmt"

// Named return: defer can modify it
func calculate() (result int) {
    result = 0
    fmt.Println("first", result)

    show := func() {
        result = result + 10
        fmt.Println("defer", result)
    }
    defer show()

    result = 5
    fmt.Println("second", result)
    return result
}

// Unnamed return: defer cannot modify it
func calc() int {
    result := 0
    fmt.Println("first", result)

    show := func() {
        result = result + 10
        fmt.Println("defer", result)
    }
    defer show()

    result = 5
    fmt.Println("second", result)
    return result
}

func main() {
    fmt.Println("calculate result:", calculate())
    fmt.Println("calc result:", calc())
}

Output:

first 0
second 5
defer 15
calculate result: 15
first 0
second 5
defer 15
calc result: 5

The Difference:

Aspect	`calculate()` (Named)	`calc()` (Unnamed)
Return Value	15	5
What Happens	Closure modifies return variable	Closure modifies local variable
Return Mechanism	Returns modified variable	Returns captured value

Execution Timeline

Named Return (calculate()):

1. Enter function → result = 0 (named return in stack frame)
2. Register defer show() → closure captures reference to 'result'
3. Set result = 5
4. Return statement reached → process defer list
5. Execute show() → result = 15
6. Return final value of 'result' = 15

Unnamed Return (calc()):

1. Enter function → result = 0 (local variable)
2. Register defer show() → closure captures reference to 'result'
3. Set result = 5
4. Return statement reached → value 5 captured in register
5. Process defer list → execute show() → result = 15 (local changed)
6. Return value from register = 5 (unchanged!)

Understanding Closures in Defer

Deferred closures capture variables by reference, not by value:

func closureExample() (result int) {
    defer func() {
        result = result * 2  // Shares the same memory address
    }()

    result = 5
    return  // Returns 10, not 5
}

The closure has access to the actual result variable and can modify it.

Reference vs Copy Semantics

Scenario	Behavior	Example
Direct value in `defer`	Copy	`defer fmt.Println(x)`
Closure capturing variable	Reference	`defer func() { use(x) }()`
Named return variable	Reference	`func f() (x int)`
Unnamed return value	Copy (captured)	`return x`

func referenceVsCopy() {
    x := 1
    defer fmt.Println("Copy:", x)  // Captures value 1
    x = 2

    y := 1
    defer func() {
        fmt.Println("Reference:", y)  // Will see y=2
    }()
    y = 2
}
// Output:
// Reference: 2
// Copy: 1

How Go Implements defer Internally

Go implements defer using a singly linked list where each function's stack frame maintains a pointer to a chain of defer records.

Defer Record Allocation

When defer is encountered, Go:

Creates a new defer record (stack- or heap-allocated depending on escape analysis)
Stores the function pointer and captured arguments
Links it to the defer chain starting from the most recent addition

This means each defer statement prepends to the chain, naturally achieving LIFO order.

Defer Record Structure

A conceptual view of the defer record structure:

// Simplified conceptual structure
// (actual runtime definitions vary by Go version)
type _defer struct {
    fn   func()       // Function to call
    args []uintptr    // Captured argument values
    next *_defer      // Pointer to next defer in chain
}

Note: This is a simplified conceptual structure; actual runtime definitions vary by Go version and may include additional fields for panic handling and frame pointers.

Execution Flow

Stack Frame
├─ Local Variables
├─ Return Address
└─ Defer List Pointer ──→ [Defer Record #3] (most recent)
                          ├─ Function: show()
                          ├─ Arguments: captured values
                          └─ Next ──→ [Defer Record #2]
                                      ├─ Function: p()
                                      ├─ Arguments: 5
                                      └─ Next ──→ [Defer Record #1]
                                                  ├─ Function: fmt.Println()
                                                  ├─ Arguments: 5
                                                  └─ Next ──→ NULL

When the function returns, execution starts at the head (most recently added defer) and follows the chain:

func example() {
    defer fmt.Println("1")  // Record 1
    defer fmt.Println("2")  // Record 2 (becomes head)
    defer fmt.Println("3")  // Record 3 (new head)

    // At return:
    // Head → Record 3 (execute) → Record 2 (execute) → Record 1 (execute) → NULL

    // Output:
    // 3
    // 2
    // 1
}

Why This Design?

Per-function management: Each function tracks its own defer chain independently
Dynamic size: No fixed limit on defer count; scales with runtime behavior
O(1) insertion: Adding a new defer is a single pointer operation
Natural LIFO: Prepending to the head automatically gives reverse execution order
Closure support: Each record can capture different closure environments
Panic handling: The defer chain is traversed even during panic recovery

Common Pitfalls

Loop Variable Capture

// WRONG: All closures see final value of i
func problematicLoop() {
    for i := 0; i < 3; i++ {
        defer func() {
            fmt.Println(i)  // Prints: 3, 3, 3
        }()
    }
}

// RIGHT: Pass as parameter to capture value
func fixedLoop() {
    for i := 0; i < 3; i++ {
        defer func(n int) {
            fmt.Println(n)  // Prints: 2, 1, 0
        }(i)
    }
}

Resource Cleanup in Loops

// WRONG: All Close() calls happen at end of function
func processFiles(filenames []string) {
    for _, name := range filenames {
        f, _ := os.Open(name)
        defer f.Close()  // Accumulates
    }
}

// RIGHT: Use a wrapper function for scope
func processFilesCorrect(filenames []string) {
    for _, name := range filenames {
        func() {
            f, _ := os.Open(name)
            defer f.Close()  // Closes immediately after this iteration
        }()
    }
}

Error Handling in Defer

func mightFail() (err error) {
    f, err := os.Open("file.txt")
    if err != nil {
        return err
    }
    defer func() {
        if closeErr := f.Close(); closeErr != nil {
            if err == nil {
                err = closeErr  // Combine errors with named return
            }
        }
    }()

    // Process file...
    return nil
}

Practical Patterns

Resource Cleanup (Named Return)

func openResource() (err error) {
    r, err := acquireResource()
    if err != nil {
        return
    }

    defer func() {
        if closeErr := r.Close(); closeErr != nil && err == nil {
            err = closeErr  // Can modify named return
        }
    }()

    // Use resource...
    return nil
}

Panic Recovery

func safeOperation() (err error) {
    defer func() {
        if r := recover(); r != nil {
            err = fmt.Errorf("panic: %v", r)
        }
    }()

    // Code that might panic...
    return nil
}

Transaction Pattern

func transaction() error {
    tx := db.Begin()
    defer func() {
        if r := recover(); r != nil {
            tx.Rollback()
            panic(r)
        }
    }()

    // Do work...
    return tx.Commit().Error
}

Performance Considerations

Defer is cheap for most use cases. However, in very tight loops with millions of iterations, the overhead of managing the defer chain becomes measurable:

// Slower: defer in tight loop (millions of iterations)
func processBatch1(items []Item) {
    for _, item := range items {
        mu.Lock()
        defer mu.Unlock()  // Creates millions of deferred records
        process(item)
    }
}

// Faster: explicit unlock (millions of iterations)
func processBatch2(items []Item) {
    for _, item := range items {
        mu.Lock()
        process(item)
        mu.Unlock()  // Immediate cleanup, no defer overhead
    }
}

When to use defer:

One-time resource cleanup (file opens, lock acquisition)
Error handling and panic recovery
Any non-performance-critical code

When to avoid defer:

Extremely hot loops with millions of iterations
Real-time systems with strict latency requirements

Modern Go (1.20+) has optimized defer significantly with open-coded defers, making it even cheaper in most scenarios.

Closures in Go:- escape analysis, memory layout, and runtime behavior

Saiful Islam — Thu, 06 Nov 2025 13:29:30 +0000

Closures in Go Includes the exact code, what the compiler does at compile-time, runtime steps, stack vs heap comparison, a compact memory diagram, and GC is here.

Starting with a code Example
Program output
What is a closure
Why closures matter
Compiler time: code/data segments & compilation flow
Key segments (table)
Escape analysis — what it is and how it decides
Runtime behavior — stepwise
- Program startup
- Call to outer()
- Invoking the closure
- Multiple closures
- End of life
Stack vs Heap — compact comparison table
Memory visualization (CLI)
Garbage collector role

12. Minimal step-by-step trace (first `outer()` and two closure calls)

1. Starting with a code Example

package main

import "fmt"

const a = 10    // compile-time constant
var p = 100     // package-level variable

func init() {
    fmt.Println("Bangla Bank")
}

func outer() func() {
    age := 30
    money := 100

    fmt.Printf("Age = %d\n", age)

    show := func() {
        money = money + a + p
        fmt.Println(money)
    }

    return show
}

func main() {
    incr1 := outer() // creates closure capturing `money`
    incr1()          // prints updated money
    incr1()          // prints updated money again

    incr2 := outer() // new closure instance — independent `money`
    incr2()
    incr2()
}

2. Program output

Bangla Bank
Age = 30
210
320
Age = 30
210
320

Note: two separate closures created by two calls to outer() (incr1 and incr2), each with its own money value so their state does not interfere.

3. What is a closure

A closure in Go is a function value (commonly an anonymous function) that captures identifiers (variables) from its surrounding lexical scope. Captured variables remain accessible to the closure after the outer function returns. In the example above, show captures money. Because show is returned and can be invoked later, the captured money must survive the lifetime of outer().

Implementation note (runtime view): a function value is usually represented as a small runtime struct containing a pointer to the compiled code and a pointer to the closure's environment (the captured variables).

4. Why closures matter

Closures allow a function to carry state with it (function + environment).
Each call to outer() returns an independent function value with its own captured environment. That’s why incr1() and incr2() maintain separate money values.
Knowing how captured variables are stored (stack vs heap) is essential for reasoning about performance and lifetime.

5. Compiler time: code/data segments & compilation flow

At compile-time the Go toolchain typically:

Compiles function bodies into machine code → code segment (read-only).
Places package-level variables into the data segment (globals).
Treats local variables as stack candidates until escape analysis decides they must escape.
Produces a binary where constants, functions, and globals are laid into appropriate areas.

The escape analysis pass marks variables that must live beyond their creating function; the compiler will then arrange for those variables to be heap-allocated.

6. Key segments and examples from the program

Segment	What it stores (this program)
Code segment	compiled instructions for `init`, `main`, `outer`, and the anonymous `show` function. (Note: `const a` is a compile-time constant — see "Anomalies & fine points" for nuance.)
Data segment	package/global vars: `p`
Stack	local variables used only during function execution (e.g., `age`)
Heap	variables that escape (e.g., the `money` cell when captured by the closure)

7. Escape analysis- what it is and how it decides

Escape analysis is a compile-time analysis that decides whether a variable can safely live on the stack or must be moved (escape) to the heap.

Simplified rules (high level):

If a variable is used only inside the function and cannot be referenced afterwards → keep it on the stack.
If a variable's address is taken, stored in a place that outlives the function, or is captured by a function value that may outlive the function (returned or stored elsewhere) → the variable escapes and is allocated on the heap.

In the example:

age is used only inside outer() and is never referenced by show → stays on the stack.
money is referenced by show and show is returned → money escapes and is allocated on the heap.

8. Runtime behavior- function values, stack frames, heap objects

Program startup

Package init() runs (prints Bangla Bank).
Program loads code/data segments and prepares to execute main().

Call to `outer()`

A stack frame for outer() is created.
age := 30 is allocated as a stack-local candidate.
money := 100 is created but marked by escape analysis as escaping; the compiler arranges for it to be allocated on the heap (addressable by the closure environment).
The anonymous function show has compiled code in the code segment; the runtime builds a function value that contains:
- a pointer to the compiled code for the anonymous function, and
- a pointer to the captured environment (a heap object holding money).
outer() returns that function value; the stack frame is popped but the heap environment remains reachable through the function value.

Invoking the closure

Calling the function value (e.g., incr1()) jumps to the code pointed to by the function value.
The closure code uses the environment pointer to access and modify the heap-stored money cell.
Repeated calls mutate the same heap cell referenced by the closure (so state persists across calls).

Multiple closures

Each call to outer() that returns a closure creates a separate heap allocation for money.
incr1 and incr2 therefore refer to different heap objects; their money states do not interfere.

End of life

When there are no remaining references to a closure's function value (and thus to its environment), the heap object becomes unreachable and the GC may reclaim it.

9. Stack vs Heap- compact comparison table

Property	Stack	Heap
Allocation	Automatic per function call	By compiler/runtime when variable escapes
Lifetime	LIFO — ends when function returns	Lives until GC collects unreachable objects
Use case	Temporary locals (`age`)	Captured locals that outlive function (`money`)
Management	Implicit, no GC involvement	Managed by Go garbage collector
Access cost	Fast, no pointer indirection	Additional indirection; GC overhead
Visibility to closure	Not available after return	Reachable via closure function value

10. Memory visualization (CLI-style)

┌─────────────────────────────┐
│ Code segment                │
│ --------------------------- │
│ compiled code: init, main,  │
│ outer, anonymous show       │
│ (const a inlined at compile time)
└─────────────────────────────┘
           ↓
┌─────────────────────────────┐
│ Data segment                │
│ --------------------------- │
│ var p = 100                 │
└─────────────────────────────┘
           ↓
┌─────────────────────────────┐
│ Stack                       │
│ --------------------------- │
│ outer() frame               │
│   age = 30                  │
│   return address, locals    │
└─────────────────────────────┘
           ↓
┌─────────────────────────────┐
│ Heap                        │
│ --------------------------- │
│ money = 100 (for incr1)     │
│ money = 100 (for incr2)     │
└─────────────────────────────┘

Each returned closure function value points to the code segment (function code) and a pointer to its own heap block that holds money.

11. Garbage collector role

When closures (and references to them) go out of scope, the heap objects they reference become unreachable. Go's GC reclaims unreachable heap memory using concurrent mark-and-sweep techniques (collection timing is nondeterministic and happens automatically). From the programmer's perspective: you don't free these captured variables manually — the runtime does it when they become unreachable.

12. Minimal step-by-step trace (first `outer()` and two closure calls)

outer() called:
- age := 30 (stack)
- money := 100 → marked to escape → heap allocation for money
- fmt.Printf("Age = %d\n", age) prints Age = 30
- show is created as a function value (code pointer + pointer to heap money)
- outer() returns show
incr1() (first call):
- money = money + a + p → 100 + 10 + 100 = 210
- prints 210
incr1() (second call):
- money = 210 + 10 + 100 = 320
- prints 320
incr2 := outer() repeats the above steps and creates a new heap cell for money for the second closure.
When incr1 and incr2 become unreachable, GC reclaims their respective money blocks.

Mastering Scopes in Go

Saiful Islam — Tue, 14 Oct 2025 09:01:15 +0000

Scopes ins and outs

Basics for all advanced Go concepts, it is scope. Without a rock-solid understanding of scope, your programs will feel confusing and unpredictable—if a variable isn't accessible where you expect it, you'll get that dreaded "undefined" error.

It’s important to understand why they exist. One of the best ways to master scope is to simulate how the computer manages memory (RAM) and allocates space for your variables and functions.

Now, let's dive into scope of Go and see how the computer handles each of them.

The Pillars of Scope in Go

Go classifies scope into a few main categories: global scope, local (or block) scope, and package scope. Understanding how these layers interact and which one takes priority is crucial for writing bug-free Go programs.

Global Scope:

When your program starts running, the Go runtime allocates a dedicated portion of memory (RAM) known as the global scope. Any variable or function declared outside of any function (that is, at the package level) is placed in this space.

package main

import "fmt"

// Global variables A and B
var A = 20 
var B = 30 

func add(x int, y int) {
    // ...
}

func main() {
    // ...
}

In this code, A and B are declared in the global scope. During program startup, Go stores A = 20 and B = 30 in global memory. It also registers references to the add function and the main function at the global level.

Search Priority from: The global scope serves as the final fallback. If the compiler can't find a variable or function in the current local scope (or any enclosing local scopes), it then checks the global scope. If it finds the name there, the code compiles successfully. Otherwise, you'll get an undefined error.

Local Scope and Blocks:

Local scope is created whenever a function (or another block) is executed. Each time you call a function, Go allocates a fresh block of memory for that function’s variables, often on the call stack. A block in Go is defined by opening and closing curly braces {}. Each function, as well as conditional (if/else), loop, or switch block, creates a new local scope.

Consider this example:

func main() {
    // Local to main's scope
    X := 18 

    if X >= 18 {
        // Local to the IF block (a nested scope)
        P := 10 
        fmt.Println("I have", P, "points") // Output: 10
    }

    // P is out of scope here!
    // fmt.Println(P) // Uncommenting this will cause a compile error: undefined P
}

In this snippet, X is a local variable in main's scope. When the if condition is true, Go creates a new, nested scope for the if block, and P is a local variable in that inner scope. As soon as the if block completes, Go clears the memory for P. If you try to use P outside that block, the compiler will say it's undefined because P no longer exists in any active scope.

The Crucial Scope Resolution Sequence

Whenever your code needs to look up a name (variable or function), Go follows this sequence: 1->2->3;

Current Block/Function Scope: Check the innermost local scope first.
Enclosing/Parent Scopes: If not found, look in any outer local scopes (for example, the enclosing function's scope).
Global Scope: Finally, check the global (package-level) scope.

If the name isn't found by the time you reach the global scope, the compiler will give an error.

Real-World Scope Failure Example: If you declare a variable Z inside a function add(), it only lives in the local scope of add().

Trying to use Z in main() will fail with undefined: Z, because Z was never in scope in main().

Package Scope: Cross-File Accessibility

Package scope governs how code is visible across different files and packages.

Multiple Files in the Same Package

If you have multiple Go files in the same package (for example, main.go and add.go both with package main), you need to compile or run them together. For example:

go run main.go add.go

If you run only main.go by itself, Go won’t see the contents of add.go. Any functions or variables declared in add.go would be "undefined" in that case. Running both files together ensures all package-level declarations are included.

Importing from a Custom Package

When using separate packages (for example, you create your own package math_library), Go enforces that only identifiers starting with an uppercase letter are exported. For instance:

// Inside math_library/math.go
package math_library

// Exported: accessible from other packages
func Add(x int, y int) int {
    return x + y
}

// Not exported: starts with a lowercase letter
var money = 100

After doing go mod init example.com for this module, you might use math_library from main.go like this:

package main

import (
    "fmt"
    "example.com/math_library"
)

func main() {
    result := math_library.Add(4, 7) // Works, since Add is exported
    fmt.Println(result)              // Output: 11

    // fmt.Println(math_library.money) // Error: money is unexported (undefined outside math_library--// Not exported: starts with a lowercase letter)
}

This ensures that only the parts of your code you intend to share are visible to other packages.

Variable Shadowing:

A common pitfall in Go is variable shadowing, which occurs when an inner scope declares a variable with the same name as one in an outer scope. The inner declaration "shadows" the outer one within its block.

package main

import "fmt"

var A = 10 // Global A

func main() {
    age := 30 

    if age > 18 {
        // This A shadows the global A inside this if-block
        A := 47 
        fmt.Println(A) // Output 1: 47 (prints the inner A)****After printing it will disappear then or end of it's scope tasks.****
    }

    fmt.Println(A) // Output 2: 10 (prints the global A)
}

Shadowing Example

In the code above:

Globally, A is set to 10.
When the if block executes, a new local scope is created. Inside this block, A is redeclared and set to 47.
The fmt.Println(A) inside the block finds the inner A (47) first, so it prints 47.
When the block finishes, the inner A (47) goes out of scope and is removed.
The next fmt.Println(A) (outside the block) now only sees the global A, which is still 10, so it prints 10.

The inner A temporarily takes precedence, but only within the if block.

Conclusion: Master Simulation, Master Go

Scope is not just an abstract idea—it's a direct reflection of how memory is allocated and cleaned up in your program. By mastering scope, you gain insight into your program’s inner workings. Instead of rote learning, focus on simulating execution flow and memory allocation. Visualize exactly when each variable is created and when it goes out of scope. As you write more Go code, keep imagining those memory blocks for your variables. The clearer your mental model, the fewer surprises (like "undefined" errors) you'll encounter.

Start simulating today—your future self (and your future code) will thank you. Pardon me for not visualizing RAM memory allocations.
All credit goes to Habib vai.

Variables and Data Types in Go (Golang)

Saiful Islam — Sat, 04 Oct 2025 15:33:37 +0000

"Understand variables, how they live in RAM, Go’s core data types, declaration styles, reassignment rules, and constants."

When learning Go (Golang), understanding variables and data types is essential.

They form the foundation of every program — acting as the bridge between logic and memory.

In this guide, we’ll explore

The concept of variables
How memory (RAM) works with variables
Go’s primary data types
Different variable declaration methods
Reassignment rules and type immutability
Constants in Go

Let’s dive in 👇

The Concept of Variables

A variable is simply a container — a vessel, bucket, or pot (বালতি, গামলা, বাসন) used to store something.

Just like you might store coffee in a mug or rice in a dish, a program stores data in variables.

Purpose: To store and manage data — the heart of programming and computer science.
Naming: Programmers often use Var (V-A-R) as shorthand for "Variable." They also shorten other terms, like writing int instead of “Integer.”

Variables and Computer Memory

When you declare a variable, it doesn’t just exist in code — it occupies space in your computer’s RAM (memory).

Components of a Computer Relevant to Variables

Component	Function / Role
CPU (Central Processing Unit)	Executes instructions.
RAM (Random Access Memory)	Temporarily stores variables and data during program execution.
Hard Disk	Long-term data storage (not directly used for variables at runtime).

How Variables Occupy RAM

When you declare something like a := 10, Go asks the computer to allocate space for it in memory:

RAM is divided into many small storage spaces called cells.
Declaring a variable occupies one of those empty cells.
That cell is given a name (e.g., a).
The value (e.g., 10) is stored inside that cell.

So a := 10 means:

“Hey computer, take one cell in RAM, label it a, and put 10 inside it.”

Data Types (ডাটা টাইপ)

Every variable stores data — but not all data is the same type.

Go’s data types define what kind of value a variable can hold.

Table of Primary Data Types in Go

Category	Meaning / Example	Go Type	Description
Numeric	Numbers of any kind.	—	Divided into integers and floating-point types.
->Integer (পূর্ণ সংখ্যা)	Whole numbers (e.g., `10`, `-5`).	`int`, `int8`, `int16`, `int32`, `int64`, `uint`, `uint8`, etc.	Whole numbers. The suffix (8, 16, 32, 64) refers to bit size.
->Floating Point (দশমিক সংখ্যা)	Decimal numbers (e.g., `10.5`, `40.34`).	`float32`, `float64`	For numbers with decimals.
Boolean (বুলিয়ান)	True or False values.	`bool`	Can only be `true` or `false`.
String (স্ট্রিং)	Words or text.	`string`	Enclosed in double quotes, e.g., `"Hello World"`.

Note: More complex types (like arrays, slices, and structs) come later — start simple!

Declaring Variables in Go

Go offers several ways to declare variables.

Knowing one or two is enough to start coding efficiently.

A. Explicit Declaration (Type Specified)

You tell Go exactly what type the variable will hold:

var x int = 10

var → tells Go you’re declaring a variable.
x → the variable name.
int → its data type.
= 10 → the assigned value.

B. Type Inference (Let Go Decide)

Go is smart — it can infer the data type automatically based on the value.

Example 1 — Long Form

var a = 10 // Go infers: a is int

Example 2 — Short-Hand Declaration

a := 10       // infers int
pi := 3.14    // infers float64
name := "Go"  // infers string
isCool := true // infers bool

The := operator both declares and initializes a variable in one step.

Reassigning Variables

Variables are “containers,” so their contents can change.

Rules for Reassignment

You cannot use := again — that’s only for declaring.
To update, use the simple = operator.

a := 100
a = 50 // ✅ OK (reassignment)

If you try this:

a := 100
a := 50 // ❌ Error: no new variables on left side

Go will complain — you’re redeclaring instead of reassigning.

Type Immutability

Once a variable is assigned a type, it cannot hold a value of a different type.

flag := true
flag = false   // ✅ OK
flag = "saifulire" // ❌ Error: cannot assign string to bool

Variables in Go are “loyalenough_haha;)” — they stick to their original type.

Constants

A constant (const) holds a value that never changes — like a permanent variable.

const Pi = 3.1416

Declared using const.
Cannot be reassigned — doing so triggers a compiler error:

const P = 100
P = 200 // ❌ Error: cannot assign to P

Constants are great for fixed values like configuration keys, mathematical constants, or version numbers.

Conclusion

Variables are at the core of Go programming — they link your logic to memory.
They occupy RAM cells and store data with a defined type.
Go offers smart type inference and multiple declaration styles.
Variable types are fixed after declaration, ensuring type safety.
Use constants for unchangeable values.

All credit goes to @-> Habib vai.

vectors a smart dynamic array

Saiful Islam — Sun, 28 Sep 2025 04:33:09 +0000

Saiful Islam

Sep 28 '25

Vectors in C++: The Smart Dynamic Array

#programming #performance

Comments

4 min read

Vectors in C++: The Smart Dynamic Array

Saiful Islam — Sun, 28 Sep 2025 04:20:52 +0000

When coding in C++, one of the most common data structures you’ll encounter is the vector.

It behaves like an array but with runtime flexibility — it can grow or shrink dynamically, making it one of the most powerful tools in the Standard Template Library (STL).

In this guide we’ll cover:

Vectors and STL basics
Initialization methods
Common functions and operations
Static vs dynamic allocation
Array vs vector differences
How vectors manage memory
Iterators
2D vectors
Performance considerations
Comparison with other containers
Automatic memory cleanup

STL and Vectors

The Standard Template Library (STL) provides ready-made containers and algorithms. Some commonly used containers:

vector → Dynamic array
queue → FIFO
stack → LIFO
set → Unique, ordered elements

👉 Compilation note: always use at least C++11:

g++ -std=c++11 code.cpp -o runfile && ./runfile

If you forget -std=c++11, you may run into compile errors or unexpected runtime issues.

Vector Initialization

Different ways to initialize std::vector:

#include <iostream>
#include <vector>
using namespace std;

int main() {
    // Direct initialization (C++11)
    vector<int> v1 = {1, 2, 3};

    // Fill constructor (size, initial_value)
    vector<int> v2(3, 0); // [0, 0, 0]

    // Empty then push_back
    vector<int> v3;
    v3.push_back(10);
    v3.push_back(20);

    // Printing using range-for loop
    for (int x : v1) cout << x << " ";
    cout << endl;
}

Output:

1 2 3

Vector Functions & Operations

Common vector operations:

Insertion / Removal
- push_back(x) → add at end
- pop_back() → remove last element
Access
- v[i] → element by index (no bounds check)
- v.at(i) → bounds-checked access (throws out_of_range)
- front() / back()
Information
- size() → number of elements
- capacity() → allocated memory size
- empty() → check if empty

Example:

vector<int> v = {10, 20, 30};
v.push_back(40);  // [10,20,30,40]
v.pop_back();     // [10,20,30]

cout << v.front() << endl;    // 10
cout << v.back() << endl;     // 30
cout << v.at(1) << endl;      // 20
cout << v.size() << endl;     // 3
cout << v.capacity() << endl; // capacity >= 3

Static vs Dynamic Memory Allocation

Static arrays

int arr[5]; // size fixed at compile-time

Usually stored on the stack
Size rigid, cannot grow

Dynamic arrays (manual)

int* arr = new int[5];
delete[] arr;

Stored on the heap
Requires manual memory management

Vectors use dynamic memory under the hood but manage it automatically, making them safer and more flexible than raw dynamic arrays.

Array vs Vector — Key Differences

Feature	Array (Static)	Vector (Dynamic)
Size	Fixed at compile-time	Can grow/shrink at runtime
Memory location	Stack (usually)	Heap (managed internally)
Memory management	Manual (if dynamic)	Automatic
Functions available	None (raw access only)	Rich API: `push_back`, `at`, `size`...
Initialization	Limited forms	Flexible constructors
Safety	No bounds checking	`at()` provides bounds-checked access

How Vectors Work in Memory

vector maintains two core concepts:

size → number of stored elements
capacity → allocated storage space (may be >= size)

When capacity is exceeded, implementations typically grow the capacity (commonly by doubling), which amortizes insertion costs.

Example:

vector<int> v;
for (int i = 0; i < 10; i++) {
    v.push_back(i);
    cout << "Size: " << v.size()
         << " Capacity: " << v.capacity() << endl;
}

Typical output (implementation-dependent):

Size: 1 Capacity: 1
Size: 2 Capacity: 2
Size: 3 Capacity: 4
Size: 5 Capacity: 8
Size: 9 Capacity: 16

Use reserve(n) to pre-allocate memory if you know the expected size — this avoids repeated reallocations.

Iterators

Iterators behave like pointers and are used to traverse containers:

vector<int> v = {10,20,30,40};

// Forward
for (auto it = v.begin(); it != v.end(); ++it) cout << *it << " ";

// Reverse
for (auto it = v.rbegin(); it != v.rend(); ++it) cout << *it << " ";

Output:

10 20 30 40
40 30 20 10

Iterators are the common way to use STL algorithms like std::sort, std::find, etc.

2D Vectors

Nested vectors are useful for matrices, graphs, and dynamic 2D storage:

vector<vector<int>> matrix(3, vector<int>(3, 0));
matrix[0][1] = 5;
matrix[2][2] = 7;

for (auto& row : matrix) {
    for (auto val : row) cout << val << " ";
    cout << endl;
}

Output:

0 5 0
0 0 0
0 0 7

Performance Tips

size() is O(1). Use it freely.
capacity() shows reserved memory; use reserve(n) when you know the expected size.
Avoid excessive copying — prefer emplace_back() to construct in-place.
Random access is O(1); inserting/removing at the middle is O(n).
For frequent front insertions, consider deque; for frequent middle insert/delete, consider list (but lists have poor cache locality).

Vector vs Other Containers

Vector → best for random access, fast end insertions.
Deque → fast insertions at both ends.
List → fast middle insertions/deletions (no random access).
Set → unique, ordered elements (logarithmic operations).

👉 Default choice: vector unless you have a specific reason to choose another container.

Automatic Memory Cleanup

Vectors free their managed memory automatically when they go out of scope:

void func() {
    vector<int> v(1000, 1);
} // memory is released when the function returns

✅ Conclusion

std::vector is array-like but flexible, safe (with at()), and efficient for most general-purpose needs. Prefer vectors over raw arrays unless you need a fixed-size, stack-allocated buffer or have very specific performance constraints.

Mastering DOM Performance & Security

Saiful Islam — Sat, 02 Aug 2025 10:15:26 +0000

Lessons from deep-diving JavaScript DOM with Satt Academy(website)

3 Hidden aspects Most Tutorials Skip

1. Node vs. Element: The Silent Speed Drain
Code:-

// Slow path (12% slower)  
const slow = parent.childNodes; // Grabs text & comment nodes  
// Fast path  
const fast = parent.children; // Only elements!

Why care?
Text and comment nodes sneak into your collections and silently slow down your site’s performance.

2. Live vs. Static Collections
Code:-

// Performance killer (live)  
const heavy = document.getElementsByClassName('item');  
// Optimized path (static)  
const light = Array.from(document.querySelectorAll('.item'));

📉 Result: Live HTMLCollections cause up to 40% more browser reflows than static NodeLists — meaning slower, laggier pages.

3. Content Security Matrix
Method Security Speed Best For

innerHTML ❌ Not safe Slow Injecting trusted HTML
textContent ✅ Safe Fast User-generated content
createElement ✅ Safest Fastest Complex UI building ________________________________________

4 Performance Optimization Should Use
Event Delegation
Code:-

// 1 listener instead of 100 → Saves ~75% memory!
parent.addEventListener('click', e => {
  if (e.target.classList.contains('btn')) handleClick();
});

Animation Mastery
Use requestAnimationFrame instead of setInterval for smooth, buttery 60fps animations.

NodeList → Array Magic
Code:-

// NodeList looks like an array but isn’t
const nodeList = document.querySelectorAll('.item');

// Convert for full array power
const realArray = [...nodeList];
realArray.map(item => item.classList.add('processed'));

Insights:
Converting NodeLists to real arrays unlocks the full power of JavaScript’s array methods—like .map(), .filter(), and .reduce()—while avoiding the costly performance pitfalls of live collections.

10,000+ Items? Virtualize!
Only render elements visible on the screen to ensure instant page loads and snappy interactions.

This simple step helps you write cleaner, faster, and more secure DOM manipulation code.

MongoDB connect with a Node.js web server and Send your first data in Database: Atlas and Compass

Saiful Islam — Fri, 25 Jul 2025 10:20:13 +0000

1#Directly sending data to mongodb atlas and compass

First set your mongodb atlas account and install mongodb compass as per your device configuration

In atlas website and compass software:-
1.After setting up your databases, using as per free tire option and click to connect button in atlas website first.
2.Then, will set up Collection name/database name and table name.(it is possible to setup by server code as well, all these are depends on coder)
3.After 1 and 2, Run the code(Before running the code install in terminal press:

npm install mongodb

After installing then run the code:

node dbconnect.js

Code:

`const { MongoClient } = require('mongodb');//By this-{}, installing mongodb class.

// Direct connection string with username and password
const url = 'mongodb+srv://mrx:JByoERjrLbSVNpmP@cluster0.klreadp.mongodb.net/myDatabase?retryWrites=true&w=majority';//from mongoDB Atlas url.
const dbName = 'myDatabase';// Database name

const client = new MongoClient(url);

async function connectToDatabase() {
    try {
        await client.connect();// Connect to the MongoDB server
        console.log('✅ Connected to MongoDB Atlas');

        const db = client.db(dbName);// Get the database instance
        const usersCollection = db.collection('users');// Get the 'users' collection -> table.

        const sampleUser = {
            name: 'Mitchell Johnson',
            email: 'jonson@example.com',
            age: 24,
            address: {
                street: '123 Main St',
                city: 'San Francisco',
                state: 'CA',
                zipCode: '94101'
            },
            hobbies: ['reasoning', 'travelling', 'coding','problem solving'],
            createdAt: new Date()
        };

        const result = await usersCollection.insertOne(sampleUser);//directly insert the sample user into the collection
        console.log(`✅ User inserted with ID: ${result.insertedId}`);

        const foundUser = await usersCollection.findOne({ name: 'Mitchell Johnson' });// Find the user we just inserted
        console.log('📦 Found user:', foundUser);

        return '✅ MongoDB operations completed';
    } catch (error) {
        console.error('❌ MongoDB connection error:', error);
    } finally {
        await client.close();
        console.log('🔒 Connection closed');
    }
}

connectToDatabase()
    .then(console.log)// Log the success message
    .catch(console.error);// Log any errors that occur during the connection or operations.

After running this Output of Terminal:

Output of Compass and Atlas(same):

2#Using Mongoose schema(ORM) sending data to mongodb atlas and compass

Like same as First part as directly sending, Except:

Only install mongoose package by-

npm install mongoose

Run in terminal:

node file_mongoose.js

Code:

const mongoose= require('mongoose');

const db = mongoose.connect('mongodb+srv://mrx:JByoERjrLbSVNpmP@cluster0.klreadp.mongodb.net/myDatabase?retryWrites=true&w=majority');

const model= mongoose.model('login', {username: String, email: String, password: String})//model schema is defined here.

const user = new model({//creating a new user instance based on the model schema.
    username: 'Stephen Hawkings',
    email: 'einstein@gmail.com',
    password: '7801'
});
user.save()
    .then(() => console.log('It is an event of Joy! that your effort is sucessful'))// message to be printed on successful save of user.
    .catch(err => console.error('Error saving user:', err));// failure message to be printed on unsuccessful save of user.

Output would be same as Direct mongodb connection.

Leetcode: 258

Saiful Islam — Sat, 31 Aug 2024 14:25:48 +0000

258. Add Digits

Question:

Given an integer num, repeatedly add all its digits until the result has only one digit, and return it.

Example 1:

Input: num = 38
Output: 2
Explanation: The process is
38 --> 3 + 8 --> 11
11 --> 1 + 1 --> 2
Since 2 has only one digit, return it.

Example 2:

Input: num = 0
Output: 0

Constraints:

0 <= num <= 231 - 1

Soln:

#include<iostream>
using namespace std;

int main()
{
    int ans, num;
    cout << "Enter a number: " << endl;
    cin >> num;

    // Convert negative number to positive
    num = abs(num);

    // Repeat the process until num is a single digit
    while(num >= 10)
    {
        ans = 0;  // Reset ans for each iteration
        while(num > 0)
        {
            ans += num % 10;  // Add the last digit to ans
            num /= 10;        // Remove the last digit from num
        }
        num = ans;  // Set num to the sum of digits
    }

    cout << "Sum of digits until single digit is: " << num << endl;
    return 0;
}

DEV Community: Saiful Islam

golang beauty

Beyond the `go` Keyword: The Secret Life of Goroutines & The Go Runtime

Saiful Islam ・ Jan 14

Beyond the `go` Keyword: The Secret Life of Goroutines & The Go Runtime

The Core Revelation: Goroutines Are Virtual, But Their Behavior Is Real

The Facebook Profile Analogy

The Code Simulation: What Actually Happens

Without the go Keyword (Sequential Execution)

With the go Keyword (Concurrent Execution)

The Critical Question: Why Do We Need time.Sleep?

The Birth of a Process: Disk → Binary → RAM → Execution

Step 1: Compilation (go build main.go)

Step 2: Execution (./main)

Enter the Go Runtime: The Mini-Operating System

Timeline of Execution

The Four Core Components

1. Goroutine Scheduler

2. Heap Allocator

3. Garbage Collector

4. Logical Processors (P)

The Complete Layer Hierarchy: From CPU to Your Code

The 2KB Secret: Why Goroutines Are Lightweight

OS Thread Stack: Fixed 8MB

Goroutine Stack: 2KB Initial, Dynamic Growth

The Memory Efficiency Advantage

The Scheduling Model: (from BGCE ARCHIEVE)

How the Scheduler Works

Visual Example

Scheduling Example: 100,000 Goroutines

📚 Stack & Heap: Where Goroutines Live

Main Goroutine vs Other Goroutines

Memory Layout During Execution

Summarized

Separate Stack for separate Thread.

Threads & Processes:

What is a Process?

What is a Thread?

Process Memory Layout

Why Separate Stacks?

Stack Frames and LIFO

Thread Creation: Main vs. Sub-threads

Thread Hierarchy

Music Player Example

The OS Kernel: Central Orchestrator

Process Management

Thread Management

Memory Management

CPU Scheduling

Context Switching

Default Stack Size by OS

Why Different Sizes?

Virtual vs. Physical Memory

Kernel Data Structures

Process Control Block (PCB)

Thread Control Block (TCB)

Kernel Stack vs. User Stack

Key Late Flourish at once!

Understanding This Matters

Go's Defer: Simple Rules, Deep Runtime Truths with intuitions.

Introduction

Quick Mental Model

What defer Does

Argument Evaluation vs Execution Time

Stack Frames and Execution

LIFO Order: Last-In, First-Out

Named vs Unnamed Return Values

Unnamed Return (Value is Captured)

Named Return (Variable is Shared)

Deep Dive: Named vs Unnamed Returns with Closures

Example 1: Named Return

Example 2: Named vs Unnamed Comparison

Execution Timeline

Understanding Closures in Defer

Reference vs Copy Semantics

How Go Implements defer Internally

Defer Record Allocation

Defer Record Structure

Execution Flow

Why This Design?

Without the `go` Keyword (Sequential Execution)

With the `go` Keyword (Concurrent Execution)

The Critical Question: Why Do We Need `time.Sleep`?

Step 1: Compilation (`go build main.go`)

Step 2: Execution (`./main`)

What `defer` Does

12. Minimal step-by-step trace (first `outer()` and two closure calls)

Call to `outer()`

12. Minimal step-by-step trace (first `outer()` and two closure calls)