Forem: Pavel Sanikovich

5 Go Bugs That Only Appear in Production

Pavel Sanikovich — Mon, 26 Jan 2026 12:30:25 +0000

Go has a reputation for being boring — in a good way.
Strong typing, a simple concurrency model, a strict compiler. If something is wrong, it usually fails fast.

And yet, many Go bugs don’t fail fast at all.

They quietly pass tests, survive code review, behave perfectly on your laptop, and only show up in production — under real traffic, real data, and long-running processes.

This article isn’t about exotic edge cases. It’s about bugs that look innocent, feel “Go-ish”, and still manage to hurt you in production. Especially if you’re a junior or mid-level Go developer.

Goroutines That Never Die

One of the most common production issues in Go is not a crash, but slow degradation. Memory usage grows, CPU usage creeps up, and the number of goroutines keeps increasing.

Often the root cause is a goroutine that was supposed to finish — but never did.

Consider a worker reading from a channel:

func worker(ch <-chan Job) {
    for job := range ch {
        process(job)
    }
}

This code looks clean and idiomatic. In tests, the channel is closed properly. Locally, everything works.

In production, things are different. A producer might crash, a request might be canceled, or a code path that closes the channel might never execute. The goroutine stays alive forever, blocked on receive.

Over time, these goroutines accumulate. The service is still “up”, but it’s slowly dying.

Production-grade goroutines need an explicit lifetime. Usually that means context cancellation:

func worker(ctx context.Context, ch <-chan Job) {
    for {
        select {
        case <-ctx.Done():
            return
        case job, ok := <-ch:
            if !ok {
                return
            }
            process(job)
        }
    }
}

If a goroutine doesn’t know when it should stop, it probably won’t.

Data Races That Only Exist Under Load

Go’s race detector is excellent, but it’s not magic. Many race conditions simply don’t appear without real concurrency and real pressure.

A classic example is shared configuration:

type Config struct {
    Enabled bool
}

var cfg = &Config{Enabled: true}

func handler() {
    if cfg.Enabled {
        doSomething()
    }
}

At some point, someone adds hot reload:

func reload() {
    cfg.Enabled = false
}

This might run fine for weeks. Tests pass. The race detector stays quiet.

Then traffic grows. CPU cores are actually busy. Suddenly behavior becomes inconsistent, but nothing obviously crashes.

The problem isn’t Go. The problem is mutating shared state without synchronization. In production, concurrency is not hypothetical — it’s constant.

A safer approach is to treat configuration as immutable and swap it atomically:

var cfg atomic.Value

func init() {
    cfg.Store(Config{Enabled: true})
}

func handler() {
    c := cfg.Load().(Config)
    if c.Enabled {
        doSomething()
    }
}

Production reveals races not because it’s special, but because it’s honest.

The Interface That Is Nil (Except It Isn’t)

This is one of the most confusing bugs for people new to Go, and it often hides until a rare code path is executed in production.

type MyError struct{}

func (e *MyError) Error() string {
    return "something went wrong"
}

func do() error {
    var err *MyError = nil
    return err
}

From the caller’s point of view:

err := do()
if err != nil {
    log.Println("error:", err)
}

You expect nothing to happen. Instead, the error branch runs.

The reason is subtle but fundamental. An interface value in Go contains both a type and a value. Here, the value is nil, but the type is not. That makes the interface itself non-nil.

This kind of bug often appears only in production, when a rarely used error path finally executes.

The fix is simple but strict: never return a typed nil as an interface. Return a real nil or a real error — nothing in between.

Timeouts That Work Locally and Fail in Production

Timeouts are another classic “it worked on my machine” trap.

client := &http.Client{
    Timeout: 2 * time.Second,
}

Locally, requests are fast. In staging, everything looks fine. In production, requests start timing out randomly.

The difference is the network. DNS latency, TLS handshakes, slow upstreams, saturated connection pools — none of that exists on localhost.

A single global timeout often hides where time is actually being spent. A more production-friendly approach is to put deadlines on requests themselves:

ctx, cancel := context.WithTimeout(context.Background(), 500*time.Millisecond)
defer cancel()

req, _ := http.NewRequestWithContext(ctx, "GET", url, nil)
resp, err := client.Do(req)

Production is not slow because Go is slow. It’s slow because networks are unreliable.

Allocation Patterns That Break at Scale

Many performance problems don’t come from algorithms, but from memory behavior that changes with scale.

Code like this looks harmless:

buf := make([]byte, 10<<20)
process(buf)

Maybe it runs once per request. Maybe it’s short-lived. Locally, no problem.

In production, under sustained load, this creates constant pressure on the garbage collector. Large allocations must be zeroed, tracked, and scanned. Latency spikes appear, and p99 gets ugly.

This is why production Go code often relies on reuse:

var bufPool = sync.Pool{
    New: func() any {
        return make([]byte, 64<<10)
    },
}

The GC in Go is very good, but it still obeys physics.

Why These Bugs Feel “Production-Only”

Because production is the first place where your code experiences:
long uptimes, real concurrency, unreliable networks, large data, and sustained load.

Go doesn’t hide these problems — it simply doesn’t simulate them for you.

If you write Go as if production is calm and predictable, production will eventually disagree.

Want to go further?

This series focuses on understanding Go, not just using it.

If you want to continue in the same mindset, Educative is a great next step.

It’s a single subscription that gives you access to hundreds of in-depth, text-based courses — from Go internals and concurrency to system design and distributed systems. No videos, no per-course purchases, just structured learning you can move through at your own pace.

👉 Explore the full Educative library here

Why allocs/op stopped being a good Go performance signal

Pavel Sanikovich — Sun, 11 Jan 2026 14:56:08 +0000

Most Go performance advice still revolves around one metric:
reduce allocs/op.

Avoid heap allocations.
Preallocate everything.
Use sync.Pool.
Be careful with interfaces.

All of that sounds reasonable — and used to be useful.

But after benchmarking modern Go (1.25) in isolation, I realized that allocation count alone no longer predicts performance in a meaningful way.

One benchmark in particular completely changed my mental model.

Retention vs Allocation

Consider the following experiment.

Both variants below perform the exact same number of allocations.

The only difference is how much memory they retain.

Bad retention

~1.5 ms/op
~8 MB/op
129 allocs/op

Good retention

~90 µs/op
~11 KB/op
129 allocs/op

That’s a ~16× difference in runtime with identical allocation counts.

The GC doesn’t care how many objects you allocated.
It cares how much memory stays reachable — and for how long.

Once you see this, a lot of familiar advice starts to feel incomplete.

When allocs/op lies

I also benchmarked a few other “classic” optimization targets:

new(int) vs stack allocation → 0 allocs/op in both cases
interface vs concrete calls → measurable overhead, no allocation or GC cost
sync.Pool → often pure overhead when allocations don’t hit the heap
slice over-preallocation → fewer allocations, worse performance

In isolation, many of these micro-optimizations either don’t matter anymore — or optimize the wrong layer.

The real shift in modern Go performance

What changed is not a single runtime tweak or compiler trick.

The shift is this:

Mechanical costs got cheaper.
Architectural costs dominate.

Modern Go rewards:

clear ownership
short-lived data
explicit lifetimes
bounded concurrency

Old advice assumed the runtime was fragile.
In modern Go, the runtime is usually fine — it’s accidental retention and unclear lifetimes that hurt.

The takeaway

Allocations still matter.

But allocation count alone is a poor proxy for performance.

If you reduce allocs/op without controlling object lifetime, you often optimize the wrong thing.

I published the full deep dive with all benchmarks, code, and detailed explanations here:

