Go: Just Go#

1
func processItems(items []Item) {
2
    var wg sync.WaitGroup
3
    for _, item := range items {
4
        wg.Add(1)
5
        go func(i Item) {
6
            defer wg.Done()
7
            process(i)
8
        }(item)
9
    }
10
    wg.Wait()
11
}

No special return type. No async keyword. Just go and a function. The goroutine runs independently. You synchronize explicitly with sync.WaitGroup, channels, or select.

Go’s runtime uses a G-M-P scheduler: goroutines are multiplexed onto OS threads through logical processors managed by the runtime. Goroutines are lightweight and start with small growable stacks, scheduled in user space. Go hasn’t been purely cooperative since 1.14 added async preemption. The runtime can interrupt a long-running goroutine now, but cancellation and shutdown are still cooperative at the application level. That’s the distinction that matters in practice. A goroutine starts with a small growable stack, usually only a few kilobytes, which is why spawning thousands of goroutines is routine in Go. The trade-off is that CPU-bound code without yield points can still starve the scheduler in some scenarios, but it’s rare in practice when you structure work around channels and I/O.

C#: Async All the Way#

1
async Task ProcessItemsAsync(List<Item> items)
2
{
3
    var tasks = items.Select(i => ProcessAsync(i));
4
    await Task.WhenAll(tasks);
5
}

The async and await keywords are viral. Once a method is async, the call chain tends to become async too. Microsoft’s async patterns docs call this the Task Asynchronous Pattern (TAP), and the spread is sometimes called the “async-await virus” or function coloring. You can block at the boundary with .Result or .GetAwaiter().GetResult(), but that often creates deadlock or thread-pool starvation risks in the wrong environment. Task.Run is not a magic adapter for async I/O; it is mostly useful for moving CPU-bound work onto the thread pool.

The compiler turns the method into a state machine. After an await, the continuation resumes through the captured context or scheduler. Otherwise it continues on a thread-pool thread. For I/O-bound work the generated state machine is clean: the compiler emits it, the runtime dispatches it via I/O completion ports on Windows and epoll/kqueue on Linux/macOS, and your code reads linearly. For CPU-bound work, it can be misleading. Task.Run doesn’t make a synchronous method faster; it just moves it to a thread pool worker. Note also that Task.WhenAll over IEnumerable<Task> runs the tasks concurrently, not in parallel. I/O-bound workloads benefit, CPU-bound ones do not.

The mental model that helped me most: in Go, goroutines are the default and synchronous code is the special case. In C#, synchronous code is the default and async is the explicit choice. I feel that asymmetry every day. If you’re trying to recognize the shape of the problem before reaching for a specific tool, the producer-consumer piece walks through when producer-consumer fits, and that’s where worker pools come in when concurrency needs bounding.

Both examples above are intentionally minimal. In Go I reach for errgroup.SetLimit; in C#, Parallel.ForEachAsync or SemaphoreSlim. Production concurrency needs bounding, but the 10-line examples above are about the shape of the primitives, not the production wrapper.

Go: Context Propagation#

1
ctx, cancel := context.WithTimeout(context.Background(), 5*time.Second)
2
defer cancel()
3

4
result, err := fetch(ctx, url)
5
if err == context.DeadlineExceeded {
6
    // timeout
7
}

Context flows through the call stack. Every function accepts it as the first parameter. Cancellation is cooperative: goroutines check ctx.Done() and exit cleanly. The context in Go blog post frames context.Context as a request-scoped value: deadlines, cancellation signals, and request-local data, all passed explicitly so downstream calls can honor the same boundary.

The discipline shows up in tooling. golangci-lint ships a contextcheck analyzer that flags functions which accept a context.Context parameter but fail to forward it to child calls. The convention is so pervasive that “context-aware” is a synonym for “production-ready” in Go codebases. errgroup brings structured concurrency to Go: it binds the lifetime of a group of goroutines to a parent context so a forgotten go keyword can’t leak past the request.

C#: Cancellation Tokens#

1
using var cts = new CancellationTokenSource(TimeSpan.FromSeconds(5));
2
var result = await FetchAsync(url, cts.Token);

Cancellation in C# is also cooperative. Passing a CancellationToken does nothing by itself unless the awaited operation observes it, or your code checks it explicitly. If you want to dig deeper into the Go side, the deeper context-cancellation post traces the lifecycle in detail. It covers patterns most tutorials skip.

Go’s context is more pervasive because it’s the standard pattern everywhere: the first parameter on every exported function, the way everyone agrees it should be. C#‘s token is more optional. Many APIs don’t accept it unless you ask, and async methods that don’t take a CancellationToken are perfectly legal. That flexibility is nice for prototypes and painful for production systems that need predictable shutdown behavior. .NET has been improving the ergonomics around coordinating many tasks, for example with Task.WhenEach, but it still does not give you the same default structured-concurrency shape that Go developers often build with context plus errgroup.

Go: Channels as Pipes#

