Inside Go Systems Programming: A Conversation with Mihalis Tsoukalos

Concurrency patterns, runtime optimizations, and memory management in modern Go

From goroutine scheduling quirks to profile-guided optimizations, Go has grown into a language that balances simplicity with systems-level power. In this conversation, we speak with Mihalis Tsoukalos—author of Mastering Go, Fourth Edition (Packt, 2025)—about what it takes to write high-performance, maintainable Go in today’s evolving ecosystem.

Mihalis is a Unix systems engineer and prolific technical author whose books Go Systems Programming and Mastering Go have become staples for developers working close to the metal with Go and Linux. He holds a BSc in Mathematics from the University of Patras and an MSc in IT from University College London, and his work has appeared in Linux Journal, USENIX ;login:, and C/C++ Users Journal. His expertise spans systems programming, time series data, and databases, but his reputation in the Go community comes from distilling that low-level experience into accessible, practical guidance.

In this interview, we explore what motivated the fourth edition of Mastering Go and the audiences it serves, the realities of structuring goroutines and channels correctly, and the concurrency patterns that actually hold up under production workloads. We also dive into Go’s runtime improvements, profiling and memory-management workflows, and the maturing role of generics in real-world projects. Beyond language features, Mihalis shares his perspective on observability, the expanding standard library, and how Go compares with Rust and Zig for systems programming. Looking ahead, he offers a candid view of where Go is headed—from concurrency safety to ecosystem maturity—without losing sight of its defining trait: clarity without unnecessary complexity.

You can watch the full conversation below—or read on for the complete transcript.

---

1: What motivated you to write the 4th edition of Mastering Go? Who should pick it up, and what kind of projects will the book help them with?

Mihalis Tsoukalos: First of all, I want to start with a disclaimer—nothing, no book or any other resource, can replace experience. You have to try things. That’s the general idea, and that’s why I wrote the book—to make you try.

The main reason for the 4th edition of Mastering Go was the continued growth and evolution of Go. Since the last edition, the language has seen major changes. The most important was the addition of generics in Go 1.18, a long-awaited feature that really shifted how developers think about type safety and code reuse. Alongside that, we’ve had improvements to modules, better WebAssembly support, and lots of enhancements across the standard library and toolchain, including faster testing for the testing process. So it made perfect sense to update the book to reflect where Go is today.

Another big motivator was feedback from the Go community. Mastering Go has always aimed to be a practical, hands-on guide, and readers kept asking for more real-world examples—especially about things like concurrency, networking, and systems-level programming. This edition builds on that by going deeper into those topics and refining the guidance on writing idiomatic, maintainable Go code. Again, I have to say it: nothing can replace experience. You have to try things all the time. That’s the point of learning something new.

The book is best suited for intermediate to advanced developers—people who already understand the basics of programming and want to work with Go and take their skills further. It is particularly useful for engineers working on backend systems, command-line infrastructure tools, high-performance network applications, or cloud-native services. It’s also a solid resource for developers coming from languages like C, C++, Java, or Python who want to build scalable, efficient systems.

For example, it can be applied in projects like migrating a payments platform from Node.js to Go to reduce latency in transaction processing and better handle traffic, writing a custom reverse proxy in Go to maximize performance and manage connection concurrency efficiently, or an observability team building high-throughput log collectors or trace aggregators that must process and forward millions of events per second.

So overall, this edition is not a minor update—it’s a reflection of how far Go has come as a language and how central it is becoming in areas like cloud computing, DevOps, and systems engineering. It is really for anyone serious about mastering Go and using it to build high-performance, real-world applications.

2: Today, Go’s concurrency model remains a major draw, with Go 1.22 fixing the long-standing loop variable capture issue. How do you now recommend structuring goroutines and channels to avoid common bugs?

Mihalis Tsoukalos: The concurrency model of Go has always been one of its strongest features because it’s simple, easy to understand, yet powerful. You can’t have everything, but what Go offers is pretty much what programmers want. Goroutines are lightweight, channels give you a clear way to coordinate between them, and it is generally easy to express concurrent logic in a readable way.