👉 https://blog.devflex.pro/why-most-go-performance-advice-is-outdated-go-125-edition

It covers:

interfaces vs generics
sync.Pool trade-offs
slice growth strategies
retention vs allocation
and why modern Go performance problems often look like architecture bugs

Why context.Context Is Not a Cancel Button (And Why That Matters)

Pavel Sanikovich — Fri, 26 Dec 2025 10:21:25 +0000

context.Context is often treated as a cancellation mechanism.

But cancellation is just one small part of what context is designed to do.

Most misuse of context.Context comes from misunderstanding its role as a protocol for request-scoped data and lifecycle management.

This article is part of a practical guide on how Go works under the hood.

Start here if you want the full picture

Most beginners meet context.Context as a strange requirement. Functions suddenly demand an extra argument. You pass context.Background() everywhere, add WithCancel or WithTimeout when a tutorial tells you to, and move on. The code compiles, tests pass, and the meaning of context remains vague.

This is unfortunate, because context is one of the clearest expressions of Go’s philosophy. It is not a helper. It is not just cancellation. It is a protocol for coordinating lifetimes across boundaries you don’t control.

To understand context, you need to forget the idea that it is about stopping things. Cancellation is only a symptom. The real purpose of context is scope.

Let’s start with the simplest example:

ctx := context.Background()

This does nothing. It has no deadline, no cancellation signal, no values. And yet it is not useless. It establishes a root. Every real context grows from a root. Without that root, lifetimes become unstructured.

Now consider a server handler:

func handle(w http.ResponseWriter, r *http.Request) {
    ctx := r.Context()
    process(ctx)
}

That single line carries a huge amount of information. It tells you that process must respect the lifetime of the HTTP request. If the client disconnects, times out, or cancels the request, process must stop. This is not optional. This is part of the contract.

That contract is what makes context a protocol.

Look at a typical mistake:

func process(ctx context.Context) {
    go work()
}

The goroutine ignores the context entirely. It outlives the request. It may continue working long after the client is gone. This is not a bug you can catch with tests. It is a design error.

The correct version looks like this:

func process(ctx context.Context) {
    go work(ctx)
}

And inside:

func work(ctx context.Context) {
    select {
    case <-ctx.Done():
        return
    default:
        doWork()
    }
}

Now the lifetime is explicit. The goroutine exists because the context exists. When the context ends, so does the work. This is not cancellation as an afterthought; it is structured concurrency.

This is why context.Background() in deep layers is often a smell. It breaks the chain. It creates work with no owner.

Contexts are meant to be passed, not created arbitrarily. A function should only create a new context when it is defining a new lifetime boundary.

For example:

ctx, cancel := context.WithTimeout(parent, time.Second)
defer cancel()

This creates a sub-scope. It says: “This operation must finish within one second, regardless of what the parent allows.” That is a design decision, not a convenience.

Another common misunderstanding is using context to pass data.

ctx = context.WithValue(ctx, "userID", id)

This works, but it should make you uncomfortable. Context values are for request-scoped metadata that crosses API boundaries, not for normal parameters. If a function requires a value to operate correctly, it should take it explicitly. Context is for data that must flow everywhere but should not define behavior.

Good examples include request IDs, authentication tokens, trace IDs. Bad examples include business logic flags, configuration, or domain objects.

This distinction matters because context values are invisible. They bypass the type system. Overusing them turns APIs into riddles.

Another important aspect of context is that it is read-only. You cannot cancel a context you didn’t create. This enforces ownership. If a function receives a context, it can observe cancellation but cannot control it. Only the creator owns the right to end the lifetime.

This mirrors everything you’ve learned so far. Ownership. Lifetimes. Boundaries.

Contexts also compose naturally. A deadline implies cancellation. Cancellation propagates downward. Values flow with the scope. All of this happens without explicit wiring between layers. The protocol is implicit, but the behavior is consistent.

Consider this:

ctx, cancel := context.WithTimeout(context.Background(), time.Second)
defer cancel()

go taskA(ctx)
go taskB(ctx)

Both tasks share the same fate. When the context expires, both must stop. You didn’t need a channel. You didn’t need shared variables. The protocol handled it.

This is why context works so well with goroutines and channels. It doesn’t replace them. It coordinates them.

Beginners often treat context as boilerplate. Experienced Go developers treat it as a map of responsibility. If you follow the protocol, your programs shut down cleanly, release resources predictably, and behave well under failure. If you ignore it, you get goroutines that never die and bugs that appear only under load.

The key idea is simple: every goroutine should have a reason to exist, and that reason should be tied to a context. When the reason disappears, so should the goroutine.

Once you internalize this, you stop scattering context.Background() and start thinking in terms of lifetimes. That shift is subtle, but it’s where Go codebases become robust.

By now, the pattern should be unmistakable. Go is not minimal because it lacks features. It is minimal because it gives you just enough structure to make responsibility visible.

What This Article Focuses On

This article is not a style guide.

It explains what context.Context is meant to represent — and why treating it as a simple cancel switch leads to fragile code.

Want to go further?

This series focuses on understanding Go, not just using it.

If you want to continue in the same mindset, Educative is a great next step.

👉 Explore the full Educative library here

Stop Using Go Channels as Queues — Here’s the Correct Mental Model

Pavel Sanikovich — Wed, 24 Dec 2025 10:50:54 +0000

Go channels are often treated as queues.

They look like queues.
They behave like queues — at least at first.

But designing systems around this assumption is one of the fastest ways to introduce deadlocks, backpressure issues, and subtle concurrency bugs.

This article is part of a practical guide on how Go works under the hood.

Start here if you want the full picture

Channels are one of the most recognizable features of Go. Beginners often fall in love with them instantly. They look clean. They look safe. They feel like a built-in solution to concurrency. And then, slowly, problems appear. Deadlocks. Goroutines that never exit. Pipelines that stall under load. Systems that work perfectly in tests and fail in production.

Almost always, the root cause is the same misunderstanding: channels are treated like queues.

They are not.

A channel is not a data structure. It is a synchronization mechanism that happens to move values. If you treat it like a queue, you will eventually design yourself into a corner. If you treat it like a coordination tool, your concurrent code becomes simpler, safer, and easier to reason about.

Let’s rebuild the mental model from scratch.

When you write this:

ch := make(chan int)

go func() {
    ch <- 42
}()

v := <-ch
fmt.Println(v)

Two things happen, not one.
A value moves from sender to receiver.
Execution is synchronized.

The send cannot complete until the receive is ready. The receive cannot complete until the send happens. This handshake is the essence of an unbuffered channel. The value transfer is almost secondary.

This is why unbuffered channels are sometimes called rendezvous points. They force goroutines to meet.

Now let’s add a buffer:

ch := make(chan int, 2)

ch <- 1
ch <- 2

At first glance, this looks like a queue. You put things in, you take things out. But the semantics are already different. The buffer only delays synchronization; it does not remove it. The third send will still block. The receive will still establish ordering. The channel is still about coordination, just with more slack.

This distinction matters more than it seems.

Beginners often write code like this:

tasks := make(chan Task)

go producer(tasks)
go consumer(tasks)

And then wonder: who closes the channel? What happens if the producer exits early? What happens if the consumer is slower? What happens if there are multiple consumers?

These questions feel annoying at first. But they are not implementation details. They are design questions. Channels force you to answer them because channels encode ownership.

Only the sender should close a channel.
Closing a channel signals “no more values will ever arrive.”
Closing is not cleanup. It is a broadcast event.

This is why closing a channel from the receiver side is almost always a bug.

Consider this pattern:

go func() {
    for v := range ch {
        process(v)
    }
}()

