This article is based on Zig 0.16. After five installments covering syntax, error handling, memory management, compile-time computation, and the build system — we’ve arrived at the finale. Time to tie it all together. Version 0.16 is a convergence point of two major changes: the Unmanaged migration of standard library containers, and the introduction of the new std.Io interface. These transformations deeply affect how Zig code is written. This article explores both, closes with three-language comparison cases, and provides a learning roadmap and resources.

The previous articles on OOM tracing all used C for eBPF kernel-space programs. This is natural — C is eBPF’s “native language,” with the verifier, CO-RE, and libbpf toolchain all designed around C. But if you’ve followed the eBPF ecosystem, you’ll notice a clear trend: more and more people are writing eBPF in languages other than C. Rust’s Aya framework is already used in production by the Solana validator and Kubernetes Gateway API; meanwhile, Zig is trying to bring a new development experience with comptime, explicit allocation, and first-class C interop.

This article is based on Zig 0.16. In the previous post, we covered Zig’s error handling and memory management — lightweight try/catch fault tolerance, and the explicit allocator-passing philosophy. Now we enter Zig’s most essential territory: structs and methods, and the soul of Zig — compile-time computation (comptime). If you come from Go, you’ll appreciate how Zig keeps things simple by defining methods directly inside the struct. If you come from Rust, you’ll see a different take on the impl block pattern. And comptime opens a path to “types as values” metaprogramming beyond Go generics and Rust traits.

This article is based on Zig 0.16. In the previous articles we covered Zig’s basic syntax and error handling. Now we arrive at the most distinctive part of Zig—memory management. If you come from Go or Rust, Zig’s memory philosophy will feel unfamiliar: it provides neither garbage collection nor an ownership system. Instead, it chooses a fundamentally different path—the Allocator Pattern. The core convention is remarkably simple, yet far-reaching: Any function that might allocate memory must accept a std.mem.Allocator parameter.

2014 SRCNN 三层卷积 · 3-layer CNN pioneered DL SR 2016 SRGAN 感知损失 + GAN visual quality leap 2018 ESRGAN RRDB + RaGAN richer features, no BN 2021 Real-ESRGAN 真实退化建模 · Real-world works on real photos 2021 SwinIR Transformer 注意力 global context modeling 2022 Diffusion 迭代去噪 · Iterative best quality, slowest From SRGAN to ESRGAN (2018) SRGAN (Super-Resolution GAN) introduced Generative Adversarial Networks (GANs) to super-resolution in 2016, achieving significant visual quality improvements over traditional PSNR-optimization methods through perceptual loss. However, SRGAN still had room for improvement. ESRGAN (Enhanced Super-Resolution GAN) by Wang et al. in 2018 optimized four key directions.

Continuous Profiling is a vital pillar of observability. Unlike traditional sampling profilers, continuous profiling captures application and kernel stack traces at a fixed frequency around the clock, generating flame graphs that help teams identify performance bottlenecks, memory leaks, and resource hotspots. This article focuses on the storage architecture of profiling data: starting from the Google pprof data model and flame graph construction algorithm, we analyze Pyroscope’s architectural evolution from V1 (TSDB+Parquet) to V2 (Metastore+Segments), Parca and FrostDB’s columnar storage innovation, commercial solutions from Datadog and Splunk, and conclude with comparative tables that highlight the differentiating choices across solutions.

This article is based on Zig 0.16. Three Error Handling Paradigms Error handling is one of the most debated topics in programming language design. Go’s multiple return values, Rust’s Result<T, E> enum, and Zig’s error union type represent three fundamentally different philosophies. This article assumes you have Go or Rust experience and uses that as a reference frame to understand Zig’s design. Go: Multi-return + if err != nil Go’s philosophy is “explicit over implicit” — functions can return multiple values, and the convention is that the last return value is error. Every call site must handle it:

This article is based on Zig 0.16. In Part 1 we discussed why Zig is worth learning and how to run your first Hello World. Now it’s time to dive into the syntax—variables, types, control flow, functions, and generics. The single goal is to make you able to read and write Zig code. If you have Go or Rust experience, none of these concepts will feel entirely new. I’ll draw comparisons at key points to help you map your existing knowledge.

Real User Monitoring (RUM) differs fundamentally from backend monitoring in its data model: RUM collects event streams with massive high-cardinality attributes — every user visit generates session_id, user_id, page_url, and hundreds of dimensions. Traditional TSDB label-set models degrade severely under this pattern. This article analyzes the time-series storage design of three mainstream RUM solutions: Sentry (open-source all-in-one), Datadog RUM (SaaS benchmark), and Grafana Faro (Grafana LGTM ecosystem extension). The common trend across all three is leveraging columnar OLAP instead of TSDB.

This article is based on Zig 0.16 (released 2026-04-13, the latest stable release). Zig is a rapidly evolving modern systems programming language. Its source repository has moved from GitHub to Codeberg, and the official download page is at ziglang.org/download/. Why Zig? If you already know Go and Rust, you might ask: why look at a third systems language? Zig sits between the two, attempting to combine C’s lightness, Rust’s modern toolchain, and Go’s low barrier to entry.