But you can always go wrong, especially when working on more complex or high-performance systems. One issue that has tripped up a lot of developers over the years was the loop variable capture problem. If you launched goroutines inside a loop, you could accidentally end up capturing the loop variable in a closure, which meant that all your goroutines might reference the same variable—not what you intended. Usually, you wanted each goroutine to take a different variable value. The typical workaround was to reassign the variable inside the loop, but it was error-prone. This was finally fixed in Go 1.22: now the language creates a new instance of the loop variable on each iteration, so closures and goroutines get the correct value automatically. It’s a small change in behavior, but it eliminates a very common class of bugs and makes concurrent code cleaner and more predictable.

That said, even with this fix in place, you still need to be cautious when writing concurrent code. A few best practices:

• Always be explicit about goroutine ownership and lifecycle. The best way to do that is by using context.Context to manage cancellation and timeouts. This ensures goroutines don’t hang around longer than they should, avoiding memory leaks and unpredictable behavior.

• Limit concurrency when needed. Just because goroutines are lightweight doesn’t mean you should spin up thousands of them without thinking. If you’re processing a large number of tasks or I/O operations, use worker pools, semaphores, or bounded channels to keep things under control.

• Avoid unbuffered channels for high-volume communication. They’re great for synchronization, but if you’re passing a lot of data around, buffered channels reduce blocking and improve performance.

• Always close channels properly. Only the sender should close the channel, and only once. Closing channels from multiple places or from the receiver side can cause panics or race conditions.

• Use the select statement defensively, especially when working with multiple channels. A default case can help you avoid blocking in situations where responsiveness matters, like event loops or fault-tolerant systems.

• Don’t force everything through channels. Although they look practical at first, sometimes mutexes or atomic operations are a better fit. Think carefully before you start writing code and designing your program.

So overall, Go 1.22 makes life easier for concurrent programming, but writing robust concurrent code still requires discipline, clear design, and a good understanding of how goroutines and channels behave under the hood. That’s what really helps you build systems that are both maintainable and production-ready. Again—think before you start writing code, and don’t just throw in goroutines because they’re lightweight.

3: When you think about concurrency at a systems level, which patterns do you find most effective for real-world workloads? Are there particular idioms you keep returning to, like worker pools or pipelines?

Mihalis Tsoukalos: At the systems level, concurrency is not just a feature—it’s a design principle. It influences how your software scales, how efficiently it uses resources, and how it behaves under pressure. Go gives you the primitives—goroutines and channels—but using them well requires a solid set of patterns you can rely on.

The first is worker pools. They are probably the most universally effective pattern. The Apache web server used to do this with threads. Instead of spawning a new goroutine for every task, you maintain a fixed set of workers that pull from a task queue. This gives you controlled concurrency—you’re not overloading the system with thousands of goroutines, and you stay within limits like memory, file descriptors, or database connections. This makes system behavior under load much more predictable because you know exactly what resources you’re using. For example, on a project I worked on, we used worker pools in a log processing service that handled thousands of files per hour without any issues.

The second pattern is pipelines. These are great when you want to break a task into stages and process each stage concurrently. Each stage runs in its own goroutine and passes data to the next using a channel chain. It’s a clean way to handle streaming data transformations or multi-step processing. It encourages modularity and makes it easier to deal with backpressure and separation of concerns.

Another critical piece is context.Context, which I consider non-negotiable in any serious concurrent Go application. It’s the standard way to manage timeouts, cancellations, and deadlines across goroutines. If you’re handling HTTP requests, running background jobs, or coordinating distributed tasks, context helps you shut things down cleanly and avoid goroutine leaks. This is especially important when interacting with external systems like databases or APIs, where you don’t want calls hanging indefinitely. For example, if you’re writing a TCP server and connections are not closed properly, you might run out of ports to serve new requests.

Another pattern I use is fan-out/fan-in. Fan-out means launching multiple goroutines to handle parts of a job in parallel, and fan-in means collecting the results into a single place. Combined with worker pools, this is a powerful way to parallelize work and aggregate results efficiently. I used fan-out/fan-in for a monitoring aggregator service with many microservices for health and metrics data—some over HTTP—and then collected the results into a single response.

I also rely heavily on select statements. Being able to multiplex across multiple channels or listen for a cancellation signal or timeout is incredibly powerful. It helps you write responsive systems that can recover from delays, retry on failure, or time out gracefully.

One principle I’ve learned over time: don’t reach for channels by default. A mutex or an atomic operation might be more appropriate, creating a simpler, cleaner, and less error-prone design.

Finally, goroutine supervision is critical. You need to track what your goroutines are doing, make sure they shut down cleanly, and prevent them from sitting idle in the background.