This loop only exits when the channel is closed. That means the sender controls the lifetime of the receiver. This is not accidental. It is the channel expressing a protocol.

Problems begin when channels are used without a protocol.

ch := make(chan int)

go func() {
    ch <- 1
}()

// Who closes ch?

This channel has no clear owner. No termination signal. No lifetime rule. It works for now — until it doesn’t.

Now let’s talk about buffering mistakes.

Beginners often add a buffer to “fix” a deadlock.

ch := make(chan int, 100)

The deadlock disappears. The program runs. Everyone is happy. Until memory grows. Or latency spikes. Or goroutines pile up. Buffers do not fix coordination problems. They hide them.

A buffer should exist because it models reality, not because it makes the program stop blocking.

For example, a worker pool:

jobs := make(chan Job, 10)

for i := 0; i < 5; i++ {
    go worker(jobs)
}

Here the buffer represents a queue of pending work. That is a valid use. But even here, the channel is still enforcing coordination. If producers outrun consumers, the buffer fills and applies backpressure. This is not an accident — it’s a feature.

Another common beginner mistake is assuming channels imply fairness.

ch := make(chan int)

go func() { ch <- 1 }()
go func() { ch <- 2 }()

fmt.Println(<-ch)
fmt.Println(<-ch)

There is no guarantee which value arrives first. Channels do not schedule goroutines. The scheduler does. Channels only synchronize when communication happens, not who gets to communicate first.

This is why channels should not be used to encode priority or ordering unless you explicitly design for it.

One of the most powerful realizations is this: channels are best used at the boundaries of ownership.

Inside a goroutine, use normal variables.
Between goroutines, use channels to hand off responsibility.

For example:

go func() {
    result := compute()
    results <- result
}()

The goroutine owns result. The moment it sends it, ownership transfers. After the send, the goroutine should not touch that value again. This mental rule eliminates an entire class of bugs.

This also explains why sharing pointers through channels is dangerous unless you are careful. The channel does not protect you from shared mutable state. It only synchronizes the moment of transfer.

Channels are not magical. They are explicit. And that explicitness is what makes them powerful.

When beginners struggle with channels, it is usually not because channels are hard. It’s because the design is unclear. Who owns what? Who decides when things stop? What does closing mean? What does blocking mean?

Once you answer those questions, channels stop feeling mysterious.

By now, a pattern should be emerging.
Memory model → lifetimes.
Pointers → ownership.
Goroutines → scheduling.
Channels → coordination.

Everything fits together.

In the next part, we’ll talk about context. Not as a cancellation trick, but as a protocol that ties together lifetimes, goroutines, and ownership across API boundaries. This is where many Go codebases quietly go wrong — and where understanding pays off immediately.

What This Article Focuses On

This article is not about channel syntax.

It focuses on the mental model behind channels — what guarantees they provide, and what they explicitly do not.

Want to go further?

This series focuses on understanding Go, not just using it.

If you want to continue in the same mindset, Educative is a great next step.

👉 Explore the full Educative library here

What the Goroutine Scheduler Really Does (And Why It Matters)

Pavel Sanikovich — Sat, 20 Dec 2025 10:12:15 +0000

Goroutines are often described as “cheap threads”.

That description is convenient — and misleading.

To understand why certain concurrency issues appear only under load, you need a basic mental model of how the goroutine scheduler actually works.

This article is part of a practical guide on how Go works under the hood.

Start here if you want the full picture

At some point every Go developer asks the same question: “How does Go actually run my goroutines?”
Beginners are often told not to worry about it. “The runtime handles it.” “It just works.” “Goroutines are cheap.” All of that is true — and completely insufficient once your programs grow beyond toy examples.

To write reliable concurrent Go code, you don’t need to know everything about the scheduler. But you do need a mental model. Without it, performance issues feel random, deadlocks feel mysterious, and race conditions feel unfair. With it, many problems become predictable.

Let’s build that model.

When you write this:

go work()

you are not creating a thread. You are creating a goroutine, which is a lightweight task managed entirely by the Go runtime. Goroutines live in user space, not in the operating system. They are scheduled by Go, not by the OS.

This distinction matters.

The Go scheduler is based on a simple but powerful idea, often called the M–P–G model. You don’t need to memorize the letters, but you need to understand what they represent.

A G is a goroutine. It contains the function to execute, its stack, and some metadata.
An M is an OS thread. It executes machine instructions.
A P is a processor — a logical resource that connects goroutines to threads.

A goroutine does not run unless it is assigned to a P, and a P does not run unless it is attached to an M. This indirection is what gives Go its flexibility.

The number of Ps is controlled by GOMAXPROCS. By default, it equals the number of CPU cores.

fmt.Println(runtime.GOMAXPROCS(0))

If GOMAXPROCS is 4, Go can run up to four goroutines in parallel. You can create a million goroutines, but only four will execute simultaneously. The rest are waiting in queues.

This already explains something many beginners find confusing: creating many goroutines does not mean doing many things at once.

Consider this code:

for i := 0; i < 5; i++ {
    go func(id int) {
        fmt.Println("goroutine", id)
    }(i)
}

The order of output is unpredictable. This is not because Go is random, but because scheduling is opportunistic. Goroutines are placed in local run queues. Ps steal work from each other when idle. The runtime tries to be fair, but it does not guarantee order.

Now let’s introduce blocking.

go func() {
    time.Sleep(time.Second)
    fmt.Println("done")
}()

While this goroutine sleeps, it does not block the entire program. The runtime parks the goroutine and frees the P to run something else. This is why goroutines are cheap. Blocking calls like time.Sleep, channel operations, and network I/O cooperate with the scheduler.

But not all blocking is equal.

Consider this:

go func() {
    for {
    }
}()

This goroutine never blocks. It spins forever. On a single-core system, this can starve other goroutines. The scheduler will eventually preempt it, but preemption is not instantaneous. This is why CPU-bound loops should yield naturally or be designed carefully.

Now consider system calls.

go func() {
    data, _ := os.ReadFile("large_file.txt")
    fmt.Println(len(data))
}()

If a goroutine enters a blocking syscall, the runtime detaches the M from the P and creates or reuses another M so that other goroutines can continue running. This is expensive compared to normal scheduling, but still far cheaper than managing threads manually.

This explains why Go performs well for I/O-heavy workloads: blocking I/O does not block the scheduler.

Now let’s look at a classic beginner pitfall involving loops and goroutines:

for i := 0; i < 3; i++ {
    go func() {
        fmt.Println(i)
    }()
}

This often prints 3 3 3. Not because the scheduler is broken, but because all goroutines capture the same variable, and execution happens later. The scheduler delays execution long enough for the loop to finish.

The fix is not about timing. It’s about ownership:

for i := 0; i < 3; i++ {
    go func(v int) {
        fmt.Println(v)
    }(i)
}

Here each goroutine owns its own copy. Scheduling no longer changes correctness.

Let’s talk about fairness.

The scheduler uses work stealing. Each P has a local run queue. When it runs out of work, it steals from others. This improves cache locality and reduces contention. But it also means goroutines may not run in the order you expect.

This matters when beginners assume round-robin execution:

go printA()
go printB()

There is no guarantee that printA and printB will interleave evenly. One might run to completion before the other even starts.

Now combine this with channels:

ch := make(chan int)

go func() {
    ch <- 1
}()

go func() {
    ch <- 2
}()

fmt.Println(<-ch)

Which value prints first? You don’t know. The scheduler decides which goroutine runs first, and channels only guarantee synchronization — not fairness.

Understanding this prevents subtle bugs.

One more example that surprises beginners:

