DEV Community: Supriya

Go's context: one goroutine cancels, all goroutines stop

Supriya — Mon, 13 Apr 2026 23:10:00 +0000

One goroutine calls cancel(). Every goroutine stops. Without any of them talking to each other.

In the previous post, we used a single goroutine checking for cancellation before each store run. One goroutine, one ctx, simple.

Now imagine multiple goroutines running concurrently, each doing a different piece of work, each derived from the same parent context.

Think of it like a family group chat. When you post "party's off," everyone in the group sees it: dad, siblings, whoever dad looped in without telling you, even the siblings who are always online but never respond. You don't need to know who's in there. If they're in the group, they get the message.

That's the Go context tree. One cancel() call, everyone stops, however deep the tree goes.

Before we go further: what does `cancel()` actually do?

When you call context.WithCancel, Go gives you two things: a context and a cancel function.

ctx, cancel := context.WithCancel(parentCtx)

ctx is what you pass around. It carries a ctx.Done() method that returns a channel goroutines can listen on. cancel is the function that closes that channel. You call it when you want everything to stop.

Reading from ctx.Done() blocks until cancel() is called. At that point the channel closes and all readers unblock simultaneously. Not a broadcast message, not a loop over goroutines. Just a channel closing.

Always pair context.WithCancel with a defer cancel() on the very next line. Even if nothing goes wrong, forgetting it means the context and its internal resources are never released until the parent is cancelled — a silent resource leak.

If you need to communicate why cancellation happened, Go 1.20+ offers context.WithCancelCause — it lets you attach an error to the cancellation, which consumers can retrieve with context.Cause(ctx). For most cases, WithCancel is enough, but it's worth knowing the option exists.

With cancellation covered, here's how goroutines actually listen for it. Goroutines opt in by listening on ctx.Done() in a select:

select {
case <-ctx.Done():
    // channel closed — clean up and stop
    return ctx.Err() // context.Canceled
default:
    // channel still open — keep going
}

New to Go channels and select? A Tour of Go covers them here.

Child contexts work the same way. When you call context.WithCancel(parentCtx), the child's Done() channel is linked to the parent's. Cancel the parent, and the child's channel closes too, automatically, without any extra wiring.

context.Background() and context.TODO() create brand new root contexts. They can't be cancelled and ctx.Done() returns nil on both. They're meant to be the starting point of a context tree, not a node in one. If you need cancellation, always derive from an existing context using context.WithCancel or context.WithTimeout.

This pattern shows up in Go's standard library. When an HTTP client disconnects, net/http cancels r.Context() automatically. Any goroutine you spawned with that context stops without you doing anything.

A word of caution: passing cancel into goroutines is powerful but should be done deliberately. In production code, it's good practice to keep cancel scoped as tightly as possible — ideally only the goroutine or function that owns the work should be able to stop it. If many goroutines all hold cancel, it becomes harder to reason about what triggered a cancellation and when.

That's the mechanism the context tree runs on. Let's see it with the party supplies story — four functions, one shared context.

// main — hosts the party, owns the root context
func main()

// watchRSVPs — checks if enough people are coming, calls cancel() if not
func watchRSVPs(ctx context.Context, cancel context.CancelFunc, guests []string)

// coordinatePickup — sends goroutines out to each store
func coordinatePickup(parentCtx context.Context)

// pickup — heads to one store, checks phone before each trip
func pickup(ctx context.Context, item, store string) error

Let's walk through each one.

main() — the host. Creates the root context (the family group), spawns watchRSVPs to watch RSVPs concurrently, then blocks on coordinatePickup. When coordinatePickup returns, defer cancel() fires automatically.

func main() {
    guestList := []string{"Alice", "Bob", "Carol", "Dave", "Eve"}

    ctx, cancel := context.WithCancel(context.Background())
    defer cancel()

    // check RSVPs concurrently — calls cancel() if not enough yes
    go watchRSVPs(ctx, cancel, guestList)

    // send goroutines to each store — blocks until all finish
    coordinatePickup(ctx)
}

watchRSVPs — the RSVP watcher. It holds cancel() and checks whether enough people are coming. It also receives ctx and listens on ctx.Done() inside the loop — because even the goroutine that owns cancel() should be stoppable. If coordinatePickup finishes before all RSVPs come in, the context closes and watchRSVPs returns cleanly instead of blocking forever.

func watchRSVPs(ctx context.Context, cancel context.CancelFunc, guests []string) {
    yesCount := 0
    for _, guest := range guests {
        // check phone before calling the next guest
        select {
        case <-ctx.Done():
            return // supplies already handled — no need to keep checking
        default:
        }
        if getResponse(guest) == "yes" {
            yesCount++
        }
    }

    if yesCount < (len(guests)+1)/2 {
        cancel() // party's off — ctx.Done() closes for all goroutines
    }
}

In the previous post, the condition check happened in main before spawning the goroutine. Here both run concurrently — the pickup is already in motion while RSVPs are still coming in. Any goroutine holding cancel() can pull the plug, at any point, from anywhere in the tree.

coordinatePickup — the delegator. Receives the parent context (the family group) and adds a child context for each item. Each goroutine joins the same family group. When the group gets the cancellation, they all see it. wg.Wait() blocks until all pickups finish.

func coordinatePickup(parentCtx context.Context) {
    supplies := map[string]string{
        "cake":     "https://api.bakery.com",
        "plates":   "https://api.costco.com",
        "balloons": "https://api.partycity.com",
    }

    var wg sync.WaitGroup

    for item, store := range supplies {
        wg.Add(1)
        childCtx, childCancel := context.WithCancel(parentCtx)

        go func(ctx context.Context, cancel context.CancelFunc, item, store string) {
            defer wg.Done()
            defer cancel() // clean up this goroutine's context when done

            pickup(ctx, item, store)
        }(childCtx, childCancel, item, store)
    }

    wg.Wait()
}