To sum up: the patterns I find most effective are worker pools, pipelines, the context package, fan-out/fan-in, and select statements. These help you create reliable, maintainable concurrent Go code.

4: Let’s talk about Go’s runtime performance, which has improved noticeably. Tail latencies are down and the garbage collector is smarter. What profiling techniques do you recommend to help teams actually realize these gains?

Mihalis Tsoukalos: That’s a good question, because sometimes you have issues and you don’t know what’s going on behind the scenes. Go has made real progress on runtime performance. The garbage collector in particular has seen big gains in terms of pause times and CPU usage. The garbage collector runs as a goroutine—everything in Go is a goroutine, including the garbage collector. The special thing about it is that sometimes, for the garbage collector to operate, everything else must freeze briefly, because you can’t create new variables while the collector is cleaning up.

Tail latencies have also come down, which makes Go a strong option for performance-sensitive systems like APIs, proxies, and backend infrastructure. But those gains don’t happen automatically—you need to profile and measure to benefit from them. Optimization without measurement is guesswork.

Go provides excellent tools for profiling. With the right approach, those tools can lead to real improvements. A practical point: don’t wait until you have a problem to learn about optimization and measurement. Experiment ahead of time so that when a problem arises, you’re ready to use the tools. Also, be very careful when using them on production systems—you might crash them. Don’t run measurements during peak hours unless it’s absolutely necessary.

The first tool I recommend is Pprof, which is built in and very powerful. The net/http/pprof package exposes several types of profiles—CPU, heap, goroutines, blocking operations, mutex contention—and you can access them through an HTTP endpoint in your web browser. Then you can visualize them using go tool pprof or one of the newer web interfaces.

I usually start with CPU profiles. Run them under realistic load and see where your code is spending time—it’s often not where you expect. Heap profiles are equally important, especially now that the garbage collector is more efficient. If you can cut down unnecessary allocations, the collector has less to clean, and your application runs more smoothly.

One mistake teams make is profiling only with benchmarks or local tests. You need to profile under real workloads in production or in a staging environment that closely mimics production. Many teams now include Pprof endpoints in production, behind secure admin-only routes, so they can safely collect data without affecting users.

For deeper insight, I recommend runtime tracing. The runtime/trace package provides a timeline of goroutine scheduling, system calls, garbage collection, and other events. Paired with Pprof, it helps explain why a goroutine was delayed or what caused a latency spike. You can collect traces with go test -trace or via code, and then explore them with go tool trace.

If you’re doing micro-optimizations, the Go benchmarking framework is excellent. Metrics like allocations per operation, bytes per operation, or nanoseconds per operation help you track how small changes affect performance, especially in tight loops or hot paths like serialization or hashing. Even one extra allocation can have a big impact under heavy load, so it’s worth running go test -bench regularly if you’re tuning critical functions.

It’s also important to watch for goroutine leaks or contention. Use goroutine and block profiles to track how many goroutines are running and whether they’re getting stuck. If the goroutine count keeps rising, that’s often a sign of a leak or unexpected blocking.

Beyond profiling, observability matters. The best-performing teams invest in continuous metrics and dashboards. Tools like Prometheus, combined with Go’s ability to export metrics, let you track garbage collection pause times, allocation rates, goroutine counts, and more. With alerting, you can catch issues before they impact users or your boss—which is never a good surprise.

A concrete case: I once worked on a high-throughput telemetry pipeline. The team was seeing unusually high CPU usage during peak hours, even though the runtime looked idle. The issue turned out to be repeated use of json.Marshal inside a loop, which was allocating and copying far more data than necessary. Replacing it with a streaming encoder solved the problem and made everything much faster.

So in short, Go’s runtime has improved, but to realize those gains you must measure continuously, profile under real workloads, and act on what you find.

5: Profile-guided optimization became stable in Go 1.21. Where does PGO make a real difference, and when might it not be worth the effort?

Mihalis Tsoukalos: The stabilization of profile-guided optimization (PGO) in Go 1.21 was a big milestone for performance-focused developers. Go has traditionally emphasized implicit, fast compiler optimizations, but PGO changes that. It gives us a new way to fine-tune performance based on how our code actually runs in production.