runtime.GOMAXPROCS(1)

go func() {
    for {
        fmt.Println("A")
    }
}()

go func() {
    for {
        fmt.Println("B")
    }
}()

Even with one OS thread, both goroutines will run. Go uses cooperative scheduling with preemption. But the output will be uneven. One goroutine may dominate for a while before being interrupted.

This is why relying on scheduling behavior for correctness is a mistake. Correct concurrent programs work under any scheduling order.

The Go scheduler is not something to fight. It is something to design for. When your goroutines have clear lifetimes, when blocking points are intentional, when shared state is explicit, the scheduler becomes invisible — and that’s the goal.

In the next part, we’ll zoom in on channels themselves. We’ll explain why channels are not queues, why buffering changes semantics, and how channel patterns shape program structure. This is where many concurrency designs either become elegant — or collapse under their own complexity.

By now, you should feel it: Go’s simplicity is not hiding chaos. It’s hiding a system that rewards clarity. The scheduler is not your enemy. It’s your silent partner.

What This Article Is About

This article doesn’t dive into runtime source code.

It explains the scheduler at a conceptual level — just enough to reason about performance, blocking, and unexpected behavior.

Want to go further?

This series focuses on understanding Go, not just using it.

If you want to continue in the same mindset, Educative is a great next step.

👉 Explore the full Educative library here

Concurrency in Go Is Easy — Until You Get It Wrong

Pavel Sanikovich — Tue, 16 Dec 2025 14:35:44 +0000

Go makes concurrency look simple.

A few goroutines, a couple of channels — and everything seems to work.

Until it doesn’t.

Most production concurrency bugs in Go come not from complex patterns, but from a small set of wrong assumptions about how goroutines actually interact.

This article is part of a practical guide on how Go works under the hood.

Start here if you want the full picture

Concurrency is the reason many people choose Go. You write go func() {} once, and suddenly your program feels modern, fast, and powerful. Goroutines are cheap. Channels feel intuitive. The syntax is friendly. Everything seems to work — until one day it doesn’t. And when it breaks, it breaks in ways that are deeply confusing for beginners.

This is not a flaw in Go. It’s a consequence of how concurrency really works.

Most beginner tutorials teach concurrency as a mechanical skill. Start a goroutine. Send data through a channel. Use a WaitGroup. Avoid races. These rules are useful, but they don’t explain why certain patterns are safe and others are dangerous. Without a mental model, concurrency becomes cargo cult programming: copy a pattern, hope it works, and pray nothing strange happens in production.

To understand concurrency in Go, you need to stop thinking in terms of threads and start thinking in terms of coordination and ownership.

Let’s begin with the illusion.

go func() {
    fmt.Println("Hello from goroutine")
}()

This looks harmless. It usually works. But what actually happened? You did not “start a thread.” You asked the Go runtime to schedule a function for concurrent execution. You don’t control when it runs. You don’t control where it runs. You don’t even know if it runs at all before the program exits.

This is the first important idea: goroutines are not threads, and concurrency is not parallelism. Goroutines are tasks. The runtime decides how and when they execute. Sometimes they run in parallel. Sometimes they don’t. Sometimes thousands of them share a single OS thread.

Once you accept that loss of control, things start to make sense.

Now consider shared memory:

var x int

go func() {
    x = 42
}()

fmt.Println(x)

This code compiles. It may print 42. It may print 0. It may work for years and then break after a minor refactor. This is not a timing issue. It’s a memory visibility issue.

Concurrency is not just about doing things at the same time. It’s about when changes become visible to other parts of the program. Without synchronization, Go makes no promises. This is why data races are not “bugs you sometimes see.” They are undefined behavior.

Beginners often try to fix this by adding sleep calls:

time.Sleep(time.Millisecond)
fmt.Println(x)

This is not synchronization. This is gambling.

The correct fix is not “wait longer.” The correct fix is to establish a happens-before relationship. In Go, this usually means communication.

done := make(chan struct{})

go func() {
    x = 42
    close(done)
}()

<-done
fmt.Println(x)

Now the program has a guarantee. The receive on done happens after the write to x. This is not a convention. It is a formal property of Go’s memory model.

This leads to one of the most important ideas in Go concurrency: don’t share memory by communicating — communicate by sharing memory. This sentence is often quoted, but rarely understood. It does not mean “never use shared variables.” It means that coordination should happen through communication, not through ad-hoc shared state.

Channels are not queues. They are synchronization points.

Consider this example:

ch := make(chan int)

go func() {
    ch <- 42
}()

v := <-ch
fmt.Println(v)

The channel does two things at once. It transfers a value, and it synchronizes execution. The send cannot complete until the receive happens. This creates a clear ordering in time and memory. That ordering is the real value.

Problems begin when beginners treat channels as generic data pipes without thinking about ownership.

go producer(ch)
go consumer(ch)
go consumer(ch)

Who owns the channel? Who closes it? What happens if one consumer exits early? These are not stylistic questions. They are correctness questions. Every concurrent design must answer them explicitly.

Another common beginner mistake is assuming goroutines are “fire and forget.”

for _, v := range values {
    go process(v)
}

This looks elegant, but it hides several problems. How many goroutines are you spawning? What happens if process blocks? What if it panics? What if it allocates memory faster than the GC can keep up? Concurrency magnifies every inefficiency.

This is why experienced Go developers often prefer boring patterns: worker pools, bounded concurrency, explicit lifetimes. Not because they love ceremony, but because these patterns make ownership and limits visible.

Here is a safer pattern:

sem := make(chan struct{}, 10)

for _, v := range values {
    sem <- struct{}{}
    go func(val int) {
        defer func() { <-sem }()
        process(val)
    }(v)
}

Now concurrency is bounded. Memory usage is predictable. Failure modes are controlled. This is what “thinking concurrently” actually means.

Concurrency also interacts deeply with everything you learned earlier. Closures extend lifetimes. Pointers introduce shared state. Escape analysis moves values to the heap. Goroutines delay execution. Combine these carelessly, and you get subtle bugs that are impossible to reason about without a solid mental model.

This is why Go concurrency feels easy at first and hard later. The syntax removes friction, but the responsibility remains. Go does not protect you from bad design; it gives you tools that make good design explicit.

The goal is not to avoid concurrency. The goal is to structure it so that ownership is clear, lifetimes are bounded, and communication defines order. When you do that, Go concurrency becomes not only safe, but elegant.

In the next part, we’ll go one level deeper and look at what the runtime actually does when you start a goroutine. We’ll explore the scheduler, the M–P–G model, and why understanding it changes how you write concurrent code. This is where many developers finally stop guessing and start predicting behavior.

Concurrency is not magic. It’s discipline, expressed through a language that rewards clarity.

What This Article Focuses On

This is not a concurrency tutorial.

It explains why certain concurrency patterns look correct but break under load, scheduling, or subtle timing differences.

Want to go further?

This series focuses on understanding Go, not just using it.

If you want to continue in the same mindset, Educative is a great next step.

👉 Explore the full Educative library here

Pointers in Go Are Simple — Until You Misunderstand What They Actually Point To

Pavel Sanikovich — Sun, 14 Dec 2025 11:53:58 +0000

Pointers in Go are often described as “simple”.

And syntactically, they are.

But most bugs involving pointers don’t come from syntax — they come from misunderstanding what a pointer actually represents and how it relates to memory, variables, and values.

This article is part of a practical guide on how Go works under the hood.

Start here if you want the full picture

Pointers are where many beginners quietly lose confidence. Even developers with years of experience in other languages often treat pointers in Go with suspicion. They either avoid them entirely or overuse them without understanding the consequences. Both approaches miss the point. In Go, pointers are neither dangerous nor advanced. They are simply the language’s way of expressing ownership and lifetime.