New to sync.WaitGroup? Check out the official docs here.

You might wonder: if cancelling the parent already stops all goroutines, why create a child context per goroutine at all? The parent handles fan-out cancellation — one cancel, everyone stops. But the child context lets you cancel one goroutine individually without affecting its siblings. If the cake pickup fails and you want to abort just that one without cancelling the plates and balloons, you call that goroutine's own childCancel(). The parent context is the group chat. The child context is a private message to one person.

pickup — one sibling, one store. Checks the family group (ctx.Done()) before heading out. If the party's already been cancelled, the channel is closed and it stops immediately.

func pickup(ctx context.Context, item, store string) error {
    select {
    case <-ctx.Done():
        fmt.Printf("cancelled — skipping %s\n", item)
        return ctx.Err()
    default:
    }
    return fetchFromStore(ctx, store)
}

Here's what they look like together:

// main — hosts the party, owns the root context
func main() {
    guestList := []string{"Alice", "Bob", "Carol", "Dave", "Eve"}

    ctx, cancel := context.WithCancel(context.Background())
    defer cancel()

    // check RSVPs concurrently — calls cancel() if not enough yes
    go watchRSVPs(ctx, cancel, guestList)

    // send goroutines to each store — blocks until all finish
    coordinatePickup(ctx)
}

// watchRSVPs — checks if enough people are coming, calls cancel() if not
func watchRSVPs(ctx context.Context, cancel context.CancelFunc, guests []string) {
    yesCount := 0
    for _, guest := range guests {
        select {
        case <-ctx.Done():
            return
        default:
        }
        if getResponse(guest) == "yes" {
            yesCount++
        }
    }
    if yesCount < (len(guests)+1)/2 {
        cancel() // closes ctx.Done() for all goroutines
    }
}

// coordinatePickup — sends goroutines out to each store
func coordinatePickup(parentCtx context.Context) {
    supplies := map[string]string{
        "cake":     "https://api.bakery.com",
        "plates":   "https://api.costco.com",
        "balloons": "https://api.partycity.com",
    }

    var wg sync.WaitGroup

    for item, store := range supplies {
        wg.Add(1)
        childCtx, childCancel := context.WithCancel(parentCtx) // derived context

        go func(ctx context.Context, cancel context.CancelFunc, item, store string) {
            defer wg.Done()
            defer cancel()
            pickup(ctx, item, store)
        }(childCtx, childCancel, item, store)
    }

    wg.Wait()
}

// pickup — one sibling, one store, checks the group before heading out
func pickup(ctx context.Context, item, store string) error {
    select {
    case <-ctx.Done(): // cancelled — stop before the next store
        fmt.Printf("cancelled — skipping %s\n", item)
        return ctx.Err()
    default:
    }
    return fetchFromStore(ctx, store)
}

No goroutine was cancelled individually. One cancel() call on the parent, everything stops. That's the context tree.

One thing omitted here for clarity: error handling. coordinatePickup spawns goroutines and discards their return values. In real code, you'd want to capture errors — the idiomatic tool for this is errgroup from golang.org/x/sync. It wraps sync.WaitGroup, collects the first non-nil error, and cancels the shared context automatically. Worth reaching for once this pattern feels familiar.

The mistake that breaks the tree: goroutine leaks

I made this mistake myself. I created new contexts mid-flow instead of deriving from the parent, and the first few runs looked fine. But each server restart... the memory climbed a little higher. By the time I opened Task Manager it was already tanking.

There's a version of coordinatePickup that looks almost identical but breaks everything:

// ❌ Wrong — creating a brand new context instead of deriving from parent
childCtx, childCancel := context.WithCancel(context.Background()) // 🚨

vs.

// ✅ Correct — deriving from the parent context
childCtx, childCancel := context.WithCancel(parentCtx)

One character difference in the argument. Completely different behavior.

Imagine dad decided not to delegate to your siblings. Instead he called your cousins. He created a separate "chore group" with just them. Your cousins aren't in the family group. They don't have the family group context.

You text the family group "party's off." Everyone in the family group stops. But the cousins' chore group never gets the message. It's completely disconnected. Cousins keep going. Buying supplies for a party that isn't happening.

That's a goroutine leak. Work continuing that nobody asked for anymore, consuming resources with no way to stop it from the outside.

When you pass context.Background(), you're creating a brand new root, a separate group with no connection to the parent. Your cancel() call never reaches it. The channel it would close is in a completely different context tree.

The rule: always pass context down. Never create a new one mid-flow.

If you ever see a wild goroutine running and eating up resources on your machine with no clear reason why, look for a context.Background() or context.TODO() buried inside a function that should have been receiving and passing a parent context. That's almost always the culprit.

Same context, different roles

The key insight across both posts: watchRSVPs holds cancel() and monitors a condition, pulling the plug when it's met. coordinatePickup holds the parent ctx and passes it down to child goroutines. The pickup goroutines hold child ctx, derived from the parent, cancelled automatically when the parent is cancelled. None of them need to know about each other. ctx and cancel are the only wire between them.

That separation of concerns is what makes Go's context composable. The worker doesn't need to know who cancelled it or why. It just listens on ctx.Done() and cleans up when the channel closes.

New to Go's context? Read Go's context isn't React's Context first — that's where we build the foundation.

What Go misconceptions have cost you the most time? Drop them in the comments — I'd genuinely love to hear them.

Keep Up With My Go Journey

I'm documenting my transition from frontend to backend in public. If you're on a similar path, or just enjoy watching someone learn and fail publicly, follow along:

Go's context isn't React's Context. Think AbortSignal.

Supriya — Mon, 06 Apr 2026 23:00:00 +0000

It was my first time building a server with go and I was figuring out stuff. I've heard about context, but never spent too much time on it. I was too eager to start using...and that's what I did.

I stored all the variables I wanted in context as if it's a HUGE object and kept passing it around the functions. It worked! But it was too late for me to realize that it wasn't how context needs to be used.