In simple terms, PGO lets the compiler make smarter decisions using real-world runtime data—things like which functions are called most often, which branches get taken, and where the hot paths are. With that information, the compiler can reorder functions to improve caching, inline code more intelligently, and reduce indirect calls. The result is lower CPU usage and better latency, especially in high-throughput or tight-loop scenarios.

So where does PGO shine? It’s great for performance-critical systems with stable workloads—things like low-latency services, backend infrastructure, proxies, or message brokers. In these environments, even small improvements in CPU can translate into real wins. It also makes a difference in hot-path code: tight loops that run millions of times, or CPU-bound routines like encoders, parsers, or math-heavy computations. PGO helps optimize layout and branching in those areas, reducing stalls and improving instruction-cache behavior.

If you’re running large-scale or long-lived services, even small gains add up—a 5% CPU saving across hundreds of instances is significant.

That said, PGO isn’t always worth the effort. For applications with unpredictable or highly variable workloads, the profile you generate today might not reflect tomorrow’s behavior. It’s also not ideal for short-lived command-line tools or scripts. And if your codebase is still changing rapidly, PGO is premature. Finish stabilizing your application first, then consider it.

In general, PGO is a powerful tool, but like any optimization technique, it’s most effective when used deliberately. If you’ve already profiled your application, you know where the bottlenecks are, and you want to squeeze out more performance without rewriting code, then PGO is a great next step. But it won’t solve every problem. My advice is to experiment with it on your own time so you’re ready to use it when it’s truly needed.

6: Memory is always a tricky area. What is your typical workflow for diagnosing memory leaks or reducing high allocation rates in Go systems? Do you have any favorite tools or patterns you like using?

Mihalis Tsoukalos: Although modern computers have plenty of memory, we still need to watch for leaks and excessive allocations. When I’m diagnosing memory issues in Go—whether a potential leak or just high allocation pressure—the first step is to establish a baseline. That means running the service under real or representative load and collecting memory data that reflects actual behavior, not just synthetic benchmarks.

From there, I rely heavily on Go’s built-in tooling, especially Pprof. I usually instrument the service with an HTTP endpoint using net/http/pprof, then capture heap profiles at different points—typically one right after startup and another after the service has been running under load. Comparing these snapshots helps answer key questions: Are allocations growing continuously? Which types are taking the most memory? Is the garbage collector doing more work than expected?

I load these profiles into go tool pprof or use the web interface, focusing on views like “in-use space” or “in-use objects.” If I see unexpected memory growth, I look for object types that shouldn’t be long-lived but are still hanging around. I also use the -alloc_space and -alloc_objects views to see where allocations are happening most frequently. That helps distinguish between a true leak and simply too many short-lived allocations.

A common pattern I follow is taking delta comparisons between snapshots. If memory usage looks flat but allocation counts are high, that’s usually a sign of churn, not a leak. Tools like go test -bench -benchmem are useful here—they show allocation behavior in tight loops or hot paths and help validate changes quickly.

When reducing allocations, I start with escape analysis. Running go build -gcflags=-m tells you which variables are escaping to the heap and why. Small changes—like passing a pointer instead of a value, or reusing a buffer—can keep data on the stack and reduce garbage collector pressure. If I see repeated allocations of slices, maps, or temporary structs in performance-sensitive areas, I consider sync.Pool, preallocating, or reusing buffers carefully. Even avoiding repeated string concatenations in loops or unnecessary interface conversions can make a noticeable difference.

For long-running services, I also recommend taking full memory dumps periodically and tracking object retention over time. That helps catch leaks caused by forgotten references. Continuous monitoring with Prometheus and visualization in Grafana is also valuable—it makes unexpected trends easy to spot.

Ultimately, avoiding memory leaks comes down to habits: profile early, understand your allocation patterns, avoid global state, and monitor in production. It’s not just about saving memory—it’s about running a system that behaves predictably under load and doesn’t wake you up in the middle of the night.

One memorable case involved a team whose Go service gradually climbed in memory usage over several days, even under steady load. Garbage collection seemed fine, but comparing heap profiles revealed that a map of cached Protobuf messages was never shrinking. The problem was a custom cache with no eviction policy—it just kept growing. To make matters worse, the keys were strings derived from user input, so the cardinality was unbounded. The fix was introducing a bounded LRU cache with periodic cleanup. The key insight came from seeing that the live object count of a specific type kept rising across heap snapshots. Without those profiles, it would have been much harder to pinpoint and fix.