The confusion usually comes from baggage. In C or C++, pointers are a source of power and catastrophe at the same time. They allow arithmetic, manual memory management, and undefined behavior. In Go, all of that is gone. You cannot move a pointer arbitrarily. You cannot free memory manually. You cannot corrupt the heap through pointer tricks. What remains is a safe, constrained tool with a very specific purpose.

A pointer in Go does exactly one thing: it allows multiple parts of a program to refer to the same value. That’s it. No magic. No danger. Just shared access.

Consider the most basic example:

func increment(x int) {
    x++
}

func incrementPtr(x *int) {
    (*x)++
}

Calling the first function changes nothing outside its scope. Calling the second modifies the caller’s value. The difference is not about mutability; it’s about ownership. The value version receives a copy. The pointer version receives access to the original.

Once you see pointers as a question of ownership, many rules that felt arbitrary suddenly make sense.

This is why Go encourages passing small structs by value. When you pass a value, you make ownership explicit. The function receives its own copy and cannot accidentally modify shared state. This leads to code that is easier to reason about, easier to test, and easier to parallelize.

Now compare these two functions:

func process(u User) {
    u.Name = "Alice"
}

and

func processPtr(u *User) {
    u.Name = "Alice"
}

The first function modifies only its local copy. The second modifies shared state. Neither is wrong. But the second carries more responsibility. Any function that accepts a pointer is making a promise: “I might change this.” In Go, that promise is visible in the function signature. That visibility is intentional.

Pointers also interact directly with memory lifetimes, which you saw in Part 3. Returning a pointer means extending lifetime. Capturing a pointer in a closure means sharing state. Passing pointers between goroutines means introducing synchronization concerns. None of these are flaws; they are explicit tradeoffs.

A common beginner question is whether pointers are faster. The honest answer is: sometimes, and often not in the way you expect. Copying a small struct is cheap. Copying a pointer may force a heap allocation. The real cost is not the pointer itself, but the lifetime extension it causes.

This is why Go APIs often look “odd” to newcomers. For example, methods on slices and maps rarely use pointers to slices or maps. That’s because slices and maps already contain internal pointers. Passing them by value still shares underlying data. A pointer to a slice is usually unnecessary and often harmful.

Consider this:

func add(nums []int) {
    nums[0] = 42
}

Even though nums is passed by value, the underlying array is shared. The pointer semantics are already there, hidden inside the slice header. Adding an extra pointer layer does not give you more power; it only complicates lifetimes.

Another area where pointers confuse beginners is method receivers. Go allows both value and pointer receivers, and many people assume one is “more correct” than the other. In reality, the choice expresses intent.

A value receiver means the method does not modify the receiver’s logical state. A pointer receiver means it might. The compiler will automatically take the address or dereference as needed, so this is not about convenience. It’s about communication.

This becomes especially important in concurrent programs. Shared mutable state is the hardest problem in software. Go’s pointer rules make sharing explicit. When you pass a pointer into a goroutine, you are saying: “This value will be accessed concurrently.” That statement alone should make you think about synchronization, ownership, and boundaries.

One of the reasons Go feels simple is that it avoids cleverness. Pointers are not overloaded with meaning. They do not unlock hidden capabilities. They simply make sharing visible. And visibility is the foundation of maintainable systems.

Beginners often try to avoid pointers entirely, hoping to stay in a “safe zone.” Ironically, this leads to worse code. The goal is not to avoid pointers but to understand them well enough to use them intentionally. When you do, pointers stop being scary and start being descriptive.

By now, you should see a clear chain forming. Go’s memory model is based on lifetimes. Escape analysis enforces those lifetimes. Pointers express shared ownership and extended lifetimes. Together, they form a coherent system. Nothing is accidental.

What This Article Is (and Isn’t)

This is not a pointer tutorial.

It focuses on the mental model behind pointers in Go — why they behave the way they do, and why certain assumptions lead to subtle bugs.

Want to go further?

This series focuses on understanding Go, not just using it.

If you want to continue in the same mindset, Educative is a great next step.

👉 Explore the full Educative library here

Stack vs Heap in Go: How Escape Analysis Actually Works

Pavel Sanikovich — Fri, 12 Dec 2025 10:28:31 +0000

One of the most common questions Go developers ask is whether a value is allocated on the stack or on the heap.

And just as often, the question itself is slightly wrong.

In Go, stack vs heap is not a manual decision — it’s a result of escape analysis, and misunderstanding this leads to performance myths and unnecessary micro-optimizations.

This article is part of a practical guide on how Go works under the hood.

Start here if you want the full picture

If you’ve ever profiled a Go program and wondered why a simple function allocates memory, or why a tiny struct suddenly ends up on the heap, you’ve seen the effects of escape analysis. Beginners often learn stack and heap as if they were fixed rules — small things go on the stack, large things go on the heap — but Go doesn’t work like that at all. Size is irrelevant. What matters is lifetime.

A value stays on the stack only if the compiler can prove it never outlives the function that created it. The moment the lifetime becomes ambiguous, that value “escapes,” and Go places it on the heap. This is not a heuristic and not guesswork; it is a strict safety rule.

Understanding this rule gives you x-ray vision into your Go programs. You start predicting allocations before they happen. You see how small changes in code shape memory behavior. And most importantly, you learn to write Go the way the compiler expects — which results in faster, cleaner, more predictable programs.

Let's walk through this from the ground up.

What This Article Focuses On

This article is not about forcing allocations onto the stack or the heap.

It explains how Go’s escape analysis works, why certain values escape, and why trying to “outsmart” the compiler usually backfires.

The Stack: Fast, Local, Temporary

A stack frame exists only during the execution of a function. When the function returns, the frame disappears. If a value can be proven to stay within that frame, it is stack allocated.

A simple example:

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

If we ask the compiler to show escape analysis:

$ go build -gcflags="-m"
<no escape>

Nothing escapes. Everything is on the stack. The compiler is even free to inline the function, meaning the variables may never exist as “variables” at all — they become registers or constants.

This is the ideal path: pure stack behavior, no GC pressure, no heap work.

The Heap: For Values with Extended Lifetime

A value must live on the heap if something outside the current stack frame needs to reference it. Returning a pointer is the most common example:

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

Compiler output:

./main.go:4:9: &x escapes to heap

This has nothing to do with the size of x. The compiler simply sees that the caller needs a reference to x after the function returns. The stack frame cannot hold it anymore.

A beginner often doesn’t realize that the pointer itself is not expensive — it’s the lifetime extension that forces the escape.

Closures: When Variables Quietly Escape

Closures are a classic place where beginners accidentally create heap allocations.

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

Compiler output:

./main.go:6:13: func literal escapes to heap
./main.go:5:5: moved to heap: x

Why?
Because the returned function continues to exist after counter finishes. It needs access to x.
Therefore, x must move to the heap, where its lifetime is no longer tied to the stack frame.

Many beginners write closure-based code without realizing they are allocating memory every time.

Two Constructors, Two Lifetimes, Two Allocation Patterns

This is one of the clearest ways to see escape analysis in action.

Version 1 — returning a value:

type User struct {
    Name string
}

func newUser(name string) User {
    return User{Name: name}
}

And now version 2 — returning a pointer:

func newUserPtr(name string) *User {
    return &User{Name: name}
}

For the first version, the compiler often places User directly into the caller’s stack frame.
For the pointer version, the allocation must occur on the heap.

Same data. Same fields. Same size.
Different lifetime = different memory behavior.

