Lessons from Zig
A Smaller Standard Library
Abstract
The Zig programming language maintains an intentionally small standard library. Components that do not meet strict inclusion criteria are removed and relocated to community-maintained packages. This philosophy is enabled by a first-class package manager that makes third-party code trivially accessible.
C++ has no such escape valve. Every component added to the standard library creates a perpetual obligation: maintained by compiler vendors forever, analyzed for interactions by every future proposal, taught (or taught to avoid) by every educator. The cost to add is finite. The cost to keep is unbounded.
This paper argues that WG21 should adopt a philosophy similar to Zig’s regarding what belongs in the standard library. The argument is purely economic: the committee’s scarce resources should be allocated to components whose coordination benefits exceed their perpetual maintenance costs, and the bar for demonstrating this should be explicit, high, and consistently applied.
1. Zig’s Philosophy
1.1 Intentional Minimalism
The Zig language, created by Andrew Kelley, takes a deliberate position on standard library scope. The standard library focuses on low-level, fundamental utilities: memory allocators, data structures, string operations, and cross-platform OS abstractions. Domain-specific functionality is explicitly excluded.
Community discussions have crystallized this position:
In-memory operations belong. Allocators, queues, strings, and fundamental data structures serve virtually every program.
File format handling does not belong. Tar, zip, JPEG, and similar formats are considered too specialized. Each is “its own huge project” better served by dedicated libraries.
High-level frameworks do not belong. HTTP clients, for example, are considered inappropriate for a general-purpose systems language’s standard library.
1.2 Active Removal
Zig does not merely avoid adding components. It actively removes them. The std-lib-orphanage repository (archived November 2025) contains code relocated out of the standard library under an MIT license, allowing community maintenance. Examples include:
realpath()was removed because it is not portable, relies on a legacy permissions model, and “is typically a bug to call”A red-black tree implementation was relocated to community ownership
Filesystem APIs have been reorganized from
std.fstostd.Ioto better reflect their proper scope
This willingness to shrink the standard library is remarkable. In most language communities, additions are permanent. Zig treats the standard library as a curated collection that should contract when components fail to justify their maintenance burden.
1.3 The Package Manager Enables the Philosophy
Zig’s minimalism is viable because the language ships with a first-class package manager. Third-party dependencies are trivially accessible. When something leaves the standard library, users are not stranded. They add a dependency and continue working.
This is the critical enabler. A small standard library is punitive without easy access to alternatives. With a package manager, it becomes a virtue: the standard library stays focused, and the ecosystem absorbs the rest.
2. The Economic Case for a Smaller C++ Standard Library
2.1 Every Addition Creates Perpetual Costs
The economic structure of C++ standardization exhibits a fundamental asymmetry. A proposal author invests finite effort across a few years. Upon acceptance, that cost terminates.
The standard, however, must account for the addition in perpetuity:
Every subsequent proposal must analyze interactions with the new component
Every core language evolution (concepts, reflection, contracts) must consider its effects on existing library surface area
Every defect report in adjacent areas potentially implicates it
Every compiler vendor must implement and maintain it forever
Every ABI concern constrains future evolution permanently
Every educator must decide whether to teach it
Every new C++ programmer must learn it or learn to avoid it
The combinatorial complexity of the standard grows monotonically, and this complexity tax compounds across all future committee work, forever. The proposer pays once. Everyone else pays the rest.
2.2 The Externality Problem
This asymmetry creates a classic economic externality. Proposers capture the concentrated benefit of standardization (prestige, canonical status for their design) while the diffuse, perpetual maintenance cost is socialized across all future committee participants, most of whom had no voice in the original decision.
The rational incentive is to propose aggressively and defend additions uncritically, since the proposer bears almost none of the long-term cost they impose. Without mechanisms that force proposers to internalize perpetual costs, the standard library grows without bound.
2.3 Historical Evidence
The C++ standard library already contains cautionary examples:
std::regex: Shipped slow, cannot be fixed due to ABI constraints, and respected experts advise never using it for performance-critical codestd::any: A vocabulary type nobody needed; rarely used, sacrifices type safety, frequently cited as a standardization regretstd::auto_ptrandstd::rel_ops: Took over fifteen years from recognition of defects to removalstd::codecvtfacets: Deprecated, still maintainedstd::filesystem: Encoding assumptions frozen in 2003 that produce mojibake on Windows; vcpkg “completely ripped out use of std::filesystem”
Each seemed reasonable at proposal time. Each now imposes ongoing costs with minimal corresponding benefit. The committee lacks any formal mechanism to audit whether standardized features delivered their promised value.
3. Institutional Analysis
3.1 Complexity Accumulates, Knowledge Decays
Samo Burja’s Great Founder Theory observes that functional institutions are the exception, not the rule. Institutions decay over time as the living knowledge that created them—the understanding of why particular decisions were made—erodes through imperfect transmission. Each generation works from “photocopies of photocopies,” and without the generating principles, the tradition cannot recover what is lost.
This pattern applies directly to standard library components. The design rationale, the tradeoffs considered and rejected, the understanding of why particular API shapes were chosen—this knowledge lives in founders’ heads and dissipates when they disengage or pass away. Beman Dawes designed std::filesystem and shepherded it for fourteen years. When he died in 2020, the living tradition of knowledge behind its design went with him. The committee must now reverse-engineer intent from specification text.
Every component added to the standard creates another tradition of knowledge that must be preserved. A smaller standard library means fewer traditions to maintain, fewer succession crises, and less accumulated complexity for future committee members to navigate.
3.2 Bureaucratic Expansion Resists Contraction
GFT identifies a pattern in non-functional institutions: the body of the institution optimizes for appearance rather than function. In the context of WG21, this manifests as a bias toward adding components (visible, measurable progress) over the harder work of maintaining, improving, or removing existing ones.
No committee member builds a career on removing std::codecvt. Careers are built on proposals that add. This asymmetric incentive drives expansion regardless of whether expansion serves users.
Zig’s willingness to actively remove components from its standard library demonstrates a fundamentally different institutional posture: one that treats contraction as legitimate progress. This requires what GFT calls a “live player”—someone with the authority and vision to make decisions that bureaucratic processes resist.
4. What C++ Can Learn from Zig
4.1 Raise the Bar for Inclusion
Zig’s inclusion criteria are implicit but clear: a component belongs in the standard library only if it provides low-level, fundamental functionality that virtually every program needs. C++ should make this bar explicit.
A library component should be standardized only when it satisfies both:
Stability confidence: The design has converged over years of production use. No significant interface changes have been required. Known deficiencies have been addressed, not deferred.
Vocabulary necessity: Independent library ecosystems demonstrably require type agreement to interoperate. Evidence exists of coordination failures that standardization would resolve. Third-party distribution cannot address these failures.
“This would be useful” is necessary but insufficient. Useful libraries can thrive outside the standard. The question is: why does this usefulness require standardization rather than third-party distribution?
4.2 Invest in the Ecosystem Instead
Zig’s philosophy works because the package manager makes external libraries first-class citizens. C++ lacks this, which creates pressure to put everything in the standard. But the answer is not to capitulate to that pressure—it is to invest in the ecosystem.
The committee’s bandwidth is finite and precious. Every meeting hour spent on a niche library component is an hour not spent on:
Core language improvements that benefit everyone
Vocabulary types that resolve genuine coordination failures
Ecosystem infrastructure that makes external libraries more accessible
The opportunity cost of library expansion is paid in delayed progress on work that only the committee can do. External libraries can be maintained by anyone. Language evolution and vocabulary coordination require the committee.
4.3 Acknowledge That Removal Is Progress
The C++ standard has historically treated removal as nearly impossible. Deprecation takes a decade. Actual removal takes longer. This one-way ratchet guarantees unbounded growth.
Zig shows an alternative: when a component no longer justifies its place, relocate it. The code does not vanish. It moves to a different home where it can evolve without imposing costs on the core.
C++ cannot replicate Zig’s approach exactly—ABI stability and decades of deployed code make removal far more complex. But the committee can adopt the mindset: additions should be presumed temporary, not permanent. Every component should periodically justify its continued inclusion. If a facility has known defects that cannot be fixed, acknowledging this honestly serves users better than maintaining the pretense.
5. Addressing Counterarguments
5.1 “C++ Needs a Large Standard Library Because It Lacks a Package Manager”
This argument is circular. The standard library grows because the ecosystem lacks good dependency management. The ecosystem stagnates because everything important is expected to be in the standard. Breaking this cycle requires choosing a direction. Zig chose ecosystem investment. C++ should consider the same.
The alternative—continuing to expand the standard library as a substitute for ecosystem infrastructure—has predictable consequences. The standard becomes a repository of ABI-frozen designs reflecting assumptions of the era in which they were standardized. Performance-conscious organizations abandon std:: for internal alternatives. The standard library becomes precisely what it was never meant to be: used at API boundaries, avoided internally.
5.2 “The Standard Library Provides Guarantees That External Libraries Cannot”
The standard provides specification, not quality. std::regex is specified and slow. std::filesystem is specified and has encoding bugs. Specification guarantees portability of interface, not correctness of implementation or fitness for purpose.
External libraries can provide their own guarantees: test suites, benchmarks, deployment evidence, responsive maintenance. These are often more meaningful to users than an ISO document number.
5.3 “A Smaller Standard Library Would Hurt Beginners”
Beginners benefit from a coherent standard library more than a large one. A smaller library that works well is easier to teach than a large library with pitfalls that require expert knowledge to navigate. “Use std::regex but not for performance” and “use std::filesystem but beware encoding on Windows” are not beginner-friendly teachings.
6. Conclusion
The Zig programming language demonstrates that a small, focused standard library is not a limitation but a strength—when paired with ecosystem infrastructure that makes external libraries accessible.
C++ faces a different structural reality: no unified package manager, ABI stability constraints, and decades of deployed code. These constraints are real. But they do not change the underlying economics. Every addition to the standard library creates a perpetual obligation. Every obligation consumes finite committee bandwidth. Every hour spent maintaining regretted additions is an hour not spent on work that would benefit the entire C++ community.
The committee’s most valuable resource is its collective expertise and attention. A philosophy that guards this resource—that demands rigorous evidence before accepting perpetual obligations—serves the C++ community better than one that expands the standard library in the hope that breadth compensates for the absence of ecosystem infrastructure.
Zig asks: “Does this belong in the standard library, or can the ecosystem handle it?” C++ should ask the same question, with the same rigor, for every library proposal.
7. References
Kelley, Andrew. Introduction to the Zig Programming Language
Zig std-lib-orphanage. Archived November 2025.
Ziggit: Should the standard library be “batteries included”?. 2024.
Burja, Samo. Great Founder Theory. 2020.
[P3001R0] Muller, Jonathan; Laine, Zach; Lelbach, Bryce Adelstein; Sankel, David. “std::hive and containers like it are not a good fit for the standard library.” October 2023.
[P2028R0] Winters, Titus. “What is ABI, and What Should WG21 Do About It?” 2020.
[P1863R0] Winters, Titus. “ABI - Now or Never.” 2019.
[P0939R4] Dos Reis, Gabriel. “Direction for ISO C++.”
Jabot, Corentin. “A cake for your cherry: what should go in the C++ standard library?”
Winters, Titus. “What Should Go Into the C++ Standard Library.” Abseil Blog.
Revision History
R0 (2026-02-06): Initial draft examining Zig’s standard library philosophy and its applicability to WG21