7: Generics have been around for a couple of releases now. What patterns have you seen work well, and where do you think developers are overusing or misusing them?

Mihalis Tsoukalos: Now that generics have had time to mature over a few Go releases, we are starting to see clear patterns around where they shine and where they can go off the rails.

One of the most effective use cases has been writing reusable, type-safe data structures and algorithms. Things like generic slices, sets, maps, or utility functions—map, filter, reduce—have become much easier to implement in a way that’s both clean and performant. This has led to better library code, especially in packages dealing with collections, number crunching, or parsing. Libraries that used to rely on the empty interface and type assertions now benefit from compile-time safety with very little extra syntax. That’s a big improvement in terms of both correctness and readability.

Another area where generics work really well is domain-specific helper functions. For example, a pagination utility that works across different types of records, or a retry wrapper that can handle arbitrary operations. These kinds of generics eliminate boilerplate and keep APIs consistent without losing clarity. When used thoughtfully, they make code more declarative and reduce the need for duplicating logic across packages or modules.

That said, there have also been missteps. A common one is overgeneralization—creating overly abstract, flexible APIs just because the language allows it. Another is wrapping generic types in ways that obscure intent. Instead of simply using a slice of type T, some developers introduce unnecessary abstractions that add layers without real benefit, making the codebase harder to understand.

There’s also a tendency among some developers to import functional programming paradigms wholesale—monads, chaining combinators, deeply nested generic utilities. While elegant in languages designed for them, these patterns often clash with Go’s core philosophy of clarity, simplicity, and explicit flow of control. The result can be clever-looking code that’s hard to read and even harder to debug.

In short, generics are a powerful addition to Go, but like any powerful tool, they need to be used with purpose and restraint. Think before you reach for them, and prefer clear designs. The goal should always be code that is easy to understand and maintain.

8: Go 1.23 adds iterator functions and generic type aliases. How do you see those changing how we write Go, especially in libraries?

Mihalis Tsoukalos: The addition of iterator functions and generic type aliases in Go 1.23 might look like a quiet update, but it’s actually a significant step forward in writing more expressive, reusable, and composable code—particularly in libraries. These features build on the foundation of generics and help capture common programming patterns more naturally, while still keeping Go’s strengths of simplicity and clarity.

Take iterator functions. Go has always relied on for loops and range for iteration, and that worked well. But now, with iterator functions, we can encapsulate iteration logic as values—functions that yield elements one at a time. That might sound like a small shift, but it opens up powerful patterns like lazy evaluation, functional-style pipelines, and composable data flows. You’re no longer stuck rewriting the same loop boilerplate; you can abstract iteration into helpers that are both type-safe and ergonomic.

Then there are generic type aliases, which reduce friction when using generic types across packages. Before, if you wanted to tailor a generic type like map[K]V or Option[T] to your domain, you often had to rewrap or reimplement it. That made things verbose and diluted the usefulness of generic libraries. Now, with type aliases that support generics, you can define concise, strongly typed shortcuts for common patterns. This improves readability and makes code easier to work with, without introducing runtime overhead.

I think these features will lead to more expressive APIs and more composable, domain-agnostic utility packages. We’ll likely see libraries offering richer iterator utilities—things like filter, map, and reduce—implemented in a way that feels native to Go.

That said, the real challenge for library authors will be balance—using these tools to enhance code, not overcomplicate it. If done well, these features could significantly modernize the Go ecosystem, especially in areas like data processing and systems-level programming, where reusable containers, iterators, and higher-order utilities really shine.

9: Fuzzing is built into Go now. How have you seen teams make fuzz testing practical, and what are some tips to get value from fuzzing beyond just turning it on?

Mihalis Tsoukalos: Fuzz testing is a powerful technique for uncovering edge cases, subtle bugs, and even security issues—things that traditional unit tests often miss. Since Go 1.18 added fuzzing support directly into the go test tool, we’ve seen some teams begin experimenting with it. Again, it’s important to experiment first.

But as you said, just enabling fuzzing isn’t enough. To really benefit, teams need a focused, deliberate approach. The teams that get the most out of fuzz testing usually start by targeting critical code paths—places where the software processes complex or untrusted inputs. Think parsers, codecs, or deserialization logic. These are prime candidates because they’re hard to reason about and easy to break with unexpected input. And one important rule here: never trust user input. Writing fuzz tests for these areas helps surface bugs that could otherwise go unnoticed.