This is why experienced Go developers say: prefer returning values unless you need shared mutable state.

Escape Analysis Loves Clear Ownership

Here’s a subtle example where a tiny rewrite prevents a heap escape:

func sumSlice(nums []int) *int {
    total := 0
    for _, v := range nums {
        total += v
    }
    return &total
}

Compiler:

./main.go:7:12: &total escapes to heap

But if we write it like this:

func sumSlice(nums []int) int {
    total := 0
    for _, v := range nums {
        total += v
    }
    return total
}

Now:

<no escape>

Exact same logic. Different lifetime semantics.

This is the power of understanding escape analysis: your intuition becomes aligned with the compiler.

A Surprising Case: Heap Allocations Without Pointers

Sometimes a heap escape happens even though you don’t return a pointer. A classic example:

func run() {
    for i := 0; i < 3; i++ {
        go func() {
            fmt.Println(i)
        }()
    }
}

Compiler:

./main.go:5:10: func literal escapes to heap
./main.go:4:6: moved to heap: i

Why?
Because the goroutine runs after the loop iteration completes.
It needs access to i.
Therefore i cannot live on the stack.

This is the precise moment when a beginner realizes that concurrency also changes lifetimes.

What Escape Analysis Is Actually Doing

It’s not trying to optimize your code.
It’s proving safety.

If the compiler can prove a value is local → stack.
If it cannot prove → heap.

It’s a conservative algorithm. A value will escape even when theoretically safe, simply because proving otherwise would require solving undecidable problems. Go plays it safe; that’s what keeps programs correct.

How to See Escape Analysis in Your Code

You can observe everything the compiler decides:

go build -gcflags="-m=2"

Or for even more detail:

go build -gcflags="-m -m"

This becomes addictive. You begin scanning your code and predicting escapes before the compiler prints them.

Once you reach that level, Go feels like a language that explains itself to you.

Why This Matters for Beginners

Understanding escape analysis is not about premature optimization.
It’s about forming the mental model that Go expects you to have.

Once you understand lifetimes:

– you choose value vs pointer intentionally
– you design APIs that minimize hidden allocations
– your code scales better under load
– you avoid concurrency pitfalls
– you become predictable to the compiler

This is exactly where beginners stop being beginners.

Want to go further?

This series focuses on understanding Go, not just using it.

If you want to continue in the same mindset, Educative is a great next step.

👉 Explore the full Educative library here

Go Memory Model Explained Simply (But Correctly)

Pavel Sanikovich — Wed, 10 Dec 2025 13:49:46 +0000

Most developers assume that if code “looks sequential”, it behaves sequentially.

In Go, this assumption is often wrong.

The Go memory model is small, precise, and intentionally restrictive — but many concurrency bugs come from misunderstanding what it does not guarantee.

This article is part of a practical guide on how Go works under the hood.

Start here if you want the full picture

Beginners usually hear a reassuring story about memory in Go: small things live on the stack, large things live on the heap, the garbage collector handles cleanup, and escape analysis is a mysterious optimization pass that decides where everything goes. This story is simple, but it hides the actual forces that shape how Go works. The reality is both subtler and more interesting, and once you see it, the way you write Go code changes forever.

The right way to understand Go’s memory model is to forget about stack and heap for a moment and focus instead on the nature of values. Go is a value-oriented language. Everything starts with a value: an integer, a struct, a slice header, a map handle. The crucial question is not “where” the value lives but “how long” it needs to live. Lifetime, not size, governs Go’s memory behavior.

A stack frame lives only as long as a function call. If a value can stay within that frame safely, it will. That decision is the essence of escape analysis. Nothing mystical is happening: the compiler simply looks at each value and decides whether it can remain tied to the call stack or whether something forces it to survive beyond the function that created it.

To see how straightforward this is, consider the simplest possible example:

func makeNumber() int {
    x := 42
    return x
}

If you ask Go to print escape analysis results, you will see nothing dramatic:

$ go build -gcflags="-m"
<no escape>

The compiler sees that x never leaves this function except as a copy. It can happily live on the stack.

But now make a tiny change:

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

Run the same command:

./main.go:4:9: &x escapes to heap

The value x must now outlive the stack frame of makeNumberPtr, because the caller receives a pointer to it. Go cannot keep x on the stack anymore. Nothing about the size or complexity changed. Only the lifetime changed. The moment you return a pointer, your value escapes.

This is where beginners usually pause. Returning a pointer feels harmless, even idiomatic, yet it changes how memory is managed. This is why thinking in terms of ownership is more important than memorizing stack vs heap rules. A pointer implies shared ownership. A value implies independent ownership. The compiler simply enforces this distinction.

Closures reveal this idea even more clearly. Consider this common pattern:

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

Here x is referenced by a function literal that survives after counter returns. Go performs the only correct action:

./main.go:6:13: func literal escapes to heap
./main.go:5:5: moved to heap: x

When you run the program, every call increments the same x, and that would be impossible if x had stayed on the stack. The heap is not a performance penalty here; it is the correct expression of the variable’s lifetime.

Not all escapes are required. Some are accidental. A lot of performance issues in Go come from patterns that unknowingly extend lifetimes.

Compare two versions of a constructor:

type User struct {
    Name string
}

func newUser(name string) User {
    return User{Name: name}
}

Now the pointer version:

func newUserPtr(name string) *User {
    return &User{Name: name}
}

In the first case, User is returned by value. The compiler can often avoid heap allocation entirely by placing the struct directly in the caller’s stack frame. In the second case, returning a pointer forces escape. A beginner may prefer pointer semantics because they “feel cleaner,” but the cost appears only when you look deeper.

The same applies to slices and maps. A slice header is a small struct containing a pointer to underlying data. Returning a slice does not necessarily cause a heap escape; returning a pointer to part of a slice almost always does. Ownership and lifetime drive everything.

The garbage collector fits neatly into this picture. It is not sweeping memory randomly; it is following chains of references established by your program. If nothing points to a value, the value dies. If something still points to it, the value lives. This makes clarity of ownership a performance feature. The simpler your reference graph, the less work the GC performs.

Understanding all of this does not require deep systems knowledge. It requires only the willingness to look under the surface and recognize that Go’s model is not magical. It is logical. And once you see the logic, your intuition sharpens. You start predicting when a value will escape. You notice unnecessary pointers. You understand how closures extend lifetimes. You become aware that Go optimizes for the code you write, not the code you intended.

The Go memory model is approachable because the language removes distractions. There is no manual memory management, no pointer arithmetic, no undefined behavior. What remains is a direct connection between the structure of your program and the shape of its memory. For a beginner, discovering this is often the moment Go stops looking “too simple” and starts looking deeply intentional.

The value of Go lies not in hidden complexity but in transparent mechanisms that reward clear thinking. The memory model is the first place where this becomes unmistakable.

Want to go further?

This series focuses on understanding Go, not just using it.

If you want to continue in the same mindset, Educative is a great next step.

👉 Explore the full Educative library here

Go Under the Hood: Memory, Concurrency, and Mental Models Most Developers Get Wrong

Pavel Sanikovich — Wed, 10 Dec 2025 13:33:55 +0000

Go is often described as a “simple” language.

And syntactically, it is.

But many production bugs in Go don’t come from complex code — they come from incorrect mental models about how Go actually works under the hood.

This guide is a collection of practical explanations about Go’s execution, memory, and concurrency model — not as a tutorial, but as a way to fix the most common wrong assumptions developers make.

Articles in This Guide

Each article below is standalone — you can read them in any order.