It looked something like this.

// ❌ What I tried — treating ctx like a React context store
ctx := context.Background()
ctx = context.WithValue(ctx, "dbConn", db)        // storing a DB connection
ctx = context.WithValue(ctx, "config", appConfig)  // storing app config

// Then passing ctx everywhere and extracting values like this:
db := ctx.Value("dbConn").(*sql.DB)

We all do have bad code days.

This compiles. It runs. And it's wrong: extracting bunnies from a magic hat. The values are in there, but you have no idea what's inside until you reach in.

And unlike React context, which is typed, Go's context values resolve to any (Go's empty interface). No compiler help. The type assertion happens at runtime:

// ❌ This compiles fine — but panics at runtime if the value is missing,
// the wrong type, or stored under a slightly different key
db := ctx.Value("dbConn").(*sql.DB)

If you're coming from TypeScript, this should set off alarm bells. You've just moved a compile-time guarantee into a runtime panic. Compare that to an explicit parameter. The compiler knows exactly what it is, and can't be passed the wrong thing:

// ✅ Type is in the signature — compiler enforces it, no surprises
func GetUser(ctx context.Context, db *sql.DB, userID string) (*User, error) {...}

So if context isn't for sharing state, what is it actually for?

Two things. That's it.

1. Carrying request-scoped values

requestID, a JWT token, the authenticated userID: values whose lifespan matches the request's lifespan. When the request ends, they're gone.

userID is the one that divides devs. If you're only logging it, "request from user abc123", context is fine. Its lifespan matches the request. But if your handler is calling ctx.Value("userID") to fetch user data or make authorization decisions, that's business logic hiding in context. Pass it explicitly instead: visible in the function signature, enforced by the compiler, testable without a context setup.

The rule: context is for observability. Not for driving logic.

One thing to get right: don't use raw string keys. Using "requestID" as a key means any other package could accidentally collide with it. In Go's context, both the key and the value are typed as any (the empty interface). That's why a raw string like "requestID" as a key is risky. Any other package using the same string collides silently.

Define a private type instead:

// private key type — unexported, so no other package can collide with it
type contextKey string
const requestIDKey contextKey = "requestID"

// middleware sets it
func withRequestID(next http.Handler) http.Handler {
    return http.HandlerFunc(func(w http.ResponseWriter, r *http.Request) {
        id := uuid.New().String()
        ctx := context.WithValue(r.Context(), requestIDKey, id)
        next.ServeHTTP(w, r.WithContext(ctx))
    })
}

The private type wraps the string in a new type the compiler treats as distinct, making collisions impossible across package boundaries.

// handler reads it
func handleRequest(w http.ResponseWriter, r *http.Request) {
    id, ok := r.Context().Value(requestIDKey).(string)
    if !ok || id == "" {
        log.Println("warning: requestID missing from context")
        id = "unknown"
    }
    log.Printf("handling request %s", id)
}

The test: does this value die when the request dies? If not, it's a function parameter, not a context value.

2. Cancellation — and why AbortController is the better comparison

Here's a scenario. Your server receives a request and kicks off a fetch to a third-party API. While that fetch is in-flight, waiting on the promise to resolve, your server goes down. The third-party API eventually responds. But there's nobody home. The response arrives, resolves into a void, and the work was wasted.

Or a softer version: the fetch is just taking too long, and you want to bail.

Think of it like this.

You ask your dad to pick up supplies for a party. He grabs his keys, heads out the door. You can picture it. He's already at the store, navigating the aisles, loading the cart.

And then you check the RSVPs. Not enough people are coming. Majority said no.

You need to stop him. But here's the thing. You can only reach him if he has his phone with him. The phone is what makes cancellation even possible. Without it, there's no way to get through. The chore just... continues.

That's ctx. You pass it into the goroutine the same way dad takes his phone with him. It's the thing that keeps the line open between you two.

When you decide to cancel, you call him. That's cancel(). His phone rings. That's ctx.Done(). He checks if he missed a call before heading to the next store. That's select { case <-ctx.Done(): }.

But if he left his phone at home? No ctx. No cancellation. He comes back with a car full of streamers, balloons, and enough snacks for thirty people.

For a party that isn't happening.

You'd get scolded for making him step out for nothing. But nothing compared to explaining why he just spent $300 on a party nobody's coming to.

Note: in Go, "calling dad" isn't literally a phone call. It's cancel() closing a channel. Every goroutine listening on ctx.Done() gets unblocked simultaneously, not one by one. The call analogy is just a way to picture "signalling that work should stop."

In Go, this looks like:

ctx, cancel := context.WithCancel(context.Background())
defer cancel()

// Dad heads out first — he's already in-flight
go dadGetPartySupplies(ctx, []string{"cake", "plates", "balloons"})

// simplified — in real code you'd watch RSVPs concurrently (more on that in post #4)
if !majorityRSVPed(guestList) {
    cancel() // dad is already out — this stops him mid-chore
}

defer cancel() is the safety net. Whether cancel() is called explicitly or the function returns normally, it always runs. No goroutine leak. Calling cancel() twice is safe. It's idempotent.

// Dad checks his phone before heading to each store
func dadGetPartySupplies(ctx context.Context, supplies []string) error {
    stores := map[string]string{
        "cake":     "https://api.bakery.com",
        "plates":   "https://api.costco.com",
        "balloons": "https://api.partycity.com",
    }

    for _, item := range supplies {
        // check phone before heading to the next store
        select {
        case <-ctx.Done():
            fmt.Println("party's cancelled, heading home")
            return ctx.Err() // context.Canceled
        default:
        }

        if err := fetchFromStore(ctx, stores[item]); err != nil {
            return err
        }
    }
    return nil
}

New to Go channels and select? A Tour of Go covers them here.

If you've used AbortController in JS, this is the same idea. You create a controller, pass its signal to fetch, and call abort() when you need to cancel: a timeout, a user navigating away, a component unmounting.