It’s also important to seed the fuzzer well, instead of letting it start with purely random inputs. Give it examples representative of real data—this helps the fuzzing engine explore the space more intelligently and find meaningful values faster.

Integration is key. The most effective teams make fuzz testing part of continuous integration. They run short fuzzing sessions locally during development for quick feedback, and then schedule longer runs overnight or during off-hours on CI servers. That way, fuzzing becomes a continuous part of testing, not just something you do once in a while.

Beyond just finding crashes, fuzz testing is excellent for hardening error handling. It ensures your code doesn’t panic, leak resources, or hang when it gets bad input. And when you combine fuzz tests with other tools like the race detector, you can catch data races that wouldn’t show up otherwise. That combination improves reliability across the board.

One more tip: keep your fuzz functions deterministic and free of side effects. Avoid calling external systems or relying on randomness inside the test itself. Deterministic behavior makes failures easier to reproduce and debug.

In short, fuzz testing is most valuable when used deliberately—targeting the right parts of your code, seeding it well, integrating it into workflows, and combining it with other tools. Done right, it’s not just about uncovering obscure crashes—it’s about building more robust, resilient Go systems.

10: Observability is another area you cover in your book. What do you recommend for monitoring and tracing Go systems effectively, especially under high concurrency?

Mihalis Tsoukalos: Observability is absolutely essential when running Go systems at scale, especially in high-concurrency environments. It gives you the visibility to understand how your application behaves in production, diagnose issues quickly, and keep performance and reliability where they need to be.

For monitoring, the first step is always metrics—both system-level and application-specific. We mentioned Prometheus earlier; it’s the go-to choice in the Go ecosystem, largely because of its flexibility and strong community support. The key is to instrument your code with meaningful metrics. Put simply: if you don’t collect the right metrics, you won’t solve your issues.

So collect things like request rates, error counts, latency percentiles, goroutine counts, and garbage collection pauses. These tell you how the system is behaving and where things might degrade under load. You also get a lot of value from the Go runtime metrics exposed through the runtime/metrics package. These provide insight into memory usage, garbage collection activity, and goroutine scheduling—crucial when dealing with thousands of concurrent operations.

Metrics give you an aggregated view, but tracing lets you zoom in. With distributed tracing—using something like OpenTelemetry—you can follow individual requests as they move through different parts of your system. That’s where you see latency accumulation, service interactions, or contention points. Under high concurrency, tracing is especially useful for catching queuing delays, lock contention, or slow dependencies—issues that metrics alone might mask.

One of the most important practices here is context propagation. We’ve already discussed the context.Context type. This is your mechanism for passing timeouts, cancellations, and tracing data across API boundaries and goroutines. If you don’t propagate context properly, you’ll miss spans or lose correlation in your traces. End-to-end consistency in instrumentation is critical, especially for workloads where a request might fan out into multiple goroutines.

Of course, high concurrency also means generating a lot of telemetry data, so you need to be smart about sampling and rate limiting. Adaptive sampling works well—prioritizing traces based on latency, errors, or unusual behavior. This way, you capture the most informative data without overwhelming your observability systems or introducing overhead.

And observability isn’t just about collecting data—it’s about acting on it. Instead of relying only on fixed thresholds, use anomaly detection and pattern-based alerts. Dashboards that track Go-specific behaviors—like spikes in goroutines or increased garbage collector pauses—make it easier to spot problems early and understand what’s really happening.

In short, effective observability in high-concurrency Go systems means combining detailed metrics, distributed tracing with proper context propagation, smart sampling, and ongoing analysis. With those in place, you’re in a much better position to detect issues early, debug complex behavior, and keep systems running smoothly at scale.

11: The standard library keeps expanding with utility packages and smarter routing in net/http. Do these reduce the need for external frameworks? What do you feel is still missing?

Mihalis Tsoukalos: The standard library of Go has always been one of its strongest features—clean, composable, well-tested, and rich. Over time, the maintainers have added to it in a very deliberate way. Things like smarter routing in net/http and new utility packages like slices, maps, and cmp have made it easier to build web services, command-line tools, and system-level software directly on top of the standard library.

Yes, these improvements are definitely reducing the need for external frameworks, especially for small to mid-sized applications. One of the best examples is net/http, which has steadily improved: better routing logic, smoother integration with middleware patterns, improved support for HTTP/2 and structured headers, and overall better ergonomics. For teams that prioritize simplicity, performance, and long-term maintainability, that’s a big win.