Go Memory Model Explained Simply (But Correctly) LINK
Stack vs Heap in Go & How Escape Analysis Actually Works LINK
Pointers in Go Are Simple — Until You Misunderstand What They Actually Point To LINK

How to Read This Guide

These articles are not tutorials.

They focus on why things behave the way they do in Go — especially in situations where intuition often fails.

Want to go further?

This series focuses on understanding Go, not just using it.

If you want to continue in the same mindset, Educative is a great next step.

👉 Explore the full Educative library here

How Vue Reactivity Actually Works Under the Hood (A Simple Explanation With Internals)

Pavel Sanikovich — Mon, 01 Dec 2025 15:00:55 +0000

If you’ve been working with Vue for a while, you’ve probably learned the rules:

ref() holds a value
reactive() makes an object reactive
computed() derives state
changing state triggers a re-render

But none of that explains why it works.

Why does changing count.value make the component update?
Why does Vue know which component depends on which variable?
What exactly happens during render()?

To really understand Vue — and to write scalable, predictable code — you need to understand what’s happening under the hood.

Let’s open that black box.

And don’t worry — I’m going to explain this without computer-science jargon.

The simple idea behind all of Vue: “track” and “trigger”

The entire Vue reactivity system — every ref, reactive object, computed, watcher — is built on two operations:

track()   // remember that some code used this value
trigger() // notify all code that depends on this value

That’s it.

Every time you read a reactive value → Vue calls track().
Every time you write to a reactive value → Vue calls trigger().

Vue keeps a mapping:

reactiveValue → list of functions that should re-run when it changes

Those “functions” are typically the component’s render function, or a computed getter, or a watcher.

This is the entire reactivity system in one sentence:

Vue re-runs functions that used a reactive value when that value changes.

The rest is implementation detail.

Let’s build a tiny Vue-like reactivity system from scratch

Vue 3 uses Proxy under the hood to intercept reads and writes.

Here’s a tiny toy example that mirrors how Vue works:

let activeEffect: Function | null = null

const effects = new Map()

function track(key: string) {
  if (!activeEffect) return

  let deps = effects.get(key)
  if (!deps) {
    deps = new Set()
    effects.set(key, deps)
  }
  deps.add(activeEffect)
}

function trigger(key: string) {
  const deps = effects.get(key)
  if (!deps) return
  deps.forEach(fn => fn())
}

function reactive(obj: Record<string, any>) {
  return new Proxy(obj, {
    get(target, key) {
      track(key as string)
      return target[key]
    },
    set(target, key, value) {
      target[key] = value
      trigger(key as string)
      return true
    }
  })
}

Now watch the magic:

const state = reactive({ count: 0 })

function effect(fn: Function) {
  activeEffect = fn
  fn()
  activeEffect = null
}

effect(() => {
  console.log("count changed:", state.count)
})

state.count++
// → logs: "count changed: 1"

Congratulations — this is the core idea of Vue reactivity.

Vue’s real system is more advanced — optimized dependency tracking, cleanup, effect scopes, watcher flushing — but the foundations are exactly this.

How `ref()` works internally

A ref is just a reactive object with a .value property.

Inside Vue, the implementation is roughly:

class RefImpl {
  private _value: any
  private deps = new Set<Function>()

  constructor(value: any) {
    this._value = value
  }

  get value() {
    trackRefValue(this)
    return this._value
  }

  set value(newValue) {
    this._value = newValue
    triggerRefValue(this)
  }
}

This is why you must use .value — it’s where access tracking happens.

When you write:

const count = ref(0)
count.value++

Vue performs:

track: remember that some component/computed uses count.value
trigger: re-run those functions when the value changes

How `reactive()` works internally

Vue wraps your object in a Proxy. The proxy intercepts all get and set operations.

When you read a property:

state.user.name

Vue calls:

track(state.user, "name")

When you change one:

state.user.name = "Sarah"

Vue calls:

trigger(state.user, "name")

This lets Vue know exactly which fields of which objects your UI depends on.

The real magic: dependency tracking

Here’s a key insight junior developers often miss:

Vue tracks dependencies at runtime, not at compile time.

This means Vue knows exactly which reactive variables your component used while rendering.

Consider this component:

const count = ref(0)
const double = computed(() => count.value * 2)

When double is evaluated:

it reads count.value
so Vue records: “double depends on count”

Thus, when count.value changes → double re-runs automatically.

Vue builds a dependency graph dynamically, every time reactive values are used.

This is why:

computed values update automatically
watchers run when the reactive value they use changes
components re-render when data they accessed changes

Why components re-render

Inside a component’s render function, Vue does this:

evaluates the template → which reads reactive values
tracks each read → maps reactive values → render function
stores these dependencies

Later, if a variable changes:

Vue sees which render functions depend on it
schedules those components to update

So updating state.count will only re-render components that used state.count.

This is why Vue apps can stay performant even with lots of components.

Why some values don't trigger updates

Vue tracks accesses, not assignments.

Consider this:

const state = reactive({
  items: []
})

state.items.push(1)

Push mutates an array without calling set on the array property (because the reference didn’t change).

But Vue patches array methods like push to call trigger() internally — otherwise arrays wouldn’t be reactive.

If you create a custom object with methods, Vue will not track them unless they use reactive data.

Why destructuring breaks reactivity

This confuses a lot of beginners:

const state = reactive({ count: 0 })
const { count } = state   // ❌ reactivity lost

Why?

Because you copy state.count into a standalone variable.
It no longer goes through the reactive proxy.

This explains why Pinia recommends:

const store = useStore()

// ❌ breaks reactivity:
const { count } = store

// ✔ keeps reactivity:
const count = store.count

Or:

const { count } = storeToRefs(store)

Why watchers run too often

Because a watcher reacts to any change of any reactive variable used inside it.

For example:

watch(() => state.user, () => {
  console.log("User changed")
})

This watcher triggers whenever any property of state.user changes.

Vue isn't being "weird".
It’s doing exactly what you told it:

“Tell me whenever this entire object changes.”

If you want precision:

watch(() => state.user.name, () => {
  console.log("Name changed")
})

Why your app re-renders too much

Every unintended use of reactive data inside a render or computed function adds a dependency.

Vue will track it.

Vue will re-run it.

Vue will re-render.

Even if it was an accident.

Final mental model (save this forever)

If you truly understand this sentence, you understand Vue:

Vue re-runs anything that used a reactive value when that value changes.

That’s the whole system.

Everything else — computed, watchers, refs, reactive objects — is just different UI around the same engine.

Once this clicks, Vue stops feeling magical and starts feeling predictable.

Why Your Vue Code Becomes Messy (And How to Keep It Clean From the Start)

Pavel Sanikovich — Mon, 01 Dec 2025 14:47:20 +0000

Most Vue developers don’t notice when their codebase starts falling apart.
At first everything feels simple: a clean component, a small API call, a few reactive variables, a couple of watchers. Vue makes early progress feel effortless.

And then the project grows.

A new screen.
A new flow.
Another API call.
A bit of duplicated state “for now.”
A watcher added as a quick fix.
A temporary boolean to fix an edge case.
A composable created without a clear purpose.
A Pinia store that now holds everything because “it’s global anyway.”

Before you realize it, the app becomes unpredictable:

components re-render for no reason,
data changes in places you didn’t expect,
bugs appear when two features accidentally depend on the same state,
and removing old code feels terrifying because you’re not sure what it breaks.

This article explains why this happens, and more importantly, how to prevent it from happening again — even if you're still early in your Vue journey.

The real reason Vue apps get messy

Vue doesn’t force you into architecture.
It gives you freedom — sometimes too much freedom.