1
func pipeline(ctx context.Context, urls []string) <-chan Result {
2
    out := make(chan Result)
3
    go func() {
4
        defer close(out)
5
        for _, url := range urls {
6
            if ctx.Err() != nil {
7
                return
8
            }
9
            result := fetch(ctx, url)
10
            select {
11
            case <-ctx.Done():
12
                return
13
            case out <- result:
14
            }
15
        }
16
    }()
17
    return out
18
}

Channels compose naturally. You chain them: fetch → parse → store. Each stage is a function that takes a channel and returns a channel. The pipeline pattern is idiomatic, born directly from CSP (Communicating Sequential Processes), the formal model Hoare designed in 1978 and that Go’s designers deliberately adopted. Goroutines don’t share memory; they pass messages. The “don’t communicate by sharing memory; share memory by communicating” mantra is what makes channels tractable at scale, even when the codebase grows past a hundred thousand lines.

Buffered channels give you the subtle knob Go engineers learn to love: a capacity of 0 makes sends and receives synchronous (rendezvous), capacity 1 lets a writer race ahead by one message, large capacities flatten backpressure into a queue. The same primitive handles fire-and-forget, hand-off, and load-shedding with nothing more than the second argument to make.

C#: Channel and IAsyncEnumerable#

Channel<T> from System.Threading.Channels is the closer equivalent to Go channels. It models producer-consumer coordination, buffering, completion, and backpressure, which is the shape Go gives you for free. IAsyncEnumerable<T> is C#‘s pull-based async stream abstraction: it is great when a consumer wants to iterate results incrementally, but it is closer to for v := range ch than to a Go channel with its own buffered queue and backpressure.

1
async IAsyncEnumerable<Result> PipelineAsync(
2
    IEnumerable<string> urls,
3
    [EnumeratorCancellation] CancellationToken ct = default)
4
{
5
    foreach (var url in urls)
6
    {
7
        ct.ThrowIfCancellationRequested();
8
        yield return await FetchAsync(url, ct);
9
    }
10
}

LINQ-style operators exist for async streams, but the story is version-dependent. Historically you reached for System.Linq.Async / Ix; newer .NET versions are moving async enumerable operators into the platform. Notably, Go’s pipeline pattern translates almost one-for-one to IAsyncEnumerable<T> with yield return await, which I used when porting Go services to .NET. The C# shape is more verbose on the caller side (await foreach versus for v := range ch), but you get composable operators out of the box. Go gives you a primitive and trusts you to build operators. C# ships the operators and asks you to compose them.

Go: Explicit, Immediate#

1
result, err := fetch(ctx, url)
2
if err != nil {
3
    return nil, fmt.Errorf("fetch failed: %w", err)
4
}

Errors return as values. You check them immediately. There’s no hidden exception bubbling through async boundaries.

Every function signature declares its failure modes: fetch(ctx, url) (*Result, error). You can’t ignore them without your linter yelling at you. The result is verbose but boring, in the best possible sense. There’s no “did this async call throw, or did it swallow the exception because I forgot to await?” question. The error is the second return value, every time.

C#: Exceptions Across Task Boundaries#

1
try
2
{
3
    var result = await FetchAsync(url);
4
}
5
catch (HttpException ex)
6
{
7
    // handle
8
}

Exceptions still work in async code, but they behave differently. An unawaited task swallows exceptions. Task.WhenAll over multiple work items throws only the first one, hiding the rest. ValueTask complicates things further: awaiting a ValueTask twice is undefined behavior, and exceptions captured in one may not surface until the result is consumed.

This is the tradeoff: Go makes every error path explicit, which is verbose but transparent. C# lets exceptions flow naturally, which is convenient but can surprise you across async boundaries. A common workaround is returning a Result<T, Error> discriminated union, but it’s not idiomatic in stock C#. The exception model is one of the places C# inherits from its synchronous roots, and those roots show at the worst possible moments.

What is the difference between goroutines and async/await?#

Goroutines are scheduled by the runtime. async/await is a language feature the compiler transforms. They’re not interchangeable: goroutines give you cheap, plentiful concurrency with no completion type; async/await gives you a completion type with no inherent parallelism.

Should I use Go or C# for a backend service?#

Go for high-concurrency network services and infrastructure tooling where explicit composition from primitives is the right shape. C# for services that lean on the .NET ecosystem (ASP.NET Core, Entity Framework, Azure SDKs) or where the team already has deep C# expertise. The choice is about team fit and integration more than throughput.

When should I use Channel vs IAsyncEnumerable in C#?#

Channel<T> when you have multiple producers or consumers and you need backpressure. IAsyncEnumerable<T> when one consumer pulls results incrementally from a single source and you don’t need your own buffer. They solve different problems.

Do goroutines use more memory than C# tasks?#

No. Goroutines typically use less. A freshly created goroutine starts with a small growable stack (a few kilobytes) and grows as needed. A Task object in C# carries more per-instance overhead (state machine, continuations, exception capture), and async methods can allocate heavily on hot paths. Goroutines in the tens of thousands are routine in Go. Tens of thousands of concurrently pending Task objects in C# can indicate high throughput or a leak depending on the workload: a long-running scrape of URLs is fine, a request handler that never awaits is not.