The new utility packages also help. Tasks like filtering, slicing, comparing maps, or writing type-safe logic can now be done concisely and idiomatically, reducing boilerplate and external dependencies.

That said, the standard library doesn’t replace third-party libraries entirely—especially when working on more complex systems or domain-specific problems. For example, I’ve written HTTP services in Go using Gorilla rather than plain net/http, and for building command-line tools I’ve used Cobra and Viper. The famous Docker tool has been written in Go using Cobra, and the Hugo static site generator also relies on Cobra and Viper. These are powerful tools for real-world utilities.

So, while the standard library is strong and keeps evolving, there are still gaps—particularly in areas like higher-level CLI frameworks or more sophisticated HTTP tooling. I expect the standard library will continue to improve, but tools like Cobra and Viper still fill important roles.

12: Even experienced Go developers make mistakes. What are some of the less obvious ones you still see when people work on performance-sensitive or concurrent systems?

Mihalis Tsoukalos: Everyone makes mistakes—that’s how we learn. The important part is being careful not to make them in production systems.

Even experienced Go developers can run into subtle issues when working on performance-sensitive or concurrent systems. A lot of this comes from Go’s simplicity. Goroutines are lightweight, channels are first-class, and the standard library gives you powerful tools. But that simplicity can hide complexity, and mistakes often come from relying too much on defaults or making assumptions about how the runtime behaves.

One common pitfall is spinning up goroutines without proper cancellation or lifecycle management. We’ve discussed before that using context.Context gives you control—allowing you to cancel goroutines properly and avoid memory leaks.

Another mistake is assuming channels are always the right concurrency primitive. When I first learned about channels, I thought they could solve every concurrency problem. But that’s not true. In some cases, a mutex or an atomic variable is more efficient and easier to work with. Think carefully before using channels.

Memory allocation is another big one. Developers often overlook how temporary allocations—like slices created in a tight loop, or boxing values into interfaces—can lead to heavy garbage collection overhead, which gets worse under high concurrency. Tools like Pprof or go test -bench -benchmem help you spot these patterns, but ideally, you should design with memory efficiency in mind from the start.

Another mistake is making false assumptions about how the scheduler works. Developers sometimes expect goroutines to be preempted fairly, but in CPU-bound loops without I/O or channel operations, goroutines might not yield control. This can lead to starvation or uneven workload distribution. Newer versions of Go have improved scheduling and preemption, but in rare cases you still need to explicitly yield with runtime.Gosched to let other goroutines run.

So overall, the issues I see are not usually about syntax—they’re about architecture. They come from assumptions about how Go handles concurrency and performance under the hood. The way to avoid them is by profiling continuously, testing under realistic loads, and building a solid mental model of how the Go runtime behaves at scale. In other words, learn the internals—don’t just assume.

13: You’ve worked very close to the metal for many years now. How would you compare Go and Rust for systems programming, especially in terms of performance, safety, and maintainability?

Mihalis Tsoukalos: This is a question I get often. Go and Rust take very different approaches to systems programming, and choosing between them depends on the specific priorities of your project.

Rust gives you fine-grained control over memory and concurrency with zero-cost abstractions that can deliver exceptional performance. Its ownership model and borrow checker eliminate entire classes of bugs at compile time—things like data races or use-after-free errors. That makes Rust a great choice for low-level systems where correctness and reliability are absolutely critical—think operating system components, device drivers, or performance-sensitive networking.

But that level of control comes with a steep learning curve. Rust’s mental model—ownership, lifetimes, trait bounds—can slow teams down, especially if they’re new to the language. Refactoring or prototyping requires great care to satisfy the compiler. Rust’s tooling (Cargo, Clippy, Rust Analyzer) is excellent, but the language demands precision. That pays off in safety and performance, but it can be a barrier in fast-moving or exploratory environments.

Go, by contrast, is all about simplicity and development speed. Its concurrency model with goroutines and channels is approachable and powerful. The garbage collector handles memory management, so you don’t need to think about it most of the time. Go may not match Rust in raw performance for compute-heavy workloads, but its performance is consistent and more than good enough for most system-level use cases.