You can put state anywhere: inside components, inside composables, inside Pinia, inside random refs declared in the global scope. You can fetch data inside mounted(), inside composables, inside watchers, inside actions, or inside event handlers.

There are no strict rules, and that means junior developers often do what feels natural:

“I need data → I’ll put it here.”
“I need this flag → I’ll add it here.”
“I need to update something → let me add a watcher.”

This works perfectly… until features start interacting with each other.

Let’s look at an innocent example.

A small component that slowly becomes a monster

You start with this:

<script setup lang="ts">
import { ref, onMounted } from 'vue'
import { api } from '@/api'

const products = ref([])

onMounted(async () => {
  products.value = await api.getProducts()
})
</script>

Nothing wrong here.

Then someone adds filtering:

const filters = ref({})

watch(filters, async () => {
  products.value = await api.getProducts(filters.value)
})

Still fine.

Then another team member adds a “selected product”.
Then “draft product”.
Then pagination.
Then loading states.
Then error states.

Suddenly the component looks like this:

const products = ref([])
const filters = ref({})
const isLoading = ref(false)
const selected = ref(null)
const draft = ref({})
const error = ref(null)

watch(filters, async () => {
  isLoading.value = true
  try {
    products.value = await api.getProducts(filters.value)
  } catch (e) {
    error.value = e
  } finally {
    isLoading.value = false
  }
})

And you feel it:
you already lost control.

Why this happens: components are NOT meant to handle logic

A Vue component should be mostly declarative:
“What should this UI show based on the state?”

But junior developers often write components imperatively:
“What steps must I perform to make this work?”

When you put API calls, derived data, transformation logic, and UI state all in the same file — components become untestable, unreadable, and impossible to refactor.

The first step toward clean architecture is understanding this:

Components should display state, not manage it.

Let’s extract logic.

Moving logic into a composable (the right way)

Instead of stuffing all logic inside the component, we move it out:

// useProducts.ts
import { ref, watch } from 'vue'
import { api } from '@/api'

export function useProducts() {
  const products = ref([])
  const filters = ref({})
  const isLoading = ref(false)
  const error = ref(null)

  const load = async () => {
    isLoading.value = true
    try {
      products.value = await api.getProducts(filters.value)
    } catch (e) {
      error.value = e
    } finally {
      isLoading.value = false
    }
  }

  watch(filters, load)

  return { products, filters, isLoading, error, load }
}

Now the component becomes clean again:

<script setup lang="ts">
import { useProducts } from '@/composables/useProducts'

const { products, filters, isLoading, load } = useProducts()
</script>

The UI becomes declarative.
The logic becomes reusable.
And the complexity stops growing inside the component.

This is already a huge improvement — but it’s not enough.

When state becomes shared between screens

Here’s the next problem junior developers hit:

Two different components need the same data.

Example:

Product list page
Product details page
Admin product editor
Recommendations sidebar
Cart preview

All of them need “products,” but in slightly different ways.

If each component creates its own instance of useProducts(), you end up duplicating:

API calls
transformations
caching
error handling

This is where people jump to Pinia — but often do so incorrectly.

Pinia is not a storage box — it’s a state owner

Many beginners treat Pinia as a place to dump everything:

export const useProductStore = defineStore('product', {
  state: () => ({
    products: [],
    filters: {},
    selected: null,
    draft: {},
    loading: false,
    error: null,
    // more and more...
  })
})

This leads to a store that knows too much, does too much, and depends on too many features.

The correct approach is simpler:

Pinia should own state — and only the state that truly belongs to the domain.

For example, API filters are UI state → they belong in a composable or component.

But the data itself?
That belongs to the domain → it belongs in a store.

A clean, beginner-friendly store structure

Here’s how a clean store might look:

// product.store.ts
export const useProductStore = defineStore('product', {
  state: () => ({
    items: [] as Product[],
    isLoaded: false,
  }),

  actions: {
    async load() {
      if (this.isLoaded) return
      this.items = await api.getProducts()
      this.isLoaded = true
    }
  },

  getters: {
    byId: (state) => (id: number) =>
      state.items.find(p => p.id === id)
  }
})

This is simple, clean, scalable.

The store owns the data.
The composable owns the behavior.
The component owns the UI.

Once this separation clicks, Vue suddenly becomes effortless to scale.

The moment things start to feel “clean” again

A junior developer becomes mid-level the moment they realize this:

not all state belongs in a component
not all state belongs in Pinia
not all logic belongs in a composable

A clean Vue architecture emerges when every layer has a single responsibility:

Components show data
Composables coordinate behavior
Stores own global domain state
API modules own network calls
Types describe structure
Reactivity stays predictable

Clean code is not magic.
It’s the result of putting things where they belong.

A short message for juniors reading this

If your Vue code feels messy right now — that’s normal.

It doesn’t mean you're bad at writing components.
It means you're ready to start learning architecture.

Your goal isn’t to memorize APIs.
Your goal is to understand how data should move through an app.

Once you learn that, scaling will feel natural.

Forem: Pavel Sanikovich

5 Go Bugs That Only Appear in Production

Goroutines That Never Die

Data Races That Only Exist Under Load

The Interface That Is Nil (Except It Isn’t)

Timeouts That Work Locally and Fail in Production

Allocation Patterns That Break at Scale

Why These Bugs Feel “Production-Only”

Want to go further?

Why allocs/op stopped being a good Go performance signal

Retention vs Allocation

Bad retention

Good retention

When allocs/op lies

The real shift in modern Go performance

The takeaway

Why context.Context Is Not a Cancel Button (And Why That Matters)

What This Article Focuses On

Want to go further?

Stop Using Go Channels as Queues — Here’s the Correct Mental Model

What This Article Focuses On

Want to go further?

What the Goroutine Scheduler Really Does (And Why It Matters)

What This Article Is About

Want to go further?

Concurrency in Go Is Easy — Until You Get It Wrong

What This Article Focuses On

Want to go further?

Pointers in Go Are Simple — Until You Misunderstand What They Actually Point To

What This Article Is (and Isn’t)

Want to go further?

Stack vs Heap in Go: How Escape Analysis Actually Works

What This Article Focuses On

The Stack: Fast, Local, Temporary

The Heap: For Values with Extended Lifetime

Closures: When Variables Quietly Escape

Two Constructors, Two Lifetimes, Two Allocation Patterns

Escape Analysis Loves Clear Ownership

A Surprising Case: Heap Allocations Without Pointers

What Escape Analysis Is Actually Doing

How to See Escape Analysis in Your Code

Why This Matters for Beginners

Want to go further?

Go Memory Model Explained Simply (But Correctly)

Want to go further?

Go Under the Hood: Memory, Concurrency, and Mental Models Most Developers Get Wrong

Articles in This Guide

How to Read This Guide

Want to go further?

How Vue Reactivity Actually Works Under the Hood (A Simple Explanation With Internals)

The simple idea behind all of Vue: “track” and “trigger”

Let’s build a tiny Vue-like reactivity system from scratch

How ref() works internally

How reactive() works internally

The real magic: dependency tracking

Why components re-render

Why some values don't trigger updates

Why destructuring breaks reactivity

Why watchers run too often

Why your app re-renders too much

Final mental model (save this forever)

Why Your Vue Code Becomes Messy (And How to Keep It Clean From the Start)

The real reason Vue apps get messy

A small component that slowly becomes a monster

Why this happens: components are NOT meant to handle logic

Moving logic into a composable (the right way)

When state becomes shared between screens

Pinia is not a storage box — it’s a state owner

A clean, beginner-friendly store structure

The moment things start to feel “clean” again

A short message for juniors reading this

How `ref()` works internally

How `reactive()` works internally