const controller = new AbortController();

fetch('https://api.example.com/data', { signal: controller.signal })
  .then(res => res.json())
  .then(data => console.log(data))
  .catch(err => {
    if (err.name === 'AbortError') {
      console.log('fetch was cancelled — no supplies needed');
    }
  });

controller.abort();

Without AbortController, once fetch starts, you can't stop it. Same problem Go has without ctx. The goroutine just keeps running.

In real code, you often don't cancel manually. You set a deadline instead. context.WithTimeout cancels automatically when time runs out:

// caller sets the deadline — 3 seconds max
ctx, cancel := context.WithTimeout(context.Background(), 3*time.Second)
defer cancel()

getUserDetails(ctx, userID)

// fetchFromEndpoint passes ctx to http.NewRequestWithContext,
// so if the deadline fires mid-request, the HTTP call is cut off there too —
// not just between iterations.
func fetchFromEndpoint(ctx context.Context, url string) error {
    req, err := http.NewRequestWithContext(ctx, http.MethodGet, url, nil)
    // ...
}

// function just receives ctx and listens — doesn't need to know about the timeout
func getUserDetails(ctx context.Context, userID string) error {
    endpoints := []string{
        "https://api.profiles.com/user/" + userID,
        "https://api.billing.com/user/" + userID,
        "https://api.activity.com/user/" + userID,
    }

    for _, url := range endpoints {
        select {
        case <-ctx.Done():
            return ctx.Err() // context.DeadlineExceeded if timeout, context.Canceled if manual
        default:
        }

        if err := fetchFromEndpoint(ctx, url); err != nil {
            return err
        }
    }
    return nil
}

The select catches cancellation between API calls. fetchFromEndpoint passes ctx to the underlying HTTP client. So if the deadline fires mid-request, the HTTP call gets cut off there too. You don't need to check a timer yourself. The context does it.

The default case runs immediately if the channel isn't closed yet, so the goroutine keeps going without blocking. Only when cancel() is called does the case <-ctx.Done() branch runs.

It's ctx that maps to AbortSignal, not AbortController. You pass signal into fetch the same way you pass ctx into a goroutine. Neither initiates the cancellation. They just listen for it. cancel() is the AbortController equivalent. The thing you call to trigger the stop.

JS	Go
`controller.signal`	`ctx`
`signal` passed to `fetch`	`ctx` passed to goroutine
`controller.abort()`	`cancel()`
`addEventListener('abort', ...)`	`<-ctx.Done()`

ctx.Done() is a function that returns a channel which closes when the context is cancelled. The goroutine's equivalent of an abort event listener.

AbortController says: here's a signal you can pass to fetch, call abort() when you're done with it.
context.WithCancel says: here's a context you can pass to goroutines, call cancel() when you're done with it.
Same word. Completely different problem.

Same word. Completely different job.

React's context shares state down a component tree. Go's context does two things: carries request-scoped values that need to travel with a request, and propagates cancellation signals across goroutines.

The confusion is understandable. The word is the same. The mental model is completely different.

Next time you reach for context.WithValue in Go, ask yourself: does this value die when the request dies? If not, it's a function parameter, not a context value.

Next time you spawn a goroutine, ask yourself: does it have a ctx? If not, you have no way to stop it.

I learnt this the hard way. A friend who'd been writing Go for years looked at my code and said: 'Did you even read about context?'

Curious what happens when multiple goroutines share the same context — and one of them gets to decide when everyone stops? I'm publishing a follow-up post next week. We'll build on the party supplies story to get there.

What Go misconceptions have cost you the most time? Drop them in the comments — I'd genuinely love to hear them.

Keep Up With My Go Journey

I'm documenting my transition from frontend to backend in public. If you're on a similar path, or just enjoy watching someone learn and fail publicly, follow along:

Product Mindset Is the Skill Vibe Coding Can't Replace

Supriya — Tue, 31 Mar 2026 05:05:00 +0000

Everyone Can Ship Now. That's the Problem.

A few weeks ago, I built a full quiz app in three hours. Peaky Blinders on one window, Claude on the other. I described what I wanted, and it appeared. I didn't write a single component. I didn't set up a build tool. I didn't think about routing.

I just thought.

That's what vibe coding does. It collapses the distance between idea and implementation so dramatically that the bottleneck is no longer "can you build it" but "do you know what to build."

And most engineers, myself included, are quietly underprepared for that shift.

The Cost of Building Used to Do the Thinking For You

For a long time, the cost of building was a forcing function for clarity. If you were going to spend two weeks on something, you'd better understand it well enough to defend your decisions. The effort of implementation forced you to ask the uncomfortable questions early, because asking them late was painful and expensive.

Vibe coding removes that friction. Which is mostly great. Genuinely. You can go from idea to working thing in an afternoon, and that's kind of wild.

But it also means you can now ship something confidently without ever asking the questions that used to be forced on you by circumstance.

What problem does this actually solve? For whom? What does success look like? What are the tradeoffs? What happens when it scales? What's the failure mode?

These aren't engineering questions. They're product questions. And they've always mattered. They just used to have a built-in enforcer. That enforcer is gone now.

I Felt This Firsthand Building Go Mastery

When I sat down to build Go Mastery, my first instinct was the engineering instinct: what components do I need, how does state flow, what's the data model.

Then I caught myself. This was supposed to be about learning Go, not building a React app to learn Go. Those are very different projects. If I'd gone down that path I'd have spent three hours on architecture and zero hours thinking about whether the quiz would actually teach anything. I'd have shipped a beautiful, thoroughly useless piece of software.

So I forced myself to stay in the product questions first.

Why do most quizzes fail to produce real learning? Because they're built to be completed, not understood. One obviously right answer surrounded by obvious decoys. You don't need to understand anything. You just need to not be distracted. It's less of a test and more of a vibe check.

What would a quiz look like if it made that strategy impossible? One wrong answer surrounded by options that all sound plausible. Suddenly you can't pattern-match your way through. You have to actually think.

What would make it even harder to shortcut? A pushback mechanic. 60% of the time, after you answer, the quiz asks "are you sure about that?" You never know if you're wrong or just being challenged. So you pause, reread, and, if you're like me, briefly question every choice you've made.

None of that thinking required code. It required understanding the problem deeply enough to have opinions about the solution. The implementation took three hours because the thinking happened first.

That's the product mindset. And vibe coding doesn't give it to you. It just makes it more visible when you don't have it.

Hallucinations Are the Same Problem, Wearing Different Clothes

Here's where it gets interesting.

AI hallucinations and learning misconceptions are structurally the same problem. In both cases, something that sounds correct isn't. In both cases, the danger isn't obvious wrongness. It's plausible wrongness. The output that's 90% right and 10% subtly broken is far more dangerous than the output that's just clearly wrong, because at least the clearly wrong answer is easy to catch.

Spotting the obviously wrong answer is table stakes. Spotting the wrong answer when everything around it sounds reasonable, that's the actual skill.

This is why I think misconception-spotting is becoming one of the most underrated skills in engineering. Not skepticism for its own sake, not compulsive fact-checking on every sentence. The specific ability to read something that sounds authoritative and plausible, hold it up against what you actually know, and find exactly where it goes sideways.

That skill is directly trained by building with AI. Every time you prompt Claude or GPT and get back something that's almost right, you're exercising it. Every time you catch a hallucination before it ships, you're getting sharper. It's like going to the gym, except the gym occasionally tries to convince you that goroutines work like JavaScript promises.

The engineers who will thrive in the vibe coding era aren't the ones who can prompt best. They're the ones who can evaluate output best. And evaluating output requires the same thing that evaluating quiz answers requires: understanding the concept deeply enough to know why something is wrong, not just that it is.

What This Means Practically

A few things I've changed about how I work since building Go Mastery:

Before writing a prompt, write the brief. What problem am I solving? Who has this problem? What does good look like? What are the constraints? Five minutes of this saves thirty minutes of iteration and one very confusing diff.

Treat AI output like a quiz answer. Not "is this right?" but "where is this wrong?" The assumption of correctness is the trap. The default should be "this is probably mostly right and I need to find the part that isn't." It usually isn't hard to find.

Study the concepts, not just the syntax. Vibe coding makes it easy to ship Go without understanding Go. But when the hallucination shows up (and it will), you need the mental model to catch it. Surface-level familiarity doesn't give you that. Understanding does.

Think in problems, not features. The question "what should I build?" is less useful than "what problem am I solving and is this the right solution?" Features are easy to generate now. Problems worth solving are still hard to find, and no amount of prompting helps with that part.

The Skill Stack Is Shifting

We're not heading toward a world where engineering skills don't matter. We're heading toward a world where the engineering skills that matter most are shifting up the stack.

Implementation is getting cheaper. Understanding is getting more valuable. Product thinking, knowing what to build, for whom, and why, is becoming the differentiator.

That's not a threat to engineers. It's honestly a pretty good development if you're willing to lean into it. The engineers who've always wanted to think at the product level but got stuck in implementation details now have the tools to do both. The ones who only ever thought about implementation are going to find that better tools make the work harder, not easier, because the tools expose what was always true: code was never the hard part.

Vibe coding doesn't replace thinking. It just makes thinking the job.

I write about Go, full-stack development, and shipping projects without overthinking them. Follow along on LinkedIn if this resonated.

Building Go Mastery: Socratic Learning, Claude Artifacts, and the Art of Productive Struggle

Supriya — Wed, 11 Mar 2026 10:43:47 +0000

I came to Go from the React world. Frontend was comfortable. I knew the mental model: components, props, state, async with promises, then().catch(), async/await. It felt like home.

Go felt like moving into a new city where everything is slightly off. The streets look familiar but the traffic flows the wrong way.

The typed, compiled mindset was an adjustment. JavaScript lets you be loose; Go does not. But the thing that genuinely baffled me was concurrency. In JS, async is a pattern layered on top of the language. Promises chain. await suspends. The mental model, once you have it, is linear.

Goroutines don't work like that. There's no await. No .then(). You launch a goroutine and it runs alongside everything else, communicating through channels. I kept reaching for the async mental model I already had and kept grabbing at air.

That's when I realized the problem wasn't Go. It was that I was trying to learn it the same way I'd learned everything else: skim, pattern-match, move on. For React, that worked. For Go's concurrency model, it absolutely did not.

One Tuesday Afternoon and a Claude Subscription Going to Waste

Around that time, I kept thinking my Claude subscription wasn't pulling its weight. Then one Tuesday after spring break, I finally had a breather. I opened up their Cowork app and started poking around. One thing led to another and I found a remixable hallucination detection game sitting there. It clicked immediately.

We're living in a world flooded with AI-generated content. Finding the wrong pattern, the thing that sounds right but isn't, is becoming a genuine skill. That framing mapped perfectly onto what I was struggling with in Go. I decided to remix it.

I spent three hours that afternoon prompting and thinking through the product on breaks, with Peaky Blinders running on the other window. What surprised me was how easy it felt to describe what the app should do without worrying about the how. That's usually not how I work. As a frontend engineer, I think in components, in implementation. But this was supposed to be about learning Go, not building a React app to learn Go. If I'd done it the other way, I'd have missed the whole point.

So I stayed in the prompt. I brainstormed streaks to keep users coming back. I worried about the wait time between questions. Every question was a fresh API call and the pause felt wrong. The frontend engineer brain kicked in immediately: just add a loader. So I did. But a loader alone felt lazy, so I asked Claude to show random quotes from Go talks and well-known Go engineers while users waited. That helped.

Then came the caching question. I'd recently learned what caching was, in that early curious way where you start seeing it everywhere. My new backend instincts whispered: this is a perfect place to cache something. But I wasn't sure if a cache could be shared across different users. Turns out, with Claude artifact storage, it can.

The design fell into place naturally: shared storage for generated questions, personal storage for each user's streak and progress. The first user to load the app takes the hit of generating questions. Everyone after that gets them instantly. And the more users play, the richer the question pool gets, and the faster it gets for the next person.

That was the first working version. But building it forced me to confront something I'd been doing wrong for years.

The Problem with Most Quizzes (and How I Broke the Format)

I've been cheating myself for years.

Not on exams. On learning. There's a difference, and building this app made me finally see it.

The pattern showed up first in grad school, then again as I started learning Go. I'd sit down for a quiz, skim the options, and pick the answer that felt right. Not because I understood the concept. Because I'd gotten good at finding the odd one out, the option that didn't match the vibe of the others.

I was pattern-matching, not thinking. And it worked often enough that I never questioned it.

That's the problem with most multiple-choice quizzes: they're built to be completed, not understood. One obviously right answer, three obvious decoys. You don't need to understand anything. You just need to not be distracted.

So I flipped it. Instead of one right answer surrounded by wrong ones, Go Mastery has one wrong answer surrounded by options that all sound plausible. Suddenly you can't skim for vibes. You have to read. You have to think. You have to know the why, not just spot the outlier.

And I made it harder still. 60% of the time, after you pick an answer, the app pushes back: "Are you sure about that?" You never know if it's because you're wrong or just unlucky. So you pause, reread, rethink. If you do fail, you get three more tries and a mini lesson that explains what you missed. Failure stops being "you lost" and starts being "here's what you didn't understand."

The Deployment Question: Knowing When to Stop

With the quiz working and the format redesigned, one question remained: does this actually need to be deployed?

That's not laziness. It's a real design decision. I'm in grad school. I don't have weekends. And "deploy it properly" means ongoing maintenance, billing alerts, and infrastructure decisions that compound over time. Before committing to any of that, I wanted to understand what I was actually signing up for.

So I did the math.

A typical question generation on Sonnet runs about 1,200 input tokens + 600 output tokens, roughly $0.012 per question. Add a doubt challenge, a hint, and a lesson for a user who struggles, and a full 10-question session costs around $0.24.

That sounds fine until you think about scale:

100 users/day → $540/month
500 users/day (one Reddit post) → $2,700/month
1,000 users/day (viral) → $5,400/month

(These estimates use Anthropic's Sonnet 4.5 pricing as of early 2026. Always verify current rates before building on this math.)

That's the deployed version. The artifact version costs me nothing to run.

Option 1: Deploy with my API key. Polished, standalone, mine. Also, a billing liability I can't monitor from an assignment deadline.

Option 2: Stay in Claude artifacts. Less control over uptime and updates. Every change means republishing. But users can fork it, remix it, make it their own. And the marginal cost to me is zero.

I chose artifacts. Not because it was easier, but because it was the right tradeoff for this stage. A freely remixable tool that reaches more learners beats a locked-down app I'd eventually neglect.

The Caching Layer: How It Actually Works

If you want to build something similar on top of Claude artifacts, here's the technical reality of the caching layer.

Claude artifact storage gives you two modes: personal and shared. Personal storage is scoped to each user — that's where I store streaks and session progress. Shared storage is visible to everyone who loads the artifact — that's where the generated questions live.

The virtuous cycle this creates:

The first user loads the app and triggers question generation, which seeds one question per topic into shared storage
Any user who clicks "Generate" adds more questions, also cached to shared storage
Every user after that skips generation entirely and pulls from cache
The pool grows organically over time, and API calls drop toward zero

The cache caps at 5 questions per topic. Once full, new generations push out the oldest so the pool stays fresh without growing unbounded.

A few constraints worth knowing if you build on this:

20 MB limit per artifact — more than enough for text-based question data
Text only — no images or binary data
Only works when published — storage operations fail in development, so you have to publish to test the caching layer

The one real tradeoff: updating the question set requires republishing the artifact. That's fine for my use case. But if you need live updates, you'd want a different architecture.

What This Is Really About

Go Mastery started as a Tuesday afternoon side project. It ended up teaching me more about learning than Go did.

The throughline across every decision: make the right things harder, not easier.

Hard to pattern-match answers. Hard to mindlessly click through. Hard to walk away without understanding why you got something wrong. That friction isn't a bug in the design. It's the whole point.

The same principle applied to how I built it. The easy path was spinning up a React app. The better path was staying in the prompt, describing what I wanted, and letting the tool handle the how. That's a different kind of thinking, and it's one I needed to practice.

If you're learning Go, or building learning tools, or just trying to ship something without overthinking it: Go Mastery is here. Fork it, change the topic, make it yours. Try it. Struggle a little. That's the point.

I write about Go, full-stack development, and shipping projects without overthinking them. Follow along on LinkedIn if that sounds useful.

How to set up SSH keys for signed commits

Supriya — Mon, 16 Jun 2025 18:54:46 +0000

SSH keys are used to access and write data into your GitHub repository. Whenever you connect via SSH, you authenticate using the private key file on your local machine.

Before creating a new key, check if you already have one:

# on linux
ls ~/.ssh

# on Windows
ls c:/Users/<your name>/.ssh

Look for files like:

id_rsa  id_rsa.pub  or  id_ed25519  id_ed25519.pub

1. Create your SSH key

You can generate your SSH key pair using ssh-keygen. Many algorithms generate an SSH key pair. Here, we specify the Ed25519 algorithm using the -t flag. The -C flag allows us to add a comment to identify the key and is optional.

ssh-keygen -t ed25519 -C "your_email@example.com"

This generates an SSH key pair (public and private keys) in the c:/Users/<yourName>/.ssh folder on Windows.

Your key pair is saved as:

c:/Users/<yourName>/.ssh/id_ed25519 (private)

c:/Users/<yourName>/.ssh/id_ed25519.pub (public)

On Linux, this is usually: ~/.ssh/. Listing the files in the folder shows two files.

ls


id_ed25519  id_ed25519.pub

2. Add the SSH Key to the SSH Agent

eval $(ssh-agent -s)

# on Linux
ssh-add ~/.ssh/id_ed25519

# on Windows
ssh-add /c/Users/<yourName>/.ssh/id_ed25519

3. Copy the public key

cat shows the file's content. The pipe (|) operator feeds this content as input to the clip command. This copies the file content to your clipboard.

cat ~/.ssh/id_ed25519.pub | clip

4. Add the public key to your GitHub account

Go to GitHub → Profile Icon → Settings.

Navigate to SSH and GPG keys

Click New SSH key

Give it a title (e.g., “Laptop - June 2025”) and paste the key

Since we are using this key to sign our commits, make sure you change the "Key type" to Signing key.

5. Testing your SSH connection

ssh -T git@github.com

You should see something like this after you enter your passphrase (if you configured it while generating the SSH key pair).

If you also want to authenticate repositories with this SSH key, add the same public key again as an Authentication key under SSH and GPG keys → New SSH Key → Change "Key Type" to Authentication key.

6. Use SSH for Your Repo Remote (optional)

If your repo was cloned using HTTPS, you'll need to switch to SSH to use this key to push changes.

git remote set-url origin git@github.com:yourusername/yourrepo.git

7. Signing commits

Enable commit signing and specify SSH key format

git config commit.gpgsign true

# or enable it globally

git config --global commit.gpgsign true

Configure Git to use SSH to sign commits and tags:

git config --global gpg.format ssh

To set your SSH signing key in Git, paste the text below, substituting /PATH/TO/.SSH/KEY.PUB with the path to the public key you'd like to use.

git config --global user.signingkey /PATH/TO/.SSH/KEY.PUB

8. Check for verification on your new commit

When committing changes in your local branch, add the -S flag to the git commit command.

git commit -S -m "YOUR_COMMIT_MESSAGE"
# Creates a signed commit

If you configured a passphrase while setting up the SSH key, provide it. Otherwise, leave it blank.

Now, visit the commits in your repository to check the verified status.

Resources:

A brief overview of HTTP protocol

Supriya — Fri, 18 Aug 2023 10:53:42 +0000

Introduction

Let's start with the basics. The web works on client and server model. Where the Client initiates the request. It passes through the internet and reaches the server. The server then processes it and sends it a response the same way it arrived.

Client - usually the browser. But can also be a web crawler bot indexing the search results.
Internet - many networks of connected computers
Server - THE computer that responds to that particular request

HTTP

HTTP stands for Hypertext Transfer Protocol. But what is Hypertext? Hypertext is a way of linking text to other text or resources. It is the underlying concept of the World Wide Web, where web pages are interconnected by hyperlinks. It is a text which you see on a computer, and on clicking on it redirects to the resource. Furthermore, this resource is a document (usually HTML files) present on a computer (it can be any computer. Be it yours or someone else's on cloud). And now, what is a Protocol? To send this request to the server, we need to follow some standard rules/protocols.

In short, HTTP is the standard set of rules, which describe the way we can make a request, that allows us to transfer a text/file/media (hypertext/hypermedia) over the internet.

Between the client and the server, there are many entities (routers, switches, load balancers) through with the requests get passed. But discussing them would be out of scope for this article. You can read more about this here.

It's Simple and Stateless

All the HTTP messages are human-readable, which makes it easier for the developers to debug and reduces complexity. Whenever a request is made from the client, the server doesn't store any information; which makes it stateless.

You might question, if the server doesn't have the data from previous requests, how will it be able to keep track of what response to send for an authenticated user or a user with different permissions?
Well, though it is stateless; it can keep track of this data using cookies, whenever a new session is created. This is where we store the JWT tokens of an authenticated user in HTTP Header, to let your server know that the user is logged in.

Building Blocks

HTTP is built on top of TCP/IP protocols and consisted of 4 blocks

textual format to represent Hypertext files (HTML)
protocol to exchange these files (HTTP)
client to display these files (browser)
server to give access to these files

Evolution on HTTP

HTTP/0.9

The initial implementation of HTTP was remarkably straightforward. It's also called one-line protocol, which contained only GET method followed by the path to the resource.

REQUEST

GET /fancyWebPage/index.html

RESPONSE

<html>
  HTML page with only text. 
  No images or other resources are included in this file.
</html>

only GET method was provided to access the resources
no HTTP Headers. The response was always a (HTML) file.
no status or error codes. If there was an error, an HTML file with the generated error description was sent.

HTTP/1.0

versioning was added at the end of the resource path.
status code was also sent at the beginning of the response.
HTTP Headers were introduced for both request and responses, which allowed us to send metadata.
This allowed us to transfer documents other than plain HTML if its respective HTTP header value was included in Content-Type
The connection is closed after the response is received. We need to create a new connection for every request.

REQUEST

GET /fancyWebPage/index.html HTTP/1.0
User-Agent: BrowserName/3.0 (OS-Name 2.0)

RESPONSE

200 ok                               # status code
Date: Fri, 11 Aug 2023 12:23:22 IST  # metadata
Server: company/2.0 project/2.8      # metadata
Content-Type: text/html              # metadata
<html>                               # html content
  HTML page with images and other file content. 
  <img src="/cat.png" />
</html>

If the response contained, other resources; subsequent calls are made to the server to fetch them. Here, in the next call, the browser makes a call to the server to fetch the cat.png file.

HTTP/1.1

it introduced 'keep-alive' mechanism. Connections can be reused. There's no longer a need to open multiple connections for each request.
Pipelining was introduced, which allowed the client to make a new request without waiting for the response from the previous one. The responses were sent in the order they were requested.
- But this couldn't be handled well by the proxy servers(entities) between the client and server.
Cache control mechanisms and support for chunked responses was added.
It was easier to create new Headers and methods. It was stable for more than 15yrs.

Here's an image from MDN showing the request/response structure.

HTTPS
Netsape came up with additional layer SSL on top of HTTP to encrypt the transmission of messages between client and server.

Authoring before REST
When the World Wide Web(browser) was created by Tim Berners-Lee, he wanted to create a medium, where everyone can share, edit, create and share the documents over the internet. But eventually, the webpages became read-only for most users. The write access was limited to few folks, who can change these documents on the servers.

In 1996, people of World Wide Web consortium addressed the problem of authoring on the web and HTTP was extended to allow authoring, creating WebDAV - Web Distributed Authoring and Versioning. It is an extension to HTTP that lets clients edit remote content on the web. Any server that supports WebDAV can act as a file server. There are other extentions like CalDAV which allows the client to schedule events on the server and CardDAV, which allows you to share the contact informatiom on the remote server which work similarly.

Popular clients of WebDAV are Microsoft Office, OpenOffice, DropBox, etc. Any fie sharing system you can think of uses WebDAV behind the scenes to create/ share/ modify/ delete your files or folders over the internet.

✨REST✨

In 2000, Representational State Transfer (REST) was designed to use the HTTP protocol. It uses the basic methods defined in HTTP/1.1 and allowed any web application to modify the data, without the need to update its servers. One drawback of it was each website defined its own RESTful APIs and had complete control over them.

Think of this as using an open API(MovieDB) on your website, to display the content, but also allowing your clients to modify the data(marking a movie as favourite). But any modification of the data wouldn't effect the data in server where the Open API's being hosted. But instead, these changes are persisted on your website server where you handle these changes on top of Open API data.

HTTP/2

As webpages became complex, more scripts being added for interactivity of the webpage... more and more data was being transfered through the HTTP requests. This created more overhead for the HTTP/1.1 connections. In early 2010, Google created an experimental protocol SPDY, which laid foundation for HTTP/2.

Officially standardised in 2015 and 35.7% of websites use HTTP/2

Binary protocol, unlike HTTP/1.1 which is text based
multiplexed protocol. Enables the client to make parallel requests.
It compresses headers, which are common for similar set of requests. This removes duplication and overhead of data transmitted.
Server push. This allows the server to populate the client cache

HTTP/3

It uses QUIC instead of TCP in the transportation layer. 26.5% of websites use HTTP/3. QUIC is a connection-oriented protocol that creates a stateful interaction between a client and server. QUIC authenticates the entirety of each packet and encrypts as much of each packet as is practical. QUIC packets are carried in UDP datagrams [UDP] to better facilitate deployment in existing systems and networks.

Initially an acronym QUICK was described as Quick UDP Internet Connections, but RFC 9000 mentions it as name, not an acronym.

multiplexed protocol, unlike HTTP/2 which runs on single TCP connection. QUIC runs on multiple UDP streams.
Endpoints communicate in QUIC by exchanging QUIC packets. Most packets contain frames, which carry information and application data between endpoints.
Application protocols exchange information over a QUIC connection via streams, which are ordered sequences of bytes.
- bidirectional streams, which allow both endpoints to send data;
- unidirectional streams, which allow a single endpoint to send data.
A credit-based scheme is used to limit stream creation and to bound the amount of data that can be sent.
QUIC depends on congestion control to avoid network congestion using QUICK-RECOVERY algorithm for detecting and recovering losses.

How to create a server with HTTP/2/3 protocol?

Many programming lanaguages have in-built libraries, for us to create servers. Node.js has http, http2 libraries to build implement servers with HTTP protocols.

Golang has similar libraries http, and http2, http3✨

But the support for creating servers which use HTTP/3 is still a work in progress in Node.js community. As of today, 18 Aug 2023, there's no library available for us to get on HTTP3.

Keep track of HTTP/3 and QUIC

Node.js - status : currenly blocked on QUIC implementation #38478

Reference
HTTP - MDN Docs
What is WebDAV
RFC 9000

Icon by Freepik

DEV Community: Supriya

Go's context: one goroutine cancels, all goroutines stop

Before we go further: what does cancel() actually do?

The mistake that breaks the tree: goroutine leaks

Same context, different roles

Keep Up With My Go Journey

Go's context isn't React's Context. Think AbortSignal.

1. Carrying request-scoped values

2. Cancellation — and why AbortController is the better comparison

Same word. Completely different job.

Keep Up With My Go Journey

Product Mindset Is the Skill Vibe Coding Can't Replace

Everyone Can Ship Now. That's the Problem.

The Cost of Building Used to Do the Thinking For You

I Felt This Firsthand Building Go Mastery

Hallucinations Are the Same Problem, Wearing Different Clothes

What This Means Practically

The Skill Stack Is Shifting

Building Go Mastery: Socratic Learning, Claude Artifacts, and the Art of Productive Struggle

One Tuesday Afternoon and a Claude Subscription Going to Waste

The Problem with Most Quizzes (and How I Broke the Format)

The Deployment Question: Knowing When to Stop

The Caching Layer: How It Actually Works

What This Is Really About

How to set up SSH keys for signed commits

1. Create your SSH key

2. Add the SSH Key to the SSH Agent

3. Copy the public key

4. Add the public key to your GitHub account

5. Testing your SSH connection

6. Use SSH for Your Repo Remote (optional)

7. Signing commits

8. Check for verification on your new commit

A brief overview of HTTP protocol

Introduction

HTTP

It's Simple and Stateless

Building Blocks

Evolution on HTTP

HTTP/0.9

HTTP/1.0

HTTP/1.1

HTTP/2

HTTP/3

How to create a server with HTTP/2/3 protocol?

Keep track of HTTP/3 and QUIC

Before we go further: what does `cancel()` actually do?