That predictability, combined with readability and minimalism, makes Go practical for building high-throughput services, container tools, infrastructure automation, and other backend-heavy systems. It’s also easier to onboard new developers, and because Go code tends to look the same across teams, long-term maintainability is a real strength.

On safety, Go doesn’t give you compile-time guarantees like Rust. It won’t catch data races before you write code, but it does offer good tools: the race detector, a solid testing framework, and a culture that values clarity and explicitness. Go avoids complexity by design—no macro-heavy DSLs, no surprising inference—so the code stays understandable even as systems grow.

To sum up: Rust is the right tool when performance and safety are top priorities and you’re ready to invest in upfront complexity. Go shines when development speed, operational simplicity, and long-term maintainability matter more.

As an example, we once evaluated Rust for a packet inspection engine but chose Go due to faster development time and easier team onboarding.

In the past few months, I’ve also had the chance to explore Zig. It sits closer to Rust in terms of low-level control, but it’s much easier to learn. Zig has no garbage collector—you manage memory manually—but it’s far simpler than Rust. It may be a sweet spot between Go and Rust when you want to go lower without Rust’s complexity.

14: Looking ahead, what are you most excited about in Go’s evolution over the next few releases? Where do you see the ecosystem heading?

Mihalis Tsoukalos: What excites me most is how Go continues to evolve while staying true to its roots—pragmatic, simple, but increasingly powerful.

One area I’m watching closely is the ongoing evolution of generics. Since type parameters were introduced in Go 1.18, each release has built on that foundation, most recently with features like generic type aliases and iterator functions in Go 1.23. These aren’t flashy changes, but they’re meaningful. They enable more expressive and reusable code across the ecosystem—richer data structures, functional-style APIs, and cleaner abstractions in libraries. I look forward to seeing how the standard library and open-source projects embrace these tools to offer more composable, idiomatic patterns without losing Go’s clarity.

Performance tuning and runtime observability are also maturing quickly. Built-in fuzzing, profile-guided optimizations, and expanded runtime metrics are pushing Go beyond being just easy to use—it’s becoming easy to optimize too. For teams building high-performance systems, this is a big deal. I think profiling and performance tuning will become a routine part of development workflows, just like writing tests.

Concurrency is another area evolving. Go has always had a clean concurrency model, but with Go used increasingly in multicore, high-load environments—APIs, networking layers, real-time systems—there’s more attention on scheduler improvements, memory footprint reduction, and smarter resource usage. The recent fix to the goroutine loop variable capture bug is a good example: a small change, but it eliminates a long-standing issue and makes concurrent programming safer without adding complexity.

Beyond the language, the ecosystem is maturing fast. We’re seeing better libraries, stronger tooling for testing, static analysis, and cross-compilation, and an overall improved developer experience. Projects like TinyGo, Go Cloud, and Go’s growing presence in WebAssembly and embedded environments point to a future where Go isn’t just a server-side language—it’s part of a broader portable systems toolkit.

At the same time, community efforts around formal APIs, versioning best practices, and module proxy infrastructure show that Go is becoming more production-hardened and resilient.

So in short, I’m excited that Go is getting more powerful without becoming more complicated. That’s rare in programming languages. Go is investing in performance, safety, and tooling in a way that feels very Go-like: minimal, orthogonal, and deliberate. The future looks bright because Go isn’t chasing trends—it’s solving real problems with clarity and focus. I think we’ll see it used in even more places—cloud, systems, edge, maybe even mobile—while continuing to be a language teams can rely on for the long haul.

---

To explore the ideas discussed in this conversation—including concurrency design patterns, profiling techniques, and Go’s evolving support for generics and fuzzing—check out Mastering Go, Fourth Edition by Mihalis Tsoukalos, available from Packt. This 740-page comprehensive guide dives deep into advanced Go concepts such as RESTful servers, memory management, the garbage collector, TCP/IP, and observability.

Fully updated with coverage of Go generics, fuzz testing, Docker integration, and performance optimization, the book combines detailed explanations with real-world exercises. Readers build high-performance servers, develop robust command-line utilities, work with JSON and databases, and refine their understanding of Go’s internals. Each chapter is designed to strengthen both conceptual mastery and hands-on practice, from error handling and data types to concurrency, profiling, and advanced testing.

Whether you’re building network systems, optimizing cloud-native applications, or simply aiming to deepen your Go expertise, Mastering Go provides a practical foundation for writing professional, production-grade software.

Here is what some readers have said: