Deconstructing the Rust Discourse


Last updated on

Hodong Kim <hodong@nimfsoft.com>

Preface

This book analyzes both the technical characteristics of the Rust programming language and the specific technical and social discourses that have formed around it. Here, deconstruction does not mean rejecting a technology or claim in advance. It means separating technical facts, guarantees provided by a language, engineering costs, interpretations of causality, value judgments, and rhetorical expressions, and then examining the evidence and scope of application of each. The book considers, in historical and technical context, the designs Rust selected to achieve safety, performance, and concurrency, together with the costs and constraints those choices entail.

The discussion is organized around the following questions.

  1. What kinds of memory errors and data races does Safe Rust prevent, and how far do those guarantees extend in the presence of unsafe, foreign function interfaces (FFI), logical errors, and operational failures?
  2. What advantages and trade-offs do Rust’s ownership, borrowing, lifetimes, type system, and zero-cost abstractions present when compared with the approaches of C++, garbage-collected (GC)1 languages, Ada, and SPARK?
  3. To what extent do adoption cases and quantitative outcomes from companies and open-source projects demonstrate effects attributable to Rust itself, and how can those effects be distinguished from changes in architecture, algorithms, runtimes, hardware, and organizations?
  4. Under what conditions should refactoring, incremental modernization, selective replacement of risky components, and complete rewrites of existing systems be distinguished and combined?
  5. What logical leaps occur when conditional technical advantages are transformed into claims of universal superiority applicable to every system, or into judgments about developers’ intelligence or qualifications?
  6. What requirements and candidate set does the claim that a particular language is “the only alternative” presuppose, and what logical errors arise when those premises and the comparison process are omitted?

To answer these questions, the book gives priority to primary sources such as language specifications and standards, official project documentation, government reports, CVE records, original corporate engineering reports, and peer-reviewed research. When examining quantitative claims, it checks the studied population and sample, numerator and denominator, baseline, workload, hardware and software environment, and comparison period. It distinguishes observed results, statistical estimates, causal attribution, and the author’s interpretation, and applies as nearly as possible the same evidentiary standards to successful and unsuccessful cases. When evidence concerns only a particular organization or system, the book does not generalize beyond that scope and states uncertainties and alternative explanations.

The comparisons include C++, Java, C#, Go, Ada, and SPARK. Their purpose is not to rank one language as a simple replacement for another, but to examine which costs different languages and ecosystems choose among performance, memory control, developer productivity, verifiability, real-time behavior, tooling, and long-term maintainability. Ada and SPARK provide a comparison with another historical approach that has pursued safety and reliability without depending on a GC. The book also separates language characteristics from change strategies, evaluating refactoring, modernization, partial replacement, and rewriting as independent engineering tools rather than as a binary choice between preserving and discarding an existing system.

In this book, Rust discourse does not mean the official position of the Rust Foundation, the core development teams, or the community as a whole. Rust’s official channels have openly discussed and worked to improve challenges involving compilation time, asynchronous programming, tooling, safety boundaries, and other areas. The subject analyzed here is a set of recurring argumentative patterns observed in some public technical forums and social media. These online examples are used as qualitative material for analyzing the structure and discursive function of claims, not as a statistical sample proving how frequently those claims occur throughout the community.

Rust is a language that combines strong memory-safety guarantees without a GC with a high degree of control, and it has achieved important results in industry and open-source projects. This book was not written to diminish those achievements or to recommend a particular technical choice. Its purpose is to examine advantages and limitations, guarantees and costs, and observations and interpretations by the same standards. Its conclusions are therefore not final declarations but assessments based on currently available evidence, and they may be revised when better evidence or counterexamples appear.

Creative Commons License This work is licensed under a Creative Commons Attribution-NonCommercial-NoDerivatives 4.0 International License.

Table of Contents

Part 1: The Emergence of Rust and Its Technical Characteristics

Part 1 analyzes how the Rust programming language approached challenges in systems programming and the characteristics through which it has been discussed.

Chapter 1 examines the trade-off between performance and safety that formed the background to Rust’s creation and introduces major technical characteristics adopted in response, including the ownership model, the zero-cost abstraction (ZCA) philosophy, and the ecosystem represented by Cargo.

Chapter 2 analyzes the complex factors through which this technical foundation interacted with developer experience (DX), narrative, and institutional sponsorship to influence adoption.

1. Introduction to the Rust Language and Its Major Characteristics

Rather than merely listing Rust’s features, this chapter examines two questions about the boundary of memory-safety guarantees and the advantages and trade-offs of Rust’s design. First, what defects and costs did Rust seek to address in systems programming? Second, how far do the guarantees provided by ownership, borrowing, lifetimes, the type system, and zero-cost abstractions extend, and what trade-offs do they entail?

To do so, the chapter distinguishes the language’s design goals, specification-level guarantees, compiler and library implementations, and outcomes observed in actual workloads. It considers ownership and borrowing, zero-cost abstractions, types and pattern matching, and the Cargo ecosystem in turn, but does not expand a particular design goal into a universal result about the performance or safety of every program. Industrial adoption outcomes and change strategies are treated in later chapters under separate evidentiary standards.

1.1 Background: The Trade-off Between Performance and Safety

Systems programming may require hardware control, predictable resource management, throughput and latency, memory safety, and prevention of concurrency errors at the same time. Framing this simply as a binary choice between performance and safety, however, reduces the historical range of alternatives too far. C and C++ developed around low-level control and manual resource management; Ada and SPARK have combined strong typing and runtime checks with contracts and formal verification; and garbage-collected languages use automatic memory reclamation and managed runtimes. Which approach is appropriate depends on the defect model, real-time requirements, workload, operating environment, and verification requirements.

Rust began at Mozilla Research and developed into a systems programming language that pursues memory safety, concurrency, low-level control, and performance together.2 The description that it aims to provide memory safety without a GC and performance competitive with C++ is a design goal and value proposition. It is not a universal guarantee that every Rust program will match every C++ program, or that runtime costs and failures disappear. The following three objectives must therefore be read by distinguishing design goals, language guarantees, implementation properties, and observed outcomes.

Safety

Safe Rust prevents certain invalid memory accesses and data races through ownership, borrowing, and type rules. This guarantee rests on the assumption that the compiler and libraries, abstractions implemented with unsafe, and FFI boundaries fulfill their respective contracts.3 It does not automatically guarantee the absence of panic, deadlock, resource leaks or exhaustion, logical errors, every security vulnerability, or loss of service continuity. Sections 1.2 and 3.2 examine the exact guarantee boundary in detail.

Performance

Rust generates native code without a mandatory garbage collector and adopts the zero-cost abstraction principle of designing high-level abstractions not to require avoidable additional runtime overhead.4 This principle does not mean that every abstraction always runs at the same speed, or that compile time, binary size, memory use, debugging difficulty, and developer cognitive cost are zero. Actual performance must be measured with the workload, algorithm, optimization, allocation, I/O, library, and hardware conditions stated explicitly.

Concurrency

Safe Rust’s ownership and type system prevent data races, but they do not eliminate general race conditions, deadlock, starvation, priority inversion, or consistency problems in distributed systems.5 “Fearless concurrency” should therefore be understood as a bounded expression: certain memory-safety violations and data races are blocked at compile time, not that every concurrency defect is absent.

The important starting point for this chapter is the distinction between Rust’s pursuit of safety, performance, and concurrency within one design and the observed results in every environment. The following sections examine the concrete guarantees provided by ownership and borrowing, valid programs that the system rejects, runtime checks and implementation dependencies, and trade-offs with other designs.

1.2 Memory Management Through Ownership, Borrowing, and Lifetimes

This section treats ownership not as a slogan but as three distinct layers. Ownership identifies responsibility for cleaning up values and resources, borrowing constrains access permissions without transferring ownership, and lifetimes describe relationships that prevent references from being used longer than the values they point to. These layers are connected, but they are not the same concept.6

1. Ownership: Responsibility for cleaning up values and resources

In Rust, every value has an owner, and ownership may move through assignment or a function call. Reusing a moved value through its original variable is rejected at compile time. Values such as integers that implement Copy, however, are duplicated on assignment, so the original variable remains usable. The statement that “every assignment is a move” is therefore inaccurate.

When an owner leaves its valid scope, the value is cleaned up according to Drop. A type that owns a heap allocation may release that allocation at this point, and resources such as files, sockets, and locks may also be tied to a type’s destruction process. This rule is a basis for preventing errors such as double-free and use-after-free in Safe Rust, but it does not mean that destructors necessarily run on every termination path. Resources may not be reclaimed immediately after forced process termination or abort, intentional leaks, or reference-counting cycles.

2. Borrowing: Access permissions distinct from ownership

A reference does not own its target. A shared reference, &T, provides read access while it is valid, whereas a mutable reference, &mut T, expresses exclusive access during that period. This is often summarized as “many shared references or one mutable reference,” but the essential point is to prevent aliasing and mutation from occurring together while the references are actually in use.6

These rules prevent data races caused by unsynchronized concurrent reads and writes in Safe Rust. They do not, however, eliminate general race conditions whose result depends on execution order, deadlock, starvation, or priority inversion. Interior mutability based on UnsafeCell, raw pointers, and unsafe code also require separate invariants that a safe external interface must preserve.

3. Lifetimes: Relationships governing reference validity

A lifetime is not a runtime mechanism that directly controls when a value is destroyed. It is a static contract that expresses the validity relationships references must satisfy. A lifetime annotation does not make a reference live longer; it only describes relationships, such as the relationship between references accepted and returned by a function, so that the compiler can check them.6

The current borrow checker uses non-lexical lifetimes (NLL), considering the last use of a reference rather than merely the end of its enclosing block. Static analysis must nevertheless remain conservative because it cannot completely decide the meaning of every terminating program, and it rejects some programs that would be safe when executed. One reason the Rust project set stabilization of Polonius alpha as a 2026 goal is to accept more valid patterns that the current analysis cannot express, including conditional borrowing and lending iterators.7

4. Preconditions and boundaries of Safe Rust’s guarantees

The central guarantee of Safe Rust is the soundness property that safe code alone cannot cause undefined behavior. This guarantee, however, rests on the compiler, standard and third-party libraries, allocators, abstractions implemented with unsafe, operating-system interfaces, and FFI code each honoring their contracts. unsafe is not a marker that permits undefined behavior; it indicates that the implementer must verify obligations the compiler cannot check.3

Ownership and borrowing therefore block important classes of dangling references, invalid aliasing, double-free errors, and data races, but they do not eliminate out-of-memory conditions, resource exhaustion, panic, abort, logical errors, deadlock, violations of external contracts, or compiler defects. If C code at an FFI boundary causes undefined behavior, its effects may extend to the entire program, including its Rust components.

5. Ownership patterns outside the basic rules and their costs

Real-world data structures may be difficult to express using only single ownership and static borrowing. Rust therefore provides types that change the point at which checks occur or the synchronization mechanism used while preserving a safe abstraction.8

  • Rc<T> represents multiple owners within one thread, but requires a heap allocation and reference-count increments and decrements; cycles of strong references can leak memory.
  • RefCell<T> provides interior mutability and checks borrowing rules at runtime rather than compile time. Violating those rules causes a panic instead of undefined behavior, but adds state-tracking and branch costs.
  • Arc<T> uses atomic reference counting for sharing across threads. Those atomic operations can make it less favorable than Rc<T> when thread safety is unnecessary.
  • Mutex<T> grants mutable access to its inner value only to code that has acquired the lock. Types and RAII structure lock release, but lock-acquisition and contention costs and the possibility of deadlock remain.

These types do not remove the ownership rules. They encapsulate patterns that are difficult to express through static checking behind safe APIs, while choosing runtime checks, heap allocation, reference counting, atomic operations, and locking as costs and introducing new failure conditions.

Interim conclusion

At the boundary of memory-safety guarantees, ownership, borrowing, and lifetimes strongly block particular dangling references, double-free and use-after-free errors, invalid aliasing, and data races within a sound Safe Rust boundary. The guarantee nevertheless depends on the contracts of unsafe implementations and external boundaries and does not cover every bug or operational failure.

In terms of design advantages and costs, this design provides strong static guarantees without a runtime garbage collector, but requires ownership relationships to be exposed through types and interfaces and may reject some valid programs. When shared ownership or interior mutability is chosen, static costs do not disappear; they move into reference counting, runtime checks, atomic operations, and locking. Rust’s memory-management model is therefore better understood not as “cost-free safety,” but as a design that blocks particular errors statically and, when necessary, makes alternative costs explicit through types.

1.3 The Lineage of Zero-Cost Abstractions

Zero-cost abstraction is not a factual claim that every cost in a program is zero, but a principle for designing languages and libraries. It means that unused features should impose no time or space cost, and that abstractions which are used should be designed to compete with reasonable hand-written low-level implementations. The principle was formulated systematically as C++’s zero-overhead principle, and Rust adopted it as one design axis in pursuing memory safety together with low-level control.9

Features such as C’s struct, macros, inline, and sizeof influenced this history by participating in compilation or providing low-level control. Calling every compile-time technique an early form of zero-cost abstraction, however, makes the concept too broad. This section distinguishes low-level implementation techniques, a language-level abstraction principle, and observed output produced by a particular compiler.

1. Static dispatch and monomorphization

Generic functions that are used and traits that are dispatched statically are monomorphized for concrete types. This approach determines the call target at compile time and creates opportunities for direct calls, inlining, and related optimizations. Because the optimizer can see concrete types and operations together, an abstraction boundary may disappear from the final machine code.9

Monomorphization does not, however, guarantee that the same machine code is always generated or that the result is always faster than hand-written code. Generated output may vary with the rustc and LLVM versions, optimization level, crate boundaries, LTO, code-generation units, target CPU and enabled features, and surrounding code. The same source may therefore produce very different optimization results in development and release builds.10

2. Dynamic dispatch, allocation, and runtime checks

Not every Rust abstraction is eliminated statically. A dyn Trait value uses a data pointer and a virtual method table (vtable) to select the call target at runtime. This entails an indirect-call cost and generally reduces opportunities for inlining, while potentially reducing code size by avoiding a separate copy of code for every concrete type.11

Dynamic dispatch and heap allocation are not the same concept. An &dyn Trait can borrow an existing value and does not itself require a heap allocation, whereas Box<dyn Trait> chooses a heap-owning representation based on Box. Allocation and reallocation by Vec and String, and heap ownership through Box, are behaviors of the selected data structures and do not disappear merely because they are called abstractions. Safe indexing of arrays and slices also has the semantic behavior of panicking when the index is out of bounds; whether a bounds check is removed is an optimization outcome, not a universal language guarantee.11

3. Costs that may arise when runtime overhead is reduced

Because monomorphization generates machine code for concrete types, it can benefit execution performance and inlining, but it can also increase compile time and binary size. Larger code may create additional instruction-cache pressure, although the actual effect depends on call frequency, code placement, the target processor, and the workload. Dynamic dispatch, conversely, leaves an indirect call but can reduce code duplication.10

Build settings also involve trade-offs. Higher optimization levels and LTO can expose more optimization opportunities but increase compilation and linking time, and optimized code can be harder to debug because source order and execution state may be rearranged. Increasing the number of code-generation units can speed parallel compilation while reducing generated-code performance. Maintainability must likewise account for both the code duplication removed by abstractions and the complexity of generic APIs, diagnostics, and build tracing. Compile time, binary size, instruction-cache behavior, debugging, and maintenance are therefore separate evaluation dimensions from runtime throughput.10

4. Scope of the iterator example

// Sum the squares of numbers divisible by 3 from 1 through 99.
let sum = (1..100).filter(|&x| x % 3 == 0).map(|x| x * x).sum::<u32>();

This code combines filter, map, and sum to express the computation declaratively. In an optimized build, adapter calls may be inlined and intermediate state removed, producing code similar to a single loop. This example alone, however, cannot establish that every iterator chain has the same performance or machine code as a hand-written loop. The comparison in the official Rust book is likewise an observation that loops and iterators produced similar results for one search workload, not a comprehensive proof of equivalence across diverse inputs and conditions.12

5. Conditions for comparing performance claims

A performance comparison concerning zero-cost abstractions should state at least the following conditions.

  • versions of rustc, Cargo, and major crates;
  • the target triple, CPU, enabled instruction-set features, and operating system;
  • development, release, or custom profiles, including optimization level, LTO, code-generation units, and panic strategy;
  • input data, workload, iteration count, warm-up procedure, and measurement method;
  • algorithm, allocation, and I/O conditions of the comparison baseline, such as a loop or another implementation; and
  • compile time, binary size, and memory use as well as latency and throughput.

When these conditions differ, the same syntactic abstraction can produce different results. An advantage observed in one benchmark must therefore not be generalized into a fixed property of an entire language or of every abstraction.

Interim conclusion

In terms of design advantages and costs, static dispatch and monomorphization are strong mechanisms for lowering high-level interfaces into concrete code that permits direct calls and optimization. The zero-cost abstraction principle is not, however, a specification-level guarantee that every abstraction produces identical machine code or performance. Dynamic dispatch, heap allocation, bounds checks, and library runtime behavior remain according to the selected representation and data structure.

Rust is better understood as a design that lets developers choose where and which costs to pay, rather than one that removes costs. Avoiding runtime indirection may introduce the compile-time and code-size costs of monomorphization, while reducing code duplication may select the cost of dynamic dispatch. Zero-cost abstraction should therefore be evaluated through concrete workloads, build conditions, generated code, and total lifecycle cost rather than through a slogan.

1.4 Securing Safety Through the Type System and Pattern Matching

Rust’s static type system constrains how values are represented and which operations are permitted on them. Program states can be recorded in types, and operations inconsistent with those types can be rejected at compile time. What the type checker guarantees, however, is the conditions represented in the types. It does not mean that business rules, the external environment, and all execution results are automatically correct.

1. Option and Result: the scope of explicit state modeling

Rust enumerations are sum types whose variants can contain different data. Option<T> represents the presence or absence of a value as Some(T) or None, while Result<T, E> represents success and failure as Ok(T) or Err(E). When an API uses these types, callers can see in the type that absence or failure is possible and can propagate or branch on those paths.13

This advantage should not be expanded into the universal claim that “Rust has no nulls or exceptions.” Safe references &T and &mut T, and Box<T>, assume non-null pointers to valid values, but raw pointers may be null, and FFI and operating-system interfaces may convey null pointers, error codes, and foreign exceptions. Option does not automatically sanitize such boundaries; it is a way to express a validated possibility of absence inside Rust’s type system.13

Unused Result values are covered by #[must_use], but this is a lint by default. Its level can be lowered, or a value can be discarded explicitly with let _ =, so the compiler does not force a meaningful recovery policy for every error. The ? operator generally propagates an error to the current function’s caller rather than handling it. Whether to log, retry, substitute a value, or terminate remains an API and application-design decision.13

2. What pattern matching and exhaustiveness checking guarantee

A match checks whether its arms collectively cover all values that can currently be constructed for the subject type. Removing the None arm from the following code makes it fail to compile.

fn describe(value: Option<i32>) -> &'static str {
    match value {
        Some(number) if number > 0 => "positive",
        Some(_) => "zero or negative",
        None => "no value",
    }
}

This guarantee also has boundaries.14

  • A wildcard arm _ covers all remaining values and therefore passes exhaustiveness checking, but it does not reveal which variants were handled intentionally. A newly added API variant may be absorbed silently by an existing wildcard.
  • A pattern guard may evaluate to false, so it is not evidence that every value matching the pattern is handled. That is why the example needs another Some arm after Some(number) if number > 0.
  • if let, let ... else, while let, and matches! are tools for focusing on selected patterns and do not require every case to be handled.
  • A #[non_exhaustive] enumeration from another crate requires a wildcard arm to allow future variants. This facilitates API evolution, but reduces the caller’s ability to detect a new state as a compilation failure by enumerating every current variant.

Exhaustiveness checking therefore guarantees that no case is omitted with respect to the current type definition and written patterns. It does not prove that the behavior of each arm is correct, that a wildcard handles new states appropriately, or that external state agrees with the type definition.

3. Invalid states are blocked only when invariants are represented in types

Enumerations, newtypes, private fields, and validated constructors can make particular invalid states difficult to represent. A range-checked identifier or a state transition can, for example, be modeled as a distinct type so that code using the safe public API cannot bypass validation.

Relations such as a start time preceding an end time, consistency among several fields, the actual existence of a file, an authorization policy, or the trustworthiness of a network response do not arise from a type name alone. Those conditions must be implemented as constructor and method invariants, while field visibility and conversion paths are controlled. A value may be structurally well typed and still be wrong in its business meaning.

This boundary is especially important at unsafe, FFI, deserialization, and external-input boundaries. Treating an invalid enum discriminant or an invalid reference as a Rust value can cause undefined behavior. External bytes, C structures, database rows, and network messages must have their lengths, ranges, encodings, discriminants, and inter-field relations validated before being treated as Rust types. Type-system guarantees begin after a valid typed value has been constructed; they do not replace the responsibility for establishing that premise at the boundary.15

4. Runtime failure and control-flow costs

Representing failure as an Option or Result value does not remove runtime failure. unwrap and expect panic on the unexpected variant and, according to the build’s panic strategy, may unwind the stack or abort the process. unwrap_unchecked removes the check, but invokes undefined behavior when used on the wrong variant.16

Code that branches on state creates real control flow. A compiler may lower a simple match into conditional branches, a jump table, conditional moves, or branch-free code, but the concrete result depends on the number of variants, data layout, optimization level, target CPU, and surrounding code. Pattern matching and combinators are not guaranteed to be cost free. Hot paths may require measurement of branch prediction and error-value construction, while storing a large error variant directly in an enum or indirectly through Box is a trade-off between representation size and allocation cost.

5. Representation, API evolution, and maintenance costs

For a default repr(Rust) enum, exact field order, discriminant placement, and total size are generally not a stable ABI. Particular types for which the official documentation guarantees null-pointer optimization, such as Option<&T>, are exceptions; an optimization for one case cannot be generalized to every Option<T>, Result<T, E>, or user-defined enum. Depending on layout in an FFI or storage format requires an appropriate repr and a separate compatibility design.16

Dividing states precisely into types can turn omissions into compilation failures and clarify code-review and testing targets. As variants and error types multiply, however, match arms, conversion code, documentation, and tests also grow, while generic error hierarchies and long combinator chains can complicate debugging. Adding a variant to a public enum can break exhaustive matches in downstream code; #[non_exhaustive] and wildcards improve compatibility but reduce automatic discovery of new states. Type precision, API stability, diagnostic clarity, and maintenance cost must be designed together.

Interim conclusion

Looking beyond memory-safety boundaries, Option, Result, and exhaustive pattern matching block important omissions at compile time when absence, failure, and state branches are represented in types. They do not eliminate null raw pointers and FFI inputs, panics, ignored errors, new variants absorbed by wildcards, incorrect business rules, or invalid external input. The range of invalid states that are blocked depends on how accurately invariants are represented in types and safe APIs and preserved at every boundary.

In terms of design advantages and costs, refining states into types is a strong mechanism for moving implicit runtime failure into explicit interfaces and compiler diagnostics. It may also impose costs in API design, branching and representation size, error conversion, compatibility, debugging, and maintenance. The value of the type system and pattern matching therefore lies not in “eliminating every error,” but in making explicit which error states are represented and at which boundaries they are validated.

1.5 Ecosystem: Cargo and Crates.io

The experience of using a programming language is determined not only by its syntax and type system. The tools and ecosystem used to create projects, select dependencies, build, test, deploy, and update them over long periods also affect development cost and the possibility of failure. In Rust, Cargo is the official package manager and build tool, and crates.io is the default public package registry. This section analyzes them as a tooling and ecosystem layer distinct from language-level safety guarantees.

1. The workflow standardized by Cargo and its scope

Cargo uses Cargo.toml to declare package metadata and dependencies and provides common entry points such as cargo new, cargo build, cargo check, cargo test, cargo doc, cargo package, and cargo publish. Instead of combining direct rustc invocations with project-specific shell commands, one tool coordinates dependency downloads and compilation order, conventional directory structure, and build profiles. This can reduce differences among development environments and make common automation, CI, and documentation practices easier to establish.17

However, a common workflow, program properties guaranteed by the language, and a reproducible build that produces the same artifact in every environment are different concepts. Even when Cargo selects the same dependency versions, the final result can be affected by the versions of rustc and Cargo, the target triple, build profiles and flags, environment variables, build scripts, procedural macros, native libraries, and external tools. The existence of a common cargo build command therefore cannot by itself guarantee memory safety, functional correctness, or bit-for-bit reproducibility.

2. Dependency resolution, Cargo.lock, feature unification, SemVer, and MSRV

Cargo’s resolver computes a dependency graph that satisfies the version requirements declared by each package and, when a lockfile is used, records the result in Cargo.lock. When a lockfile exists, Cargo prefers the recorded versions, making dependency selection more stable. --locked turns a need to change the lockfile into an error, and --frozen combines that with offline operation. --offline, however, can use only packages already available locally and may therefore produce a dependency resolution different from an online run. A lockfile thus greatly improves determinism in dependency selection, but it does not freeze the network and cache state or the entire build environment.18

The effect of the lockfile also depends on the role of the package. For a final application, it is useful for pinning a dependency set that has been tested. When a library is consumed by another project, however, dependency resolution is performed again using the consumer’s Cargo.toml and the complete graph. Cargo’s official FAQ likewise warns that a library’s Cargo.lock does not control the dependency selection of its consumers.18

The resolver reuses the same package version where possible, but incompatible version requirements can place multiple versions of the same crate in one graph. This can increase duplicate compilation and code size, and types with the same name defined by different versions may be incompatible at runtime type-identification or public API boundaries. cargo tree -d can be used to find such duplicate versions.18

Features are not merely independent switches either. When several packages share one dependency, the union of the activated features is the default principle. Resolver version 2 reduces unnecessary feature unification in some cases involving target-specific dependencies, build dependencies and procedural macros, and development dependencies. The actual compilation graph and its cost can therefore change depending on which workspace members are built together and which targets and features are selected.18

Cargo selects versions under an assumption of SemVer compatibility, but the official compatibility guidelines themselves state that they are not rules every project is forced to obey. Changes that are syntactically compatible can also affect runtime behavior. rust-version can express a package’s minimum supported Rust version (MSRV) and allow the resolver to take it into account, but it is optional metadata and can be bypassed with --ignore-rust-version. SemVer and MSRV are therefore contracts and tools for managing update risk, not proofs that a new version is always compatible or free of regressions.18

3. Code executed during the build and native and target dependencies

Cargo dependencies do not necessarily end with passing Rust source files to rustc. A package’s build.rs runs immediately before that package is built and can compile C libraries, locate system libraries, generate source code, or perform platform-specific configuration. The Cargo documentation explains that a build script can perform arbitrary work while it runs.19

Procedural macros are also executed as actual code at compile time. According to the Rust Reference, procedural macros can use resources available to the compiler, including file access, and carry the same kinds of security concerns as Cargo build scripts. Build scripts and procedural macros from an untrusted dependency should therefore be treated as a build-time code-execution boundary. The memory-safety guarantees of application code written in safe Rust syntax and the trust placed in third-party code executed during the build are not properties of the same layer.19

Native dependencies introduce separate environmental premises. Build scripts can use links metadata and linker directives to connect to C or C++ libraries, and target-specific dependencies can vary by operating system and architecture. In cross-compilation, build dependencies execute on the host while the final crate may be compiled for a different target. Even with the same Cargo.lock, different host tools, linkers, system libraries, or target SDKs can therefore change the build result or whether the build succeeds.19

Long-term preservation or high-assurance builds consequently require recording and controlling not only the lockfile but also toolchain versions, targets, profiles and flags, native tools and libraries, required environment variables, and the execution conditions of build-time code.

4. The integrity and distribution functions provided by crates.io and the boundary of supply-chain guarantees

crates.io is Cargo’s default public registry and provides a common path for package discovery and distribution. The registry index records the SHA-256 checksum of each published .crate file, and Cargo verifies that downloaded data matches that checksum. This is an important integrity mechanism for confirming that the selected package bytes received through transfer or cache match the registry metadata.20

The management of published versions also considers stability. crates.io aims to retain published versions permanently; a problematic version can be yanked rather than deleted. A yanked version is normally excluded from new dependency resolution, but it can continue to be used when it is already recorded in an existing Cargo.lock. Owners can manage permission to publish new versions and yank existing ones, and publication metadata requires either a license expression or a license file, with standard licenses representable using SPDX expressions.20

These functions should not be expanded into a guarantee of the entire supply chain. A checksum verifies the identity of the package bytes recorded by the registry; it does not prove that the code was safely designed, how it corresponds to a particular commit in a public repository or review process, or whether its maintainers will provide long-term maintenance. The presence of license metadata also does not establish that the licenses of the entire transitive dependency graph satisfy a project’s policies and legal requirements. Yanking likewise does not automatically remove or repair a version already present in a lockfile.

The accessibility and centralized distribution path of crates.io, package checksums, ownership, and yanking are therefore useful features, but discoverability, distribution integrity, and permission management are different evaluation criteria from provenance verification, security, maintenance quality, and long-term support.

5. Lifecycle costs of networks, caches, vendoring, auditing, and updates

Cargo downloads registry and Git dependencies and caches them under locations such as $CARGO_HOME. The cache reduces network and processing cost for repeated builds, but a new environment or an empty cache requires network access and downloads again. Dependencies can be prefetched with cargo fetch, and --offline or --frozen can then be used; cargo vendor can copy the source of crates.io and Git dependencies into a local directory managed by the project. Vendoring, however, does not eliminate external dependencies. It is a choice that moves responsibility for retention, synchronization, and updates into the project.21

As a dependency graph grows, the amount of data to download and cache, compilation work, duplicate versions and enabled features, the execution surface of build scripts and procedural macros, and the number of licenses, vulnerabilities, and maintenance states to review can all grow as well. Cargo’s documentation also recommends considering compile-time, licensing, and maintenance effects when adding build dependencies. In cross-builds where host and target differ, the same dependency can be compiled again for different roles.19

cargo update intentionally changes the versions selected in the lockfile. Updating is therefore not merely a matter of obtaining a newer version number; it is maintenance work that should consider change logs, tests, SemVer assumptions, MSRV, security advisories, and rollback capability together. RustSec’s cargo audit compares Cargo.lock against a database of known security advisories, but it does not prove the absence of unreported vulnerabilities or design defects. Automated auditing can assist supply-chain review; it does not guarantee that review is no longer necessary.21

The comparison with C and C++ ecosystems should use symmetric criteria as well. It is inaccurate to say that “C/C++ has no package managers or standardized build practices.” Build systems such as CMake and Meson, C/C++ package managers such as vcpkg and Conan, and operating-system package managers are available. The distinction is less about whether tools exist than about Rust placing Cargo and crates.io at the center of its official workflow and providing a strong common default path from project creation through dependency resolution, build, testing, and publishing. Conversely, the greater diversity of C/C++ tools can increase integration cost, but it can also provide choices that fit existing build systems, system packages, binary packaging, and organization-specific repository policies.21

Interim conclusion

Cargo and crates.io are important engineering advantages of Rust. A common manifest and command system, dependency resolver and lockfile, and a default registry with checksums make project configuration and dependency selection more explicit and easier to automate. In particular, managing a verified Cargo.lock together with fixed build conditions makes it easier to reuse the same dependency set across time and development environments.

These advantages, however, are not the same as language-level safety guarantees. A lockfile does not freeze the entire build environment or the trustworthiness of third-party code; a checksum does not review code quality; and SemVer, MSRV, yanking, and security advisories do not make maintenance decisions on the project’s behalf. The convenience of composing small dependencies can also bring costs in transitive dependencies, build-time code execution, network and cache use, compile time, license and vulnerability auditing, updates, and long-term support.

For large-scale, long-lived, or high-assurance environments, the quality of the tooling should therefore not be judged solely from the facts that “Cargo is used” or that “the crates.io ecosystem is large.” The actual transitive dependency graph, enabled features and targets, build scripts and procedural macros, native dependencies, offline recovery and vendoring strategy, and auditing, update, and rollback procedures should be evaluated together. Cargo provides a strong foundation for performing this work consistently, but it does not remove supply-chain and lifecycle responsibility.

1.6 Conclusion: Guarantee Boundaries and Design Costs

The first question of this chapter was what defects and costs Rust sought to reduce in systems programming. The core finding of the preceding analysis is that Safe Rust, through ownership, borrowing, and type rules, strongly blocks important classes of dangling references, use-after-free, double free, invalid aliasing, and data races at compile time, while Option, Result, and exhaustive pattern matching can move absence, failure, and state branching into explicit types and control flow. Cargo and crates.io also provide tooling advantages by organizing project configuration, dependency resolution, building, testing, and publishing into a common workflow. The properties and guarantees of these three layers, however, are not the same.

The second question was how far these designs guarantee their intended properties and what trade-offs they entail. Safe Rust’s memory-safety guarantee depends on the compiler and libraries, abstractions implemented with unsafe, and FFI boundaries each upholding their contracts; it does not guarantee the absence of panic, general race conditions, deadlocks, memory or resource leaks and exhaustion, or logic errors, nor does it guarantee service continuity. Making states explicit in types likewise blocks the relevant classes of errors only when invariants are actually represented in types and safe APIs and their premises are validated at boundaries such as external input and FFI. Finer-grained state modeling also brings costs in API evolution and compatibility, error conversion, debugging, and maintenance. Memory safety and type-level guarantees should therefore not be equated with system-wide correctness, availability, or reliability.

On performance, zero-cost abstraction is likewise a design principle for reducing avoidable runtime overhead, not a universal speed guarantee. Static dispatch and monomorphization can reduce runtime call costs and create optimization opportunities, but they can increase compile time, code size, and debugging cost; dynamic dispatch, heap allocation, bounds checks, and library runtime behavior can remain depending on the representation chosen. Evaluation should therefore cover not only throughput and latency but also compile time, binary size, memory use, debugging, and maintenance costs under the actual workload and build conditions.

The same boundary applies to tooling and the ecosystem. Cargo’s common workflow, Cargo.lock, and crates.io checksums and distribution features structure dependency selection and automation, but they do not guarantee reproducibility of the entire build environment or the quality, security, and long-term maintenance of third-party code. Large-scale and long-lived environments must also manage toolchain pinning and upgrades, build scripts and procedural macros, native dependencies, networks and caches and offline recovery, supply-chain, license, and vulnerability audits, updates and rollback, and integration and migration costs with existing code and build systems. Because C and C++ also have real build and package-management tools, the relevant comparison is not whether tools exist but the trade-off between the integration of a common default path and the breadth of choices that can fit existing assets.

Rust can therefore be a strong option where a runtime GC is difficult or undesirable, low-level control is required, and it is important to block some errors involving memory lifetimes, aliasing, and missing states as early as possible. Conversely, the trade-offs change where shared ownership, runtime checks, and synchronization are frequently needed to accommodate valid patterns rejected by static rules, or where compile time, code size, FFI, native dependencies, existing tooling, and migration costs dominate. This means neither that other approaches are always better nor that Rust is always better.

The Chapter 1 conclusion is that Rust’s core value lies less in eliminating costs than in controlling certain errors more strongly at compile time and through explicit types and interfaces, while shifting where some costs and responsibilities are borne. Its benefits and costs can be assessed accurately only by separating language guarantees, implementation and runtime behavior, tooling and ecosystem convenience, and observed project outcomes. The next chapter treats how much these conditional technical advantages and tooling characteristics actually contribute to adoption decisions as a separate empirical and causal question.

2. Factors in Rust Adoption: Interaction Among Technology, Ecosystem, and Narrative

An observation that a language is actually used must be distinguished from a causal explanation of why it was adopted. The fact that a particular organization or project used Rust shows that adoption was possible under those conditions, but it does not mean that the language itself was the sole cause of the decision or that the same effect would recur in other organizations. In this book, “adoption” can also refer to different scopes such as experimental use, introduction into new components, partial replacement of an existing system, or organization-wide standardization, so no source is generalized beyond the level it actually demonstrates.

This chapter examines explanations proposed for Rust adoption by separating technical fit, developer experience and tooling, institutional and ecosystem conditions, and narrative and public perception. These factors may influence one another, but the presence of one does not prove the effect of another or the cause of adoption as a whole. Technical advantages, tooling convenience, institutional sponsorship, and discourse effects are therefore treated as separate evidentiary questions.

2.1 Technical Background: Memory-Safety and Performance Goals

A claim often presented in technical explanations of Rust adoption is that Rust provides a new option for systems software by aiming to strengthen memory safety without a runtime garbage collector (GC) while combining low-level control with high execution performance. Official Rust documentation explains that ownership rules are checked by the compiler and that this model is designed to provide memory-safety guarantees without a GC within the scope of Safe Rust. Borrowing rules contribute to preventing data races at compile time by restricting simultaneously existing mutable references, and the Rust Reference classifies data races, access through pointers whose lifetime has ended or that are improperly aligned, and the creation of invalid typed values as undefined behavior.22

Here, design goals must be distinguished from observed performance outcomes. The fact that ownership rules do not themselves require a separate runtime GC does not guarantee that every Rust program is faster than or as fast as a C or C++ program. As Section 1.3 discussed, actual performance depends on algorithms, allocation, bounds checks, dispatch, library and compiler implementations, target hardware, and workload.

Describing modern C++ in particular simply as a “manual-memory-management language without safety mechanisms” is inaccurate. It has language and library practices for managing resources and lifetimes more safely, including RAII, smart pointers, containers, and span, and the C++ Core Guidelines recommend avoiding raw owning pointers and direct new/delete in favor of resource handles. The location of the guarantee differs, however, from Safe Rust, where the compiler checks ownership and borrowing rules by default.23

GC-based languages as a whole should not be generalized as if they shared a single performance characteristic. For example, Oracle’s HotSpot GC documentation distinguishes throughput and latency as major garbage-collection performance metrics and explains that trade-offs among pause time, throughput, and memory usage vary by collector and configuration. It is therefore too broad to generalize that “GC is unsuitable for systems software because it has pauses.” Actual suitability varies with the collector and runtime, heap size and live objects, workload, latency requirements, memory constraints, and target environment.24

Rust’s technical distinction in this comparison is not the proposition that it is automatically faster because it has no GC, but the design choice to statically check a substantial portion of memory-lifetime and aliasing relationships through ownership and borrowing rules while strengthening memory safety without a separate runtime GC. Where a runtime collector is difficult or undesirable, or where low-level control and explicit resource-lifetime management matter, this can be a strong reason for adoption. Conversely, Safe Rust does not eliminate all logic errors, general race conditions, memory leaks, or resource exhaustion, and additional soundness obligations remain at boundaries involving unsafe and FFI.22

Interim conclusion

Rust’s design, which considers memory safety together with runtime cost, can provide a meaningful technical fit for particular systems software. How much that fit actually contributes to an adoption decision, however, is a separate empirical question. Without organizational decision records, surveys, migration reports, and comparative evidence, the existence of a technical advantage alone cannot establish either a sole cause of adoption or an average effect. This section therefore identifies the technical reasons and applicability conditions under which Rust may be adopted; conclusions about the overall causes of adoption are considered together with the tooling, ecosystem, and narrative analyses that follow.

2.2 Developer Experience (DX): Cargo and the Toolchain

When explaining Rust adoption, a consistent tooling experience centered on Cargo is often presented as an advantage. However, this claim has two distinct layers. One is the functional fact of which workflows Cargo, rustup, and related tools actually standardize; the other is the empirical and causal claim of how much that standardization contributes to developer productivity, onboarding, and organizational adoption decisions. The former can be established from official documentation, while the latter requires separate measurement and comparison.

Cargo is Rust’s official package manager and build tool, and it standardizes entry points for building, checking, testing, and generating documentation across Cargo projects through a manifest and common command system. rustup manages toolchains for the compiler and related tools, and the default installation profile includes rustfmt and Clippy. rust-analyzer is also an installable official component, and a project can record a toolchain channel, components, and targets in the repository through rust-toolchain.toml.25 This common default path may reduce the cost of relearning project-specific commands and tool choices. Official capability documentation, however, does not itself measure the magnitude of improvements in onboarding time or developer productivity, so the fact that the tools are integrated should not be equated with the conclusion that developers are more productive.

Usage data show both sides as well. More than 3,700 people responded to the Rust project’s 2025 compiler-performance survey, and about 60% said they use Cargo terminal commands for type checking, building, and testing. This is direct evidence that Cargo occupies a central place in the actual workflows of those survey respondents. In the same survey, however, among respondents who answered with the project where build-time problems were greatest, 55% said they waited more than 10 seconds for a rebuild after a small change, and among respondents who said they had stopped using Rust, about 45% cited long compile times as one reason. The 2025 State of Rust Survey also continued to report slow compilation and storage use as problems limiting productivity, while the survey team explicitly cautioned against overgeneralizing roughly seven thousand responses to the entire user population.26 These data therefore show both actual use of Cargo-centered workflows and their costs, but they do not establish that Cargo raises average productivity relative to other ecosystems or that it caused Rust adoption.

It is equally inaccurate to contrast the C and C++ ecosystems as environments without build and package-management tools. CMake provides configuration, build, installation, testing and packaging tools, together with Presets; Meson integrates common development tasks including building and testing. vcpkg can declare dependencies and version constraints directly in a manifest, while Conan manages C/C++ dependencies and binary packages across multiple build systems and platforms.27 The difference is less about whether tools exist than about the degree of integration in the default path and the structure of choices. In the Rust ecosystem, Cargo and multiple tools distributed by the Rust project form strong shared conventions, whereas C/C++ environments often select different combinations according to the organization, platform, and existing assets. The former can reduce coordination costs through common conventions; the latter can provide flexibility to fit existing build systems, binary-distribution practices, and internal repository policies. Neither structure can therefore be assumed to have lower total cost in every setting.

An integrated default toolchain also does not eliminate organization-level integration costs. rustup target add installs the Rust standard library for a cross-compilation target but does not provide every external linker or SDK, and Rust’s official installation documentation explains that ordinary builds require a linker and that some crates may require a C compiler because they contain C code.28 Organizations with an existing monorepo, internal build farm, private registry, security and license scanning, or packaging and deployment systems may need to connect Cargo to those systems or operate it alongside them. In large-scale and long-lived environments, evaluation should include not only the convenience of common commands but also toolchain pinning and upgrades, CI caches and build time, native dependencies, offline recovery, security auditing, migration, and rollback costs. Dependency, vendoring, and supply-chain boundaries follow the analysis already given in Section 1.5.

Interim conclusion

The official tooling path formed by Cargo, rustup, rustfmt, Clippy, and rust-analyzer is one of Rust’s clear engineering advantages. A common manifest and command system, toolchain management, and integration of first-party tools can make workflows more predictable across projects, and survey evidence shows that Cargo is widely used in the actual development workflows of many respondents. But the propositions is widely used, increases productivity, and causes adoption are distinct. Claims about productivity or adoption effects require additional comparative evidence or organizational decision records that control for project scale, team experience, existing tooling, build environment, and simultaneous changes. What this section can establish is therefore the technical characteristic of an integrated tooling experience and its applicability conditions, not that Cargo is a universal cause of Rust adoption.

2.3 Narrative Construction and an Analysis of Agenda Setting

In this section, narrative means a mode of explanation that presents problem definitions, value propositions, and comparison criteria in a coherent structure so that readers can understand what problem a technology seeks to solve and why it might be chosen. The term does not imply that a single central actor controls the message or that deliberate manipulation occurred. Agenda setting is used in a narrower sense. McCombs and Shaw’s 1972 study compared, within a specified election, location, sample, and time period, how strongly the media emphasized issues with which issues voters perceived as important. Therefore, the mere fact that a topic is repeated in official documents or online discussion does not establish an agenda-setting effect in which developers’ judgments of importance changed.29

Official Rust Project material can directly show which values were communicated. The 2015 Rust 1.0 Alpha announcement described the language’s focus in terms of safety, performance, and concurrency, and the official book calls the approach of using ownership and type checking to address many concurrency errors at compile time “fearless concurrency.” A 2018 post about the redesign of rust-lang.org explains that the previous front page had been reviewed for listing features such as zero-cost abstractions, memory safety, and data-race-free threads, while the new site put “Why Rust?” front and center and revised the slogan. At the time of this revision, the official front page presents Performance, Reliability, and Productivity as its principal value categories.30

What these sources directly establish is that the Rust Project has presented safety, performance, concurrency, productivity, and tooling experience as official value propositions and has consciously adjusted how those propositions are presented. They do not by themselves establish that “the entire Rust community shared the same narrative,” that “Rust discourse changed the evaluation agenda of systems programming,” or that “developers or organizations adopted Rust because of these messages.” Official project messaging, unofficial community discourse, audience perceptions of importance, and actual adoption decisions are different units of observation.

In particular, the proposition that “memory safety became a central evaluation criterion in systems programming because of Rust discourse” is stronger than the observation that memory safety repeatedly appears in official material. Empirically testing that proposition would require a population or sample of documents and posts, inclusion and exclusion criteria, a time period, comparison cases, a method for measuring emphasis by topic, and evidence about which criteria audiences regarded as important. Without such a design, this section can establish that official Rust communication has repeatedly foregrounded memory safety and related values, and at most that this may have provided frames for attention and interpretation. A community-wide agenda-setting effect, and its magnitude, remain unverified.29

Unofficial online discourse should be held to the same evidentiary standard. Selected posts or recurring expressions can serve as qualitative examples that a particular argument structure exists, but conclusions that it is common or dominant require a defined population, sampling method, and time period. Likewise, the educational claim that “learning Rust can help someone understand particular problems” is logically different from the status judgment that “a Rust user is therefore more intelligent or more qualified.” How prevalent the latter expressions are and what function they serve will not be generalized from selected examples; Sections 8.5 and 9.2 examine them with separate discourse evidence.

The influence of narrative on actual adoption is also a separate causal question. Official messaging may make particular advantages more salient and provide comparison criteria, but judging how much it changes developer learning or preferences, or organizational adoption decisions, requires direct evidence linking exposure, perception, and decision-making, such as surveys, experiments, longitudinal data, or organizational decision records. The effects of institutional and corporate sponsorship on trust or adoption are kept separate from this question and examined in Section 2.4.

Interim conclusion

It is documented that the Rust Project has officially presented safety, performance, concurrency, productivity, and tooling experience as important values and has adjusted how those values are communicated through its website and documentation. The existence of official value propositions, repetition in unofficial discourse, changes in audience perceptions of importance, and causal effects on actual adoption are, however, distinct propositions. This section therefore establishes the existence of official Rust communication and narrative construction, but it does not establish community-wide agenda setting or adoption effects without a defined discourse sample and audience evidence.

2.4 Institutional Sponsorship and Community Culture

The fact that institutions and companies supported Rust must be distinguished from the effect claim that such support increased trust, legitimacy, or adoption. The Rust Core Team explained in 2020 that Rust began as a Mozilla Research project and that, after Rust 1.0 in 2015, the project’s direction and governance became independent of the Mozilla organization, while Mozilla continued to serve as a major financial and legal sponsor. When the Rust Foundation launched in 2021, AWS, Huawei, Google, Microsoft, and Mozilla participated as founding members, and the Foundation’s board consisted of five directors from those member companies and five directors from the Rust Project.31

This history also requires distinguishing institutional support from the Rust Foundation from technical decision-making in the Rust Project. During the discussions about creating the Foundation, the Rust Core Team explained that the Foundation would provide a basis for legal and financial support and maintainer support while the scope of work and decision-making authority of most Rust teams would not change. At the time of this book revision, the Rust Project’s official governance still separately includes a Leadership Council and multiple top-level teams. Foundation membership therefore does not mean that a member company directly controls technical decisions about the language or compiler. Conversely, the existence of a legal entity, financial support, infrastructure, and maintainer-support systems describes project operating conditions, but how much those conditions changed trust or adoption decisions in outside organizations is a separate empirical question.31

The Foundation’s launch announcement interpreted the founding companies’ long-term financial commitments as a signal that Rust had established itself as a production-ready technology in corporate environments. That is, however, the Foundation’s own official interpretation, not an independent measurement of perceptions or adoption effects in outside organizations. A claim that corporate sponsorship affected trust, legitimacy, or adoption would require additional survey or comparative evidence showing whether sponsorship was actually an evaluation factor in decision records, how perceptions changed before and after sponsorship, and how other technical and organizational factors were controlled.31

For community culture as well, the existence of official norms and resources must be separated from behavior and outcomes across the community as a whole. Rust’s Code of Conduct aims to provide a kind, safe, and welcoming environment in official Rust spaces and specifies moderation and enforcement procedures for violations. Rust’s official learning page presents The Rust Programming Language as an introductory resource, and the Book itself structures a learning path through installation, Cargo use, ownership, and other language topics.32 These sources show which norms and learning resources the Rust Project officially provides, but they are not evidence that every interaction satisfies those norms or that the same culture is observed throughout unofficial Rust communities.

Likewise, the existence of a Code of Conduct and learning materials alone does not establish that barriers to entry actually fell, learning time decreased, or retention or diversity among new participants increased. Evaluating such effects would require surveys or comparative studies connecting new users’ and contributors’ experiences with attrition and retention data, learning time and success rates, and use of the documentation. From a large-scale and long-lived operational perspective, evaluation should consider not merely the number of sponsoring institutions but the continuity of legal and financial responsibility, dependence on particular sponsors, separation between governance and technical decision-making, and the ability to respond if infrastructure or maintainer support is interrupted or changed. The Rust Project’s explicit effort during the 2020 Foundation process to diversify infrastructure support and reduce dependence on a single sponsor is relevant to this distinction.31

Interim conclusion

Mozilla’s long-term sponsorship, the creation of an independent Rust Foundation, a Foundation structure in which company and project representatives participate together, the Rust Project’s Code of Conduct, and its official learning resources are all documented institutional and community foundations. The existence of support systems, the existence of official norms and resources, changes in trust, learning, or community behavior, and causal effects on actual adoption are nevertheless distinct propositions. This section therefore establishes that Rust has institutional support and official community practices, but it does not establish without direct outcome evidence that they are universal causes of adoption or community outcomes.

2.5 Synthesis of Adoption Factors and Chapter 2 Conclusion

The preceding sections identified distinct factors that can be considered when explaining Rust adoption. Section 2.1 established technical fit in some environments that require memory safety together with low-level control; Section 2.2 the common workflow provided by Cargo and the official toolchain; Section 2.3 the values and narrative construction that the Rust Project has officially presented; and Section 2.4 Mozilla sponsorship, the institutional foundation provided by the Rust Foundation, the Code of Conduct, and learning resources. But the fact that these elements coexist does not establish that they formed a causal chain that produced Rust adoption or amplified one another’s effects.

This distinction becomes even more important depending on the scope of adoption used in this chapter. Experimental use, adoption for a new component, partial replacement of an existing system, team-level use, and organizational standardization are different decisions, and the same technical property or tool may carry different weight at each scope. Therefore, the fact that Rust was used in a case shows that adoption was feasible and Rust was selected under those conditions, but it does not show which factor was decisive or whether its effect would recur at another scope or in another organization.

The evidentiary boundaries of Sections 2.1-2.4 must also be preserved. Technical fit explains a possible reason for selection but did not measure its contribution to an actual decision, and the extent to which Cargo-centered workflows are widely used is a different proposition from their effects on productivity or adoption. The existence of official value propositions, institutional support, a Code of Conduct, and learning resources is likewise documented, but changes in audience perceptions, behavior across the community, external organizational trust, and actual adoption effects require separate outcome evidence. The material in this chapter also provides no basis for ranking the relative importance of these factors.

The explanation that these factors interacted is a plausible hypothesis, not itself an observed result. Establishing it empirically would require surveys, decision records, longitudinal data, or a comparable research design that links technical evaluation, tooling experience, exposure to messaging, institutional conditions, and actual decisions. Alternative explanations must also be examined, including existing code and interfaces, team experience and staffing, architectural and operational constraints, security and procurement policies, schedule and cost, and redesign or process changes occurring at the same time. Without controlling for such conditions, successful projects or adoption cases cannot isolate the independent effects of the language, tooling, sponsorship, or narrative.

Chapter 2 conclusion

What the documents and data establish is that Rust has technical characteristics that can fit some systems-software environments, an integrated official tooling path, repeatedly presented official value propositions, and institutional support and official community practices. These elements provide reasons and conditions that a particular organization or developer may consider when evaluating and selecting Rust. But the existence of possible reasons for adoption, their contribution to an actual decision, interaction among multiple factors, and an average causal effect generalizable to other organizations are distinct propositions.

Accordingly, this chapter does not explain Rust adoption through a single form of technical superiority or a single narrative effect. The material currently reviewed is sufficient to identify multiple candidate factors and conditions of applicability, but insufficient to establish generally which factor was decisive at which scope of adoption or by how much. Later industrial cases and comparative analyses should likewise avoid using adoption itself as evidence of technical superiority and instead separate decision records, system conditions, simultaneous changes, and alternative choices. Part 2 separates this causal question from the analysis of the guarantees, costs, and historical relationships of Rust’s major design principles, including safety and ownership.

Part 2: Technical Analysis of Major Design Principles

Part 1 examined Rust’s technical characteristics and related narratives. Part 2 technically analyzes Rust’s major design principles of safety and ownership.

It examines from several perspectives the basis for describing these principles as innovative, their engineering trade-offs, and how they relate to historical precedents in languages such as C++ and Ada. It also distinguishes refactoring, modernization, partial replacement, and complete rewriting of an existing codebase as different change strategies, establishing criteria that avoid equating language-level guarantees with project-level improvement outcomes.

3. A Multidimensional Analysis of the Safety Narrative

The “safety” addressed in this chapter is not a single undifferentiated property. Rust’s language guarantees, compiler and library implementations, failure modes during operation, strategies for changing existing systems, and the use of the word “safety” in technical discourse are different units of analysis. Accordingly, this chapter does not presuppose broad propositions such as “Rust is safe” or “existing languages are unsafe”; it examines separately which properties are guaranteed under which conditions.

Section 3.1 first examines the historical relationship between Rust’s design and earlier languages and techniques while distinguishing historical precedent, conceptual similarity, and direct influence documented by official sources. Section 3.2 analyzes the technical guarantees of Safe Rust and the boundaries involving unsafe, panic, memory leaks, logical errors, and related cases. Section 3.3 compares incremental improvement in C/C++, partial replacement, and rewriting in Rust as distinct change strategies. Sections 3.4-3.5 examine Ada/SPARK and GC-based languages under common comparison criteria, while Section 3.6 separately considers how “safety” is used in discourse. Section 3.7 then synthesizes these results as engineering trade-offs.

This ordering is intended to avoid conflating historical precedent with current guarantees, strong language guarantees with successful project transition, or the existence of a particular rhetorical expression with evidence of technical superiority.

3.1 The Meaning of Innovation and an Analysis of Historical Precedents

In technology, “innovation” need not mean that no preceding concept existed. New combinations, scopes of application, locations of enforcement, usability, or implementation techniques can themselves be innovations. Conversely, similarity between two technologies is not enough to establish that one was directly derived from the other. In this section, direct influence is used only where primary Rust Project material explicitly identifies an influence; other relationships are limited to historical precedent or conceptual similarity.

C++ RAII and Rust ownership: documented influence, different locations of enforcement

The Rust Reference explicitly lists C++ references, RAII, smart pointers, and move semantics among the influences on Rust’s design. The official Rust Book likewise explains that the pattern of releasing resources with drop when a value’s lifetime ends is called RAII in C++. The C++ Core Guidelines recommend encapsulating resources in objects so that acquisition and release are paired by constructor and destructor lifetime rules, and they treat an object responsible for releasing a resource as an owner.33 The relationship between C++ RAII and related resource-management techniques and Rust is therefore a historically documented connection, not merely a superficial resemblance.

This does not mean, however, that “resource ownership” as a general concept was first invented in C++ and then simply extended by Rust. Rust combines deterministic resource release with separate rules that restrict use of the original binding after an ownership move and statically constrain aliasing between mutable and shared access through borrowing. The same Rust Reference separately lists region-based memory management in ML Kit and Cyclone among Rust’s influences.33 Reducing Rust’s memory and lifetime design to a single C++ lineage would therefore also be inaccurate. This section establishes only the existence of the relationship and differences in where rules are enforced; Section 3.2 addresses exactly what Safe Rust guarantees, and Section 4.1 provides the detailed comparison of RAII and Rust ownership.

Ada and SPARK: an earlier high-reliability and verification lineage, but not the same ownership lineage

The Ada 1983 standard predates Rust, and the Ada Reference Manual describes reliability and maintenance of programs, human programming activity, and efficiency among the principal concerns of the original design. Ada’s type and subtype system and language-defined run-time checks established a tradition of turning some classes of errors into explicit check failures. The original SPARK language was also based on Ada 83 and developed a separate high-assurance lineage using static analysis and verification conditions to verify properties such as initialization, information flow, absence of run-time errors, and specified contracts.34 In this sense, Ada/SPARK is an important historical comparator when evaluating claims that systems languages and verification techniques addressing both safety and efficiency did not exist before Rust.

It would exceed the evidence, however, to turn this into a claim that “Ada/SPARK had already implemented the same GC-free memory-safety model as Rust” or that “Rust was directly influenced by Ada/SPARK.” The Rust Reference influence list examined here explicitly names C++, SML/OCaml, ML Kit, Cyclone, and others, but does not list Ada or SPARK as direct influences. Moreover, the current SPARK pointer-ownership policy is a later-added feature, and AdaCore describes that pointer support as being based on Rust’s ownership model.34 This section therefore treats Ada/SPARK as a historical precedent for high-reliability goals and static/formal verification, not as a direct ancestor of Rust ownership. SPARK proofs also establish specified properties under stated assumptions and analysis scopes, while the Rust borrow checker performs a different class of automatic checks; without naming a property, it is not meaningful to rank one system categorically as “broader” or “stronger.”

Algebraic data types and error representation: narrowing the scope of direct influence

The Rust Reference explicitly lists algebraic data types, pattern matching, and type inference from SML and OCaml among the influences on Rust’s design. Rust’s Option<T> has None and Some(T), Result<T, E> has Ok(T) and Err(E), and OCaml’s standard option likewise represents absence and presence of a value with None and Some.35 Rust’s use of sum-type-like data types to represent absence or success and failure can therefore be related to the functional-language tradition.

The official influence list, however, directly supports only the influence of SML/OCaml algebraic data types, pattern matching, and type inference. These sources alone do not establish that the concrete APIs of Result and Option were directly derived from a particular Haskell or OCaml error-handling API, or that Rust simply borrowed “monadic error handling” wholesale. Exhaustive match can statically check coverage of variants, but Rust also does not require every error-handling path to spell out every case explicitly. What is established here is a design lineage of type-based state representation and Rust’s particular expression of it, not a single lineage for all error-handling mechanisms.35

Interim conclusion

The picture is clearer when historically documented relationships are separated from comparisons. C++ RAII, smart pointers, and move semantics, and SML/OCaml algebraic data types, are among the elements that the Rust Reference records as direct influences. Ada and early SPARK are historical comparators from a pre-Rust lineage of high-reliability engineering and formal verification, but the material in this section does not establish them as direct influences on Rust; current SPARK pointer ownership was instead added later with reference to the Rust model. Rust’s originality is therefore more accurately examined in how it combines and enforces multiple prior ideas within a particular set of ownership and borrowing rules and a language/tooling system than in the proposition that no precedent existed. What guarantees that combination provides and what costs it imposes are engineering questions separate from historical priority and are analyzed property by property in the following sections.

3.2 Definition, Boundaries, and Limitations of Rust Safety

The question in this section is not “Is Rust safe?” but what Safe Rust guarantees under which conditions, and where those guarantees end. The language-level safety contract, the soundness of unsafe implementations, the correctness of implementations and external systems such as compilers, libraries, and operating systems, and service availability are different units of analysis. Collapsing them into a single notion of “safety” would exaggerate both Rust’s real strengths and its real limitations.

Section 3.2.1 therefore examines the relationship between Safe Rust and undefined behavior (UB); Section 3.2.2 analyzes unsafe and FFI not as an abandonment of guarantees but as boundaries defined by explicit safety contracts and proof obligations. Section 3.2.3 distinguishes the unwind and abort strategies of panic and the limits of isolation and recovery; Section 3.2.4 explains why memory and resource leaks lie outside the memory-safety guarantee; and Section 3.2.5 separates logical errors, general race conditions, deadlocks, resource exhaustion, and security vulnerabilities from memory safety.

3.2.1 Definition of Safety: Preventing Undefined Behavior

The Rust Reference defines UB as a set of behaviors that a program must not exhibit. Its current list includes data races, invalid memory access based on dangling or misaligned pointers, violations of aliasing rules, calling a function with the wrong ABI, and producing invalid values. The Reference does not claim that this list is a complete formal semantics and explicitly notes that the boundary may be adjusted in the future.36

The core Safe Rust contract is best understood as ensuring that a safe caller, when using sound safe interfaces, cannot cause UB through those interfaces. This is different from an empirical prediction that “if the source code contains no unsafe, UB can never occur for any reason in the entire program.” Safe Rust code can call safe APIs from the standard library or third-party libraries whose implementations may contain unsafe. If such an implementation fails to uphold its safety contract so that a safe caller can cause UB, the implementation is unsound in the terminology of the Rust Reference.36

Specific error classes must be distinguished under the same criterion. Dereferencing an allocation that is no longer live, or creating and using an invalid reference, can be UB; Rust references must be aligned, non-null, and non-dangling. Data races are also UB. By contrast, when ordinary safe array or slice indexing is dynamically out of bounds, the indexing operation performs a run-time bounds check and enters panic rather than automatically becoming UB through a buffer overflow. Operations such as get_unchecked, which omit that bounds check, are unsafe operations with an additional safety condition; violating that condition crosses into the UB boundary.37

This distinction is important for separating language guarantees from implementation correctness. The contract that Rust’s language model requires of a safe interface, whether a particular rustc version implements that meaning correctly, whether internal unsafe code in the standard library or a crate is sound, and whether an operating system, hardware platform, or foreign code honors its own contract are different questions. Compiler defects or unsound library implementations can break memory safety in an actual execution and are important implementation risks, but that fact should not be restated as the different claim that “Safe Rust’s language rules permit UB.”

3.2.2 The unsafe Keyword and the Boundary of FFI and External Contracts {#322-the-unsafe-keyword-and-dependence-on-the-c-abi}

unsafe is not a switch that disables ownership, typing, lifetime rules, and the rest of Rust’s checks. The Rust Reference describes unsafe as a marker that creates a proof obligation for additional safety conditions the compiler does not check, or declares that an obligation created elsewhere has been discharged. An unsafe fn can define additional conditions that its caller must satisfy, while an unsafe { ... } block asserts that the programmer has satisfied the conditions of the unsafe operations performed inside it. UB remains invalid inside unsafe, and the other type checks and language rules do not disappear.38

Responsibility therefore does not move to one fixed location. The caller must satisfy the documented preconditions of an unsafe fn, but a safe abstraction that hides unsafe internally has the opposite obligation: its implementer must ensure that the internal safety conditions hold for every safe input. A safe caller must not need to know an undocumented safety condition in order to avoid UB for a safe API to be sound. It is therefore inaccurate to say that “using unsafe transfers all safety responsibility to the caller.” The relevant question is which contract is defined at a particular API boundary and who must discharge each proof obligation.38

FFI is a representative case in which this boundary becomes explicit. An external block is the basis for declaring items defined outside the current crate, and the Rust Reference treats it as a boundary akin to an unchecked import. In the Rust 2024 Edition, the external block itself must be marked unsafe extern, and the author of the declaration is responsible for ensuring that the signatures of functions and statics match their actual external definitions. Foreign items generally require unsafe calls or access unless they are explicitly declared safe.39

FFI, however, should not be equated with a universal structural dependence on the C ABI. The "C" ABI is a very important interoperability path and is also the default when an external block omits an ABI string, but Rust defines other ABIs such as "system" and "C-unwind"; low-level functionality can also be implemented through unsafe operations or platform-specific interfaces other than FFI. How extensively an actual system uses the C ABI is a property of its operating system, libraries, hardware, and integration architecture. The language-level boundary in Rust is not simply “it uses C” but who guarantees an external contract that the compiler cannot verify, and on what basis.39

At large scale, this distinction directly affects maintainability and fault isolation. An FFI wrapper can localize risk by validating pointer validity, lengths, ownership, lifetimes, aliasing, ABI rules, and error and unwind conventions at a narrow internal boundary, while exposing only a sound safe API externally. Conversely, if internal unsafe behind a safe API, an external library, or an ABI declaration is wrong, even a call site written entirely in Safe Rust can be affected. The strength of Safe Rust is therefore not that it eliminates every unverified obligation, but that it can isolate many such obligations away from safe callers and concentrate them at narrow boundaries.

3.2.3 Safe Failure and the Meaning of panic

It is not accurate to define panic as one universal model of “safe failure.” When a defined safe operation detects an error condition and panics, as with bounds checking in safe array indexing, the panic itself is not UB. What happens to the program and service afterward, however, depends on the panic strategy and the system’s isolation structure.

Cargo and rustc broadly distinguish unwind and abort panic strategies. With unwind, a panic unwinds the stack and can perform cleanup along that path; with abort, the process terminates. The strategy actually used can vary with the target platform and build configuration, so it is not correct to generalize that “a panic always unwinds the stack and terminates only the current thread by default.” More broadly, Rust’s safety contract does not guarantee that every destructor will necessarily run.40

std::panic::catch_unwind is likewise not a general exception-handling or service-recovery guarantee. It catches only unwinding panics and cannot catch an aborting panic. The standard-library documentation states that Result is more appropriate for failures that can occur as part of normal operation and does not recommend catch_unwind as a general try/catch mechanism. Its closure is also subject to the UnwindSafe boundary, and the possibility that later code observes partially modified state or a broken logical invariant during a panic must be handled separately.40

A thread boundary is not the same as automatic recovery either. Under unwinding, when a child thread panics, JoinHandle::join can expose that failure as Err, allowing a thread to be designed as an isolation unit. Turning that observation into actual service recovery still requires the caller to handle the Err, verify the consistency of shared state, and define retry, discard, or restart policies for the failed work. With panic = "abort", the process itself can terminate; designs that unwrap a join result or propagate a panic to a higher boundary can also interrupt service.40

Memory safety and availability are therefore separate properties. The fact that panic is defined control flow rather than UB does not by itself guarantee request isolation, thread/process boundaries, supervision and restart, state recovery, retry policy, or a bounded fault-propagation domain. Long-running servers and embedded or mission-critical systems must separately define both the panic strategy and the execution boundary to which a failure may propagate, together with how service will be restored afterward.

3.2.4 The Problem of “Safe” Memory Leaks

The Rust Reference explicitly includes leaks of memory and other resources among behavior that is not considered unsafe. Here, “safe” does not mean operationally desirable or failure-free; it means that the leak itself is not UB that violates Rust’s memory-safety contract.41

This boundary is especially clear in the standard-library function std::mem::forget. mem::forget is a safe function that takes ownership of a value and deliberately forgets it without running its destructor. The documentation explains that the function does not need to be unsafe because Rust’s safety guarantees do not include guaranteed destructor execution, and gives Rc<T> reference cycles and process termination as other cases in which destructors may not run. The Rust Book likewise explains that a reference cycle built with Rc<T> and RefCell<T> can leak memory in Safe Rust.41

This is not merely a terminology issue. Leaked heap memory, file descriptors, sockets, locks, and related external resources can cause resource exhaustion, higher latency, failed requests, and ultimately service interruption in a long-running process. A memory-safe leak is therefore not an availability-safe operation. At large scale and over long lifetimes, finite resources such as memory, descriptors, connections, tasks, and queues require separate invariants for upper bounds and reclamation paths.

An unsafe implementation must also not make its soundness depend on an assumption that “the caller will eventually run Drop.” A safe caller can use mem::forget, and a process can terminate without running destructors. This principle shows that Rust’s safety boundary is broader than a simple RAII explanation and that resource lifecycle must be distinguished from memory-safety proof obligations.

3.2.5 Problems Outside the Guarantee’s Scope: Logical Errors, Deadlocks, and More

Safe Rust’s strong guarantees do not automatically extend to every correctness, security, and availability property. The Rust Reference does not classify deadlocks or memory/resource leaks as unsafe; a violation of an additional logical condition in safe code can produce a panic, an incorrect result, an abort, or non-termination without thereby becoming UB.42

In particular, data races must be distinguished from general race conditions. A data race is UB in Rust and is a central class that Safe Rust prevents. The borrow checker does not, however, eliminate every general race condition in which results depend on execution order, nor TOCTOU bugs, incorrect protocol state transitions, livelock, or starvation. The Rustonomicon likewise distinguishes the guarantee that Safe Rust is free of data races from the fact that it does not prevent general race conditions.43

Integer overflow requires the same care at the boundary. The Rust Reference treats arithmetic overflow as a programmer error but does not classify it directly as UB. When debug_assert! is enabled, the implementation must insert dynamic checks that panic on overflow; in other builds, the implementation may either panic or implicitly wrap. When implicit wrapping occurs, the result is defined by two’s-complement rules. Cargo profiles control run-time overflow checking through overflow-checks, so the behavior should not be reduced to a fixed rule that “debug panics and release always wraps.”42

Security vulnerabilities are also broader than memory safety. CVE-2024-24576, published by the Rust Security Response WG in 2024, concerned insufficient argument escaping when std::process::Command executed batch files on Windows; under conditions in which an attacker controlled an untrusted argument, the flaw could lead to arbitrary shell-command execution. The API was safe to call, but the core defect was not memory corruption: it was a logical defect in command-argument handling and the API contract. The original issue was fixed in Rust 1.77.2. A separate incomplete-fix issue, CVE-2024-43402, was later reported in which trailing whitespace and periods could bypass the mitigation, and it was addressed in Rust 1.81.0.44

The conclusion that can be drawn from these cases is limited. The existence of logical security defects in particular past standard-library versions does not establish the vulnerability frequency of the Rust ecosystem as a whole or the risk of current versions. Conversely, the strength of Safe Rust’s memory-safety contract is not evidence that command injection, authentication or authorization errors, protocol bugs, resource exhaustion, deadlocks, incorrect state transitions, or failures of service recovery are automatically eliminated.

Interim conclusion

Safe Rust’s important engineering advantage is that, within sound abstraction boundaries, it enforces that safe callers cannot cause specified classes of UB and data races. That guarantee does not combine compiler correctness, soundness of unsafe implementations, the contracts of FFI and external systems, general race conditions, logical correctness, resource bounds, panic isolation, and service recovery into a single guarantee. “Memory safety,” “security,” “correctness,” “availability,” and “resilience” can be related, but they should not be evaluated as identical properties. This distinction provides a criterion for the comparisons of other languages and change strategies in the next section; by itself, it does not establish the superiority of any language-migration strategy.

3.3 Comparative Analysis 1: Layered Safety in C/C++ and Change Strategies

The question in this section is not “Should C/C++ be replaced with Rust?” but which change strategies should be selected or combined given the existing system’s defect model and assets, transition risk, and assurance requirements. The Safe Rust guarantees established in Section 3.2 are an important input to language choice, but those guarantees alone do not determine whether maintenance, modernization, selective replacement, new development, or a full rewrite is the best strategy.

At least two kinds of effects must be separated when comparing change strategies. One is which defects the resulting implementation prevents, detects, or mitigates. The other is the specification recovery, compatibility, deployment, rollback, dual-operation, staffing, and long-term maintenance costs created by the change itself. The former concerns the quality of the target state; the latter concerns transition risk. Counting only one side can overvalue either language guarantees or existing system assets.

3.3.1 Distinguishing Refactoring, Modernization, and Rewriting

This book distinguishes the following change strategies. These are working definitions intended to make the comparison units in this section explicit rather than a universal taxonomy for every methodology.

  • Maintenance and defect hardening: Fixing defects and strengthening input validation, isolation, hardening, testing, and observability without replacing the existing implementation or its external behavior.
  • Refactoring: Improving internal structure while preserving externally observable behavior. Martin Fowler likewise defines refactoring as changing internal structure without changing observable behavior.45
  • Modernization: A broader activity that improves language features and libraries, build and analysis tools, APIs, module boundaries, deployment structures, and related elements. It may intentionally change external behavior or operations when necessary.
  • Selective replacement: Replacing some components whose risk or expected value justifies a new implementation while keeping them interoperable with the rest of the system. The language may change, or the component may be reimplemented in the same language.
  • New-component adoption: Writing new functionality or services in another language without replacing an existing implementation.
  • Full rewrite: Replacing a broad portion of an existing implementation with a new implementation. Because language migration can also be partial, “language migration” and “full rewrite” are not synonyms either.

Therefore, rewriting C/C++ in Rust is not a synonym for refactoring. It may be selective replacement, a full rewrite, or one form of a broader language migration. Conversely, adopting Rust does not necessarily imply a rewrite: a project can write only new components in Rust, or replace a narrow high-risk module while retaining the surrounding C/C++ system.

3.3.2 The Practical Value of Refactoring and Modernizing Within C/C++

The improvement mechanisms available to C and C++ cannot be reduced to a single language guarantee equivalent to Safe Rust. Design rules, type and resource-management idioms, static analysis, run-time instrumentation, testing and fuzzing, isolation, and exploit mitigation operate at different layers. Prevention, detection, and mitigation must therefore be distinguished.

The C++ Core Guidelines recommend automatic resource management through RAII and resource handles, expression of ownership with unique_ptr and shared_ptr, and range representations such as span. At the same time, the Guidelines are designed for gradual adoption in existing codebases, and the language itself does not enforce every rule. clang-tidy likewise provides selectable checks such as cppcoreguidelines-*, clang-analyzer-*, and bugprone-*, but its scope is limited to patterns the enabled analyses can diagnose.46

The nature of dynamic tooling is even clearer. Clang’s AddressSanitizer detects several classes of memory error—including heap, stack, and global out-of-bounds accesses, use-after-free, and invalid free—in instrumented executions, while ThreadSanitizer detects data races. UndefinedBehaviorSanitizer similarly instruments selected UB checks at run time. These are powerful tools for finding defects in C and C++, but they are not language-level proofs of absence over paths that were never executed. They also have costs: current Clang documentation describes typical AddressSanitizer run-time overhead of about 2x, and typical ThreadSanitizer run-time overhead of about 5x–15x with memory overhead of roughly 5x–10x. The ASan and TSan runtimes are also not designed to be linked into production executables, and the documentation warns that production use in security-sensitive environments may itself create risk. Large-scale, high-load, and real-time systems therefore need tool-specific deployment boundaries: detection runtimes such as ASan and TSan are primarily placed in CI and testing, while canary or production environments should use instrumentation or mitigations whose suitability for those environments has been separately established.46

C code can likewise reduce risk through allocator/free contracts, length-carrying buffer interfaces, a single ownership rule, narrow foreign interfaces, static and dynamic analysis, and fuzzing. If those rules depend on organizational convention, API discipline, or a particular toolchain configuration, however, their location and strength of assurance differ from the language-level contract provided by a sound Safe Rust interface.

Layer Representative means Main effect Assurance or operational limit
Design, types, and resource management RAII, smart pointers, span, explicit ownership/length contracts Narrows the scope of risky lifetime and buffer manipulation Raw pointers, legacy APIs, FFI, and rule-bypassing paths still require separate control
Static analysis clang-tidy, Clang Static Analyzer, and similar tools Diagnoses source-level defects and rule violations that can be inferred by the enabled analyses Depends on enabled checks and analysis precision; not a language-wide absence guarantee
Dynamic analysis ASan, TSan, UBSan Detects selected memory, UB, and data-race defects in instrumented executions Depends on executed paths and environment and incurs time and memory costs
Testing and fuzzing Regression tests, property-based tests, coverage-guided fuzzing Executes existing behavior and boundary conditions for validation Can miss defects when the test oracle or coverage is incomplete
Isolation and hardening Sandboxing, memory tagging, hardened allocators, exploit mitigations Reduces reachability, impact, or exploitability of defects Does not remove every defect and may add performance, memory, or operational costs

The fact that this multilayered approach does not provide the same guarantee as Safe Rust matters. But a weaker guarantee, or a guarantee located at a different layer, is not the same claim as zero engineering effect. Conversely, extensive use of sanitizers and guidelines does not by itself give C/C++ code the same memory-safety contract as Safe Rust.

Current Android documentation applies this distinction as an operational strategy. AOSP says that Rust is preferred for most new native projects while also stating that rewriting all existing memory-unsafe code in Rust is not realistic and that Rust complements memory-safety tooling. Existing C/C++ continues to use detection and hardening such as HWASAN, KASAN, GWP-ASan, and memory tagging.47 The case shows that improving C/C++ and adopting Rust are not opposites and can coexist during a large-scale transition. It does not establish that Android’s code structure and vulnerability distribution generalize to other projects.

3.3.3 Guarantees Added by a Rust Rewrite and Risks Newly Created

For the scope that is newly written or replaced in Rust, the memory-safety contract of Safe Rust described in Section 3.2 can become a design default. This is a strong advantage distinct from detection by guidelines or sanitizers. Language-level prevention becomes especially valuable when memory-safety defects have high impact, unsafe and FFI boundaries can be kept narrow, and the organization can maintain the component over its intended lifetime.

However, the guarantee of the target language state and rewriting as a method of change are different units of analysis. A rewrite requires a new implementation to satisfy the required behavior, compatibility, performance characteristics, and operational contracts of the existing system again. As Martin Fowler notes when discussing gradual replacement, the actual behavior of an established system can contain more detailed specification than was apparent when the replacement effort began, and a large cut-over can concentrate risk in one event. His Strangler Fig is a gradual replacement pattern motivated by those concerns, not an empirical law that partial replacement is always superior in every system.48

Language replacement therefore introduces separate verification questions.

  1. Behavioral specification and test oracle: The project must decide which legacy behavior must be preserved and which behavior is intentionally removed. If the existing tests are insufficient, even the meaning of “equivalent” behavior in the new implementation can be ambiguous.
  2. Interop and safety boundaries: Coexistence with existing C/C++, operating-system interfaces, drivers, or libraries requires FFI, ABI, ownership, error, and unwind contracts to be stated again. The Section 3.2 boundary still applies: an unsound boundary can affect callers written entirely in Safe Rust.
  3. Deployment, rollback, and state compatibility: Parallel or staged transition requires protocol, data-format, persistent-state, and rollback compatibility to be designed explicitly.
  4. Performance and operational maturity revalidation: The new implementation must be revalidated under the target workload not only for average performance, but also for tail latency, peak memory, startup, failure modes, rare inputs, observability, and recovery behavior.
  5. Long-term organizational cost: The organization must evaluate whether it can maintain two languages and toolchains, dependencies, builds, debugging, code review, hiring, and training during the transition or for a longer coexistence period.

Android is a representative case of treating this problem as an interop-centered gradual transition. The Android team judged a wholesale C++ rewrite impractical and analyzed interoperation between existing code and Rust as a practical precondition. A 2024 firmware case prioritized new code and existing code with high security risk and described selective replacement through a thin Rust shim that preserved the existing C API.49 This shows that partial adoption can be a practical strategy in a large system. The 2021 interop analysis, however, evaluated compatibility and practicality using exported C++ APIs and types actually used in the Android platform; it is not general evidence measuring interface cost or suitability across arbitrary codebases.

The same cases do not justify the opposite generalization that “full rewrites are always wrong.” The Android team rewrote the protected-VM firmware of the Android Virtualization Framework in Rust to provide a memory-safe foundation for the pVM root of trust.50 A component-level rewrite can be reasonable when the boundary with high assurance benefit is narrow, requirements and verification scope are controllable, and there is little reason to preserve the existing structure itself.

Language replacement therefore does not simply eliminate risk; it changes the kinds and locations of risk. Moving a bounded scope to sound Safe Rust can reduce specified memory-safety risks, while a larger transition requires concurrent control of specification recovery, interop, deployment, rollback, operational maturity, and organizational capability. Net effect should be evaluated by comparing both kinds of risk on the same basis rather than by lines of code alone.

3.3.4 A Continuum of Change Strategies and Selective Adoption

Real projects do not have to choose the following strategies as mutually exclusive alternatives. A single system can retain and harden mature C++ modules, write a new native component in Rust, selectively replace only a high-risk parser that handles untrusted input, and rewrite a small subsystem whose existing structure has reached the end of its useful life.

Change strategy Conditions to check first Main effect that can be obtained Main transition and operational risk
Retain current implementation and harden defects Defects are localized and change risk is greater Smallest transition scope and preservation of existing behavioral assets Structural debt and memory-unsafe areas may remain
Modernize within C/C++ Ownership, boundaries, and verification can be improved while preserving behavioral assets Incremental risk reduction and fast rollback Completeness of rule and tool adoption depends on the toolchain and organizational discipline
Write new components in Rust New functionality does not require reimplementing established behavior Applies Safe Rust defaults to new code without rewrite regression Integration costs with existing APIs, builds, and runtimes
Selectively replace high-risk modules with Rust Defect risk is concentrated at a narrow interface Concentrates assurance benefits where risk is high FFI/ABI and dual-language lifecycle costs
Full or broad rewrite Existing architecture itself blocks requirements, and specification, test oracles, and transition resources are sufficient Redesigns architecture and implementation model together Broadest regression, cut-over, rollback, schedule, and organizational risks

At minimum, the following questions should be made explicit before choosing a strategy.

  1. Defect model: Is the problem to be reduced primarily memory safety, such as use-after-free or data races, or logic defects, availability, performance, or operational complexity?
  2. Defect distribution: Is risk concentrated in newly changed code or particular parsers, drivers, or protocol boundaries, or distributed across the whole system?
  3. Specification and verification assets: Are behavioral specifications, regression tests, corpora, fuzz targets, benchmarks, and production telemetry sufficient to judge a new implementation?
  4. Boundaries and coexistence: Are module interfaces narrow enough to state ownership, lifetime, error, and state contracts explicitly?
  5. Deployment and rollback: Are partial rollout, shadow or canary deployment, rollback to the previous implementation, and data/state compatibility feasible?
  6. Performance and resource budgets: Can the strategy meet not only throughput but tail latency, worst-case behavior, memory, code size, startup, energy, and build/test costs?
  7. Assurance requirements: Do regulations, the threat model, or the assurance case require stronger language-level prevention or formal proof rather than convention and detection?
  8. Organization and lifecycle: Does the organization have people and processes capable of reviewing, debugging, and updating two languages and toolchains during the transition or over a long coexistence period?

Different answers can make different strategies reasonable even within the same codebase. Android’s official approach combining new memory-safe code, hardening of existing C/C++, interop, and selective replacement of high-risk areas is one example of such a mixed strategy.47 It is not evidence that “gradual adoption is always best,” but evidence of possibility that a full rewrite is not the only route to improving memory safety.

Evaluation metrics should not stop at language choice either. The recurrence rate and severity of target defects, functional regressions, tail latency and resource ceilings, build/test time, recovery time, rollback success, operational complexity, and dependency and tooling maintenance costs should be measured with the same definitions before and after change. Without measurement, claims that a result is “safer” or “more maintainable” again conflate a language guarantee with a project outcome.

3.3.5 Claim Analysis: “The Only Meaningful Refactoring Is a Rewrite in Rust”

The following sentence is not a direct quotation from a particular person or from the Rust Project. It is a composite analytical proposition used to test the argument structure that the only meaningful improvement to C/C++ is a Rust rewrite.

“Refactoring C/C++ means rewriting it in Rust; any other refactoring is meaningless.”

Taken as a general proposition, it has the following problems.

  1. Category error: It defines refactoring, which preserves observable behavior, as the same operation as a rewrite that replaces the implementation.
  2. False dilemma: It compresses the actual choice space—maintenance and hardening, modernization in the same language, new Rust code, selective replacement, and broad rewriting—into only “neglect” and “full rewrite.”
  3. Nirvana fallacy: Because C/C++ tooling and modernization do not provide the same memory-safety guarantee as Safe Rust, it treats even their partial effects on defect detection, impact reduction, and maintainability as zero.
  4. Conflation of guarantees and outcomes: It risks equating Safe Rust’s language contract with the post-migration system’s overall security, availability, correctness, and maintainability outcomes.
  5. Omission of transition costs: It excludes specification recovery, FFI/ABI, dual-language builds, rollout, rollback, data and protocol compatibility, and organizational learning from the comparison.
  6. Asymmetric evidence standard: If C/C++ improvement is required to prove complete defect elimination while a Rust transition is treated as proven successful for the whole project by language guarantees alone, the two strategies are being evaluated under different standards of evidence.

The opposite generalization should also be avoided. “If C/C++ is modernized well enough, there is no reason to move anything to Rust” is not universally true either. If memory-safety defects are a principal threat, process and testing cannot reduce the risk to an acceptable level, or the required assurance demands stronger prevention, Safe Rust’s enforced guarantee can be an important reason to justify selective replacement or rewriting.

Interim conclusion

The conclusion of Section 3.3 is not that one language is always superior, but that language guarantees and change strategies must be evaluated separately. Safe Rust provides a strong default that prevents specified UB and data races within sound boundaries, and this is a real difference in assurance level from C/C++ guidelines, analyses, and testing. Existing C/C++ refactoring, modernization, and hardening can nevertheless reduce real risks at other layers, and in large existing systems they can be combined with new Rust adoption and selective replacement.

Which of maintenance, modernization, new Rust adoption, selective replacement, or full rewriting is appropriate therefore depends on the defect model, assurance requirements, existing behavioral assets, interfaces and testability, rollout and rollback feasibility, performance and resource limits, organizational capability, and total lifecycle cost. Without those conditions, both universal propositions—”only a Rust rewrite is meaningful” and “improving existing C/C++ is sufficient”—are stronger than the available evidence.

3.4 Comparative Analysis 2: Mathematical Proof and Assurance Levels in Ada/SPARK

The question in this section is not “Is Ada/SPARK safer than Rust?” but which properties each technology prevents, detects, or proves, at what stage and under what conditions, and where those guarantees end. To compare Ada/SPARK with the Safe Rust memory-safety contract established in Section 3.2, Ada’s types, run-time checks, and exception handling must not be collapsed together with SPARK’s restricted language subset, flow analysis, and proof into a single “safety level.”

The units of comparison must also remain separate. Safe Rust primarily prevents specified UB and data races through language rules within a sound safe interface. Ada provides strong typing, language-defined run-time checks, concurrency and synchronization constructs, and exception-handling mechanisms. SPARK places additional restrictions and contracts on an analyzable subset of Ada and uses GNATprove to progressively verify flow properties, absence of run-time errors, integrity properties, and functional contracts statically.51 These three models differ in the property being assured, the stage of assurance, the preconditions, and the cost.

Ada: Run-time detection and exception handling are not automatic recovery guarantees

Ada 2022 requires run-time checks for many language-defined conditions, including array indexes, scalar ranges, signed integer overflow, and null access; failure of a check raises an exception such as Constraint_Error. Signed-integer overflow is also distinct from the defined wraparound of modular integer types. When an exception is raised, the remainder of the current execution sequence is abandoned and control transfers to an applicable handler; if no handler applies locally, the exception propagates according to the language rules.52

This is an important defense layer that differs from unchecked memory access in C. But “the error is detected as an exception” and “the system recovers” are not the same guarantee. Whether a handler restores state safely, isolates only the failed request, restarts a task or process, preserves persistent-state consistency, or satisfies deadline and failover requirements must be assured by the program and system architecture separately. Ada’s exception mechanism provides a way to express and execute a recovery policy; it does not itself guarantee service availability or mission continuity.

Ada’s dynamic checking also has boundaries. Suppress can permit language-defined checks to be omitted, and if an execution reaches a situation in which a suppressed check would have failed, the standard can classify the execution as erroneous. Unchecked_Deallocation, Unchecked_Access, Unchecked_Conversion, and invalid access values or representations entering through external interfaces likewise create separate verification obligations.52 It is therefore inaccurate to summarize Ada as automatically guaranteeing the absence of every memory error.

SPARK: “Formal verification can be used” is different from “the whole program has been proved”

SPARK is not all of Ada; it is a language subset that restricts some features so that formal analysis is possible. The current SPARK User’s Guide distinguishes assurance levels as follows.51

Level Main verification objective Meaning in this section
Stone Check that the code belongs to valid SPARK Establishes the analyzable language boundary; does not mean program correctness
Bronze Initialization and correct data flow Statically eliminates uninitialized reads and specified parameter/global interference problems
Silver Absence of Run-Time Errors (AoRTE) Proves within the analyzed scope the absence of run-time errors that would cause unexpected exceptions such as Constraint_Error or assertion failures
Gold Prove key integrity properties Proves explicitly stated core safety or integrity properties such as invariants and state transitions
Platinum Formalize and prove functional requirements Proves that the implementation satisfies its specification to the extent that the contracts adequately express the functional requirements

Accordingly, the statement that “SPARK mathematically proves the absence of run-time errors” needs the condition that the analyzed scope and its proof obligations are actually closed. Silver AoRTE can prove absence of many run-time errors associated with Ada checks, such as division by zero, buffer or index errors, and overflow, but the official documentation explicitly excludes Storage_Error from SPARK analysis. Areas marked with Skip_Proof or SPARK_Mode => Off, external Ada/C/assembly code, imported data, and hardware models require separate assumptions or verification methods.53

Concurrency: absence of data races is different from absence of race conditions

Ada itself provides shared-state synchronization mechanisms such as protected objects and atomic or volatile objects, but it would be too strong to say that Ada automatically blocks every data race at run time. Ada 2022 permits tasks to read and write shared variables under language-defined rules that require appropriate synchronization, and defines semantics such as indivisible reads and updates for atomic objects.52

SPARK’s concurrent subset is narrower. Under the Ravenscar or Jorvik profiles, sharing between tasks is restricted to synchronized objects, and GNATprove can diagnose possible data races. Under Ravenscar on a single core, protected-object locking is constrained to use the Priority Ceiling Protocol to prevent deadlock, and GNATprove also checks potentially blocking actions inside protected subprograms and other tasking restrictions. Yet the official atomic-counter example shows that even without a data race, two tasks can read the same value and overwrite each other, creating a lost-update race condition. Protected operations or stronger protocol invariants are needed to prevent that class of error.54

Current GNATprove project-wide tasking analysis also has a scope limitation. The analysis uses the context of units directly or indirectly withed by the source file being processed, and the documentation notes that some tasking checks can therefore be missed when tasks in otherwise disconnected library units access the same resource.54 SPARK’s documented data-race and deadlock guarantees must therefore be read together with the supported profile, the single-core condition where it applies, and the actual GNATprove analysis context. The same distinction applies to Safe Rust in Section 3.2: preventing data races does not prove the absence of general concurrency defects such as TOCTOU errors, incorrect state transitions, deadlock, or starvation.

Proof boundaries: contracts, assumptions, and external systems

GNATprove’s modular proof assumes a callee’s contract while analyzing a caller and verifies that contract when analyzing the callee body. In real systems that are not analyzed entirely as SPARK, assumptions can remain about non-SPARK Ada, C, assembly, device registers, imported values, compiler behavior, and target behavior. SPARK documentation requires these residual assumptions to be managed through mechanisms such as --assumptions and separate review, and warns that assumptions such as pragma Assume can introduce errors into the verification process and therefore require careful justification.53

A proof result should therefore be interpreted together with at least what property was proved, what code scope was analyzed, what contracts served as the specification, what assumptions were trusted, and how the external environment and compiler/runtime/hardware were validated. A complete proof against an incorrect or incomplete specification is not the same as complete correctness with respect to the real requirements.

Comparison of assurance mechanisms

Property Safe Rust Ada SPARK Main boundary
Memory access and lifetime Statically prevents specified UB within a sound safe boundary Performs language-defined checks such as index/range/null-access checks but does not provide one blanket guarantee that all dangling-access lifetime errors are absent Can statically prove related AoRTE under its restricted pointer/aliasing model and proof obligations Rust unsafe/FFI, Ada suppressed or unchecked operations, code and assumptions outside SPARK
Array bounds Safe indexing panics on out-of-bounds access; unchecked access is an unsafe boundary An Index_Check failure raises an exception Can prove as a proof obligation that the check cannot fail Unproved code and external-input contracts
Integer overflow Follows the profile- and operation-specific semantics described in Section 3.2 and is separate from memory safety Signed integers raise an exception when the overflow check fails; modular integers have defined wraparound Can prove absence of overflow-check failure within the analyzed scope as AoRTE Storage_Error, separate resource bounds, and external arithmetic assumptions
Data races Prevented in sound Safe Rust Provides synchronization constructs but does not automatically detect or block every shared access Statically excludes data races in the supported concurrent subset General race conditions and protocol bugs remain separate
General concurrency correctness Does not generally guarantee absence of deadlock, livelock, starvation, or TOCTOU errors Provides protected/tasking mechanisms, but correct protocols remain a design responsibility Statically excludes data races in the supported subset, checks Ravenscar single-core deadlock-prevention constraints and protected/tasking rules, and can analyze explicitly stated invariants General races such as lost updates and liveness remain separate, and current project-wide tasking analysis has context-scope limits
Logical/integrity properties General functional correctness is separate except for invariants expressed by the type system Contracts can be expressed and checked dynamically Gold/Platinum can prove explicitly stated integrity and functional contracts Depends on specification completeness and assumptions
Recovery and availability Panic strategy and isolation/restart architecture are separate concerns Exception handlers can implement a response policy AoRTE can eliminate specified unexpected exceptions None automatically guarantees service recovery, redundancy, deadlines, or resource ceilings
Resource exhaustion Separate from memory/resource safety Storage_Error and similar conditions remain separate failure modes Storage_Error is outside SPARK analysis Requires separate invariants such as capacity planning, bounded allocation, and admission control

The important point is not to convert the columns of this table into a single score. Safe Rust’s strength is that it enforces specified memory-safety invariants as default constraints on ordinary code with relatively little specification annotation. Ada provides different defense layers through types, dynamic checks, exceptions, and tasking abstractions. SPARK accepts a more restricted language, explicit contracts, and proof effort in exchange for the ability to extend static proof beyond AoRTE to key integrity properties and functional requirements.

Performance, real-time, and lifecycle costs

Where the assurance mechanism is placed also affects performance and maintenance costs. Ada run-time checks provide detection during execution, so their time cost and effect on worst-case execution time must be evaluated for the target workload. Where SPARK AoRTE has actually been completed, the GNAT/SPARK workflow can use proof as a basis for producing executables with corresponding checks removed, but that does not mean that proof is free. The official documentation explains that proving large programs can take hours, that loop invariants, contracts, manual proof, and justification create maintenance costs, and that Platinum-level full functional proof is uncommon and usually applied to small scopes.51

For large-scale and extreme environments, the comparison must therefore include not only run-time overhead but also proof latency, CI resources, incremental-verification capability, the propagation of contract changes, the lifetime of external assumptions, toolchain qualification, worst-case timing, memory ceilings, and failure containment. Strong static proof can remove particular run-time-check costs, but it does not automatically solve resource exhaustion, hardware faults, incorrect requirements, or operational recovery.

Interim conclusion

The Ada/SPARK comparison does not show a simple safety ranking in which Rust occupies a point between C/C++ and SPARK. A more accurate conclusion is that safety assurance has multiple dimensions, and different languages address different parts of those dimensions at different costs.

Safe Rust has the strong advantage of preventing specified UB and data races by default within a sound safe boundary. Ada structures error detection and response through strong typing, language-defined run-time checks, exceptions, and synchronization mechanisms. SPARK can extend static proof to AoRTE, integrity properties, and functional contracts when an analyzable subset and explicit specification are provided. Conversely, SPARK proof does not automatically extend beyond Storage_Error, non-SPARK code, external systems and assumptions, or specification completeness.

Accordingly, all three statements—”Rust is safe if it compiles,” “Ada guarantees recovery because it has exceptions,” and “SPARK guarantees that the whole program is mathematically correct”—omit necessary conditions and are overly strong summaries. The comparison should concern not the language name but the property to be assured, the assurance scope, failure conditions, verification cost, run-time cost, and the proof obligations that remain at the system level.

3.5 Comparative Analysis 3: Reassessing Alternative Memory Management with GC

Rust’s memory-management approach is often compared with manual management in C/C++. The systems-programming spectrum, however, also includes languages such as Go, C#, and Java that obtain memory safety and productivity through garbage collection.

Some Rust-related discourse argues that GC languages are unsuitable for parts of systems programming because of stop-the-world pauses and runtime overhead. Such claims may describe older collectors, but may fail to reflect the characteristics of more recent GC technology.

Collectors in mainstream languages now use techniques such as generational, concurrent, and parallel GC to manage memory while minimizing application interruption. For example, the Go collector is designed with microsecond-scale pauses as a goal and is used in network servers and cloud infrastructure. Java collectors such as ZGC and Shenandoah target millisecond-scale pauses even with large heaps.

Rust ownership and garbage collection can be understood as different design philosophies about where costs are paid.

  • Rust’s approach: It minimizes runtime cost by moving part of that cost to compilation and to developers’ cognitive burden—the learning curve and borrow checker—thus paying in development time.
  • The GC-language approach: It reduces developers’ cognitive burden and development time, but pays at runtime in CPU and memory resources—that is, machine time.

There are domains where garbage collection is constrained, including resource-limited embedded systems and hard real-time operating systems. Generalizing those specific requirements to judge the practicality of every GC-based language, however, may ignore the requirements of diverse business environments. In some commercial settings, development speed and time to market matter more than maximum runtime performance; there, a GC language may be a reasonable choice.

3.6 Discourse Analysis: Redefining “Practicality” and “Responsibility”

The preceding sections, 3.1–3.5, analyzed Rust’s safety model technically and historically and compared it with other approaches including C++, Ada/SPARK, and GC languages. They also addressed Rust’s conceptual precedents (3.1) and technical limits (3.2).

Section 3.6 shifts the focus from technical facts to technical discourse: how those facts are communicated and interpreted within the Rust ecosystem, and how the central safety narrative is maintained and defended.

It first examines how the meaning of innovation is redefined as practicality (3.6.1), then how responsibility is assigned for technical limits such as memory leaks and bugs in unsafe code (3.6.2).

3.6.1 The Discursive Function of “Practical Innovation”

Section 3.1 analyzed how Rust’s central concepts build on antecedents in C++, Ada, and other languages. In response, one claim is that Rust’s innovation lies not in inventing concepts but in the democratization of value, or in practical innovation.

The reasoning is as follows. Ada/SPARK’s safety without a GC demanded high costs in specialized domains such as aerospace and defense—learning curves, specialist tools, and development speed—and therefore did not spread among ordinary developers. Rust, by contrast, is said to have carried these concepts into general systems programming through its tool ecosystem, including Cargo, and through its community. On this account, technology usable by many has greater engineering significance than technology used by only a few.

The point analyzed here is how the claim of practical innovation operates within technical discourse. When used as an answer to a critical question about the absence of conceptual originality, it tends to function as a rhetorical tool.

Answering the question “Is A conceptually new?” with “A is used in the market and is practical” may not answer the original question directly. It changes the category of discussion from the origin of the concept to its practical utility, and can thus be understood as a topic shift.

This logical shift can lead to discourse that uses Rust’s practical achievements to imply conceptual uniqueness. One effect may be that the historical and engineering results of languages such as Ada and C++ are undervalued or excluded from discussion. The idea of practical innovation explains Rust’s achievements, but can simultaneously perform the discursive function of avoiding critical examination of what “innovation” originally means.

3.6.2 Assigning “Responsibility”: How Memory Leaks and unsafe Are Discussed

When Rust’s technical limits (Section 3.2) are discussed, the assignment of responsibility for those problems often follows a particular discursive pattern. This can be analyzed as a logical boundary-setting practice that preserves the language’s central concept of safety.

1. Memory leaks: separating responsibility through the definition of safety

As analyzed in Section 3.2.4, memory leaks can occur in safe Rust code through mechanisms such as reference cycles.

When this technical fact is presented as criticism of Rust’s memory safety, discourse often refers to the technical definition in Section 3.2.1: safety means preventing UB. Because a memory leak does not cause undefined behavior, the reasoning goes, it is not unsafe behavior and therefore falls outside the compiler’s safety guarantee.

This approach separates memory problems into those that cause UB and safe logical problems that do not, such as leaks. Responsibility for preventing leaks is consequently transferred from the compiler’s guarantee domain to the developer’s logical-responsibility domain. This differs from C/C++ communities, where memory management is treated more broadly as the developer’s responsibility.

2. Bugs in unsafe: isolating responsibility at the unsafe boundary

As explained in Section 3.2.2, code inside an unsafe block bypasses some compiler safety checks, and defects there can undermine even code written in Safe Rust.

When a memory error arises in a library’s unsafe code, discourse tends to emphasize that the guarantee of Safe Rust itself did not fail. Responsibility is assigned not to the Safe Rust model, but to the developer who wrote the unsafe code.

The unsafe keyword both marks a particular region of code as requiring trust and isolates responsibility for problems arising in that region to the developer. This contrasts with the way a library defect in C/C++ may be interpreted as an expression of an inherent risk in the language itself.

Taken together, these two modes of discussion operate as mechanisms that preserve Rust’s central proposition that Safe Rust guarantees memory safety. By (1) limiting the definition of safety to prevention of UB and (2) separating responsibility through the explicit unsafe boundary, discourse maintains the central narrative that the Safe Rust guarantee remains valid despite real problems in the ecosystem such as memory leaks and bugs in unsafe implementations.

3.7 Conclusion: Trade-offs Among Performance, Safety, and Productivity

In software engineering, a single tool rarely satisfies every requirement. The same applies to programming-language design. Engineering design generally consists of balancing trade-offs among multiple objectives.

Programming languages are commonly shaped around three broad factors: performance and memory control, development productivity, and compiler-level safety. Each language and ecosystem selects a different point among these factors and therefore has different strengths and costs.

  • C/C++: Prioritize hardware control and execution performance. Developers directly carry responsibilities including memory management (Section 3.3), while safety depends on external tools and discipline.
  • Go and Java/C#: Emphasize development productivity through garbage collection and runtimes (Section 3.5), paying for this design with runtime overhead.
  • Ada/SPARK: Aim for the highest levels of mathematically provable safety and correctness (Section 3.4), requiring high development cost and specialist expertise.
  • Rust: Aims to combine performance comparable to C++ with memory safety—prevention of UB—without a GC (Section 3.2). Instead of runtime cost, it requires development-time and cognitive costs as developers learn and apply the ownership and borrow-checker model.

Because of these design differences, languages may fit different development scenarios. A web-service backend may choose Go for productivity, an aircraft-control system may choose SPARK for provable assurance, and a system constrained from using a GC may choose Rust’s model.

Safety, in conclusion, is not a single property but a multilayered spectrum, as illustrated by the table in Section 3.4. Every language has features and costs associated with its own design objectives. The engineering approach is therefore to analyze the constraints and requirements of the problem domain and select a tool suited to them.

4. Reassessing the Ownership Model and Its Design Philosophy

Section 4.1 first traces the concept to C++ RAII and smart pointers. Section 4.2 then analyzes Rust’s distinct contribution as the compiler’s conversion of a selective C++ pattern into an enforced rule. Finally, Section 4.3 compares the model with Ada/SPARK’s Design by Contract and examines the trade-offs ownership introduces when implementing certain data structures.

4.1 Origins of Ownership: C++ RAII and Smart Pointers

To understand the historical background of Rust’s ownership model, it is useful to examine how resource management evolved in C and C++.

Manual memory management in C and its limitations

C gives programmers control over dynamic memory through malloc() and free(). This design provides flexibility and performance, but makes the programmer responsible for freeing every allocation exactly once at the appropriate time.

When mistakes occur, this manual model can cause the following memory errors.

  • Memory leak: Allocated memory is not released, reducing available memory.
  • Double free: Already released memory is freed again, corrupting the allocator’s state.
  • Use after free: Code accesses released memory, potentially causing data corruption or a security vulnerability.

Because of these problems, C++ explored paradigms for managing resources systematically rather than relying only on individual programmer responsibility.

The evolution of C++: RAII and smart pointers

C++ introduced RAII (Resource Acquisition Is Initialization) to transfer responsibility for resource management from the individual programmer to the language’s object-lifetime rules. Under RAII, a resource is acquired in an object’s constructor and released in its destructor. Because the C++ compiler guarantees destructor invocation when an object leaves scope—including normal return and exception unwinding—omitted cleanup can be prevented.

Smart pointers apply RAII to dynamic-memory management. Smart pointers standardized since C++11 show similarities to Rust’s ownership model.

  • std::unique_ptr (unique ownership): Expresses exclusive ownership of a resource. Copying is prohibited and only transfer by move is allowed, connecting directly to Rust’s default ownership model and move semantics.
  • std::shared_ptr (shared ownership): Uses reference counting to let several pointers jointly own one resource. This is the conceptual basis for Rust’s Rc<T> and Arc<T>.

Through RAII and smart pointers, C++ established the idea of resource ownership and practical mechanisms for handling it.

4.2 Rust’s Ownership Model: Compiler Enforcement Rather Than Invention of a Concept

Section 4.1 analyzed the connection between Rust ownership and C++ RAII and smart pointers. Rust’s distinctive characteristic lies not in inventing the idea itself, but in how it enforces existing ownership principles at the language level.

From an optional pattern to a mandatory rule

In C++, using a smart pointer such as std::unique_ptr is a design pattern and remains the developer’s choice. Developers may disregard the pattern and use raw pointers, and the compiler does not prohibit this. Responsibility for safety remains with the developer.

Rust, by contrast, embeds ownership not as an optional pattern but as a mandatory rule in the type system. Every value follows these rules, and the static-analysis component called the borrow checker verifies compliance at compile time. Unless an unsafe block is used, violations become compilation errors and prevent the program from being built.

This design differs from C++ by transferring the primary agent of safety assurance from the developer to compiler static analysis. At the same time, it is necessary to consider how dependence on that tool affects runtime safety practices.

In C environments, awareness of code’s potential danger tends to encourage defensive programming. Confidence in compiler safety guarantees, by contrast, can reduce defensive attention to runtime logical errors or exceptional conditions. Choosing unwrap() instead of explicitly handling a Result, for example, may be interpreted as prioritizing convenience on the basis of the language’s safety net.

Trade-offs from the perspective of experienced developers

For C/C++ developers, compiler enforcement has two sides: usefulness and constraint.

Some C/C++ developers may recognize that Rust ownership rules align with established best practices.

  • Rust move semantics resemble the ownership-transfer pattern using C++ std::unique_ptr and std::move.
  • Rust immutable references (&T) and mutable references (&mut T) share context with C++ design principles that use const T& to preserve immutability or prevent concurrent mutation.

In this sense, Rust can be evaluated as a tool that makes the compiler explicitly enforce previously implicit discipline.

Enforcement can also become a limitation. When implementing certain data structures or performing performance optimization, developers may use memory-management patterns beyond the borrow checker’s analytical capability. Because the checker cannot prove every valid program, logically safe code can be rejected merely because the compiler cannot prove it.

Rust’s ownership model therefore raises the safety level through enforcement, but its philosophy of prioritizing fixed rules also contains a trade-off that can constrain development flexibility in particular situations.

4.3 Comparing Design Philosophies: Ownership and Design by Contract

Programming languages adopt different philosophies for assuring correctness. Rust’s ownership and borrowing model focuses on automatically preventing certain error classes at compile time. Design by Contract, as used in Ada/SPARK, instead has tools verify logical contracts explicitly supplied by developers.

To compare these philosophies and their engineering trade-offs, this section uses implementation of the doubly linked list as a case study.

1. Approach 1: Rust’s ownership model

In a doubly linked list, each node refers to both its previous and next nodes. In languages where this can be implemented directly with pointers or references, the structure conflicts with Rust’s default rules because the ownership system normally disallows reference cycles and multiple mutable references to the same data.

A node definition that tries to express this structure directly with references is therefore rejected by the borrow checker as a compilation error.

// Code that does not compile
struct Node<'a> {
    value: i32,
    prev: Option<&'a Node<'a>>,
    next: Option<&'a Node<'a>>,
}

To solve the constraint within safe Rust, developers must combine specific language mechanisms: Rc<T> for shared ownership, RefCell<T> for interior mutability, and Weak<T> to break reference cycles.

// Example implementation using Rc, RefCell, and Weak
use std::rc::{Rc, Weak};
use std::cell::RefCell;

type Link<T> = Option<Rc<Node<T>>>;

struct Node<T> {
    value: T,
    next: RefCell<Link<T>>,
    prev: RefCell<Option<Weak<Node<T>>>>,
}
  • Analysis: This approach has the advantage that the compiler automatically prevents certain concurrency problems such as data races. Ownership rules enforce specific memory-safety constraints, and where shared state is needed—as in a doubly linked list—they lead developers to handle that state explicitly with Rc, RefCell, and related mechanisms. The cognitive cost and verbosity introduced by this process are the price of the design philosophy. A developer’s attention may shift from the problem’s logical structure toward satisfying compiler rules.

2. Approach 2: Ada/SPARK pointers and Design by Contract

Ada supports pointer-like access through access types and can express the structure of a doubly linked list.

-- Representation in Ada
type Node;
type Node_Access is access all Node;
type Node is record
  value : Integer;
  prev  : Node_Access;
  next  : Node_Access;
end record;

By default, Ada checks errors such as dereferencing a null access value at runtime and raises Constraint_Error, thereby providing safety.

SPARK goes further and uses Design by Contract to provide a way to prove mathematically at compile time that runtime errors are absent. Developers state preconditions (Pre) and postconditions (Post) on procedures or functions, and static-analysis tools verify that the implementation always satisfies those contracts.

-- Example of proving safety with a SPARK contract
procedure Process_Node (Item : in Node_Access)
  with Pre => Item /= null; -- State the contract that Item is not null
  • Analysis: This approach lets developers express data structures through a pointer model similar to C/C++. Safety is established through runtime checks or through explicit contracts written by the developer and proofs generated by static-analysis tools. The cost of this philosophy is the responsibility and effort required to consider every potential error path and formalize it as a contract. If contracts are omitted or written incorrectly, assurance can be incomplete, creating a different kind of risk from an approach based on automatic rules.

3. Comparison and conclusion

The two approaches distribute responsibility and cost for software correctness to different actors and stages.

Dimension Rust Ada/SPARK
Agent providing safety Compiler (automatic enforcement of implicit rules) Developer + tools (explicit contracts and static proof)
Default paradigm Restrictive by default, with opt-in complexity Permissive by default, constrained through opt-in safety proofs
Primary cost Cognitive overhead and code complexity when implementing certain patterns Need to write a formal specification for interactions
Primary benefit Automatic prevention of specific error classes such as data races Direct expression of developer design intent and proof of broad logical properties

Rust’s ownership model is therefore better analyzed not through a binary judgment of innovation or defect, but as a design philosophy with benefits and corresponding costs. It prevents particular bug classes while requiring learning investment and particular solution patterns from developers. Its suitability depends on the kind of problem being solved, the team’s capabilities, and the values prioritized by the project, such as automated safety assurance versus design flexibility.

Part 3: Ecosystem Reality and Structural Costs

Part 3 analyzes practical challenges facing the Rust ecosystem and the structural costs behind them. When evaluating Rust’s developer experience, the principle of zero-cost abstractions, and constraints on industrial adoption, it is useful to distinguish two kinds of problem.

  1. Problems of maturity: Shortages of libraries, instability in some tools, incomplete documentation, and similar issues may naturally be resolved or mitigated as time and community effort accumulate. These are maturity problems shared by growing technology ecosystems.

  2. Inherent design trade-offs: These arise when a language deliberately sacrifices one value—ease of learning, compilation speed, or flexibility in implementing particular patterns—to achieve central values such as runtime performance and memory safety without a GC. Because they are choices rather than defects, they are unlikely to disappear simply with time.

Using this framework, the following chapters distinguish and evaluate the nature of Rust’s various technical challenges.

5. Achievements and Costs of Developer Experience

Chapter 5 analyzes multiple aspects of the developer experience of using Rust and the costs that accompany them.

The discussion begins with how the borrow checker and learning curve affect productivity (5.1), then considers the tendency to generalize technical choices (5.2). It next examines complexity and trade-offs in concrete areas such as asynchronous programming (5.3) and the error-handling model (5.4). Finally, it concludes the developer-experience discussion by analyzing challenges in the library ecosystem (5.5) and development toolchain (5.6 and 5.7).

5.1 The Borrow Checker, Learning Curve, and Productivity Trade-offs

The central mechanism implementing Rust’s safety model is the borrow checker, which statically enforces ownership, borrowing, and lifetime rules at compile time. Its strictness creates a trade-off with development productivity. Developers accustomed to other paradigms must restructure existing approaches to fit Rust’s model, producing a learning curve.

Both sides of the trade-off: learning cost and safety

The rules imposed by the borrow checker create cognitive costs during development, while also preventing certain runtime errors at their source.

  1. Costs and benefits of ownership and borrowing: Developers must apply the single-owner rule to every value and follow immutable or mutable borrowing rules when accessing data. This can require effort beyond implementing the program’s logic solely to satisfy compiler rules. In return, the compiler prevents concurrency problems such as data races at compile time and eliminates the possibility of memory errors such as use after free.

  2. Costs and benefits of explicit lifetimes: When the compiler cannot infer reference validity automatically, developers must state lifetime parameters such as 'a directly. This requires additional abstract reasoning to satisfy static analysis. The explicit notation, however, enables the compiler to verify and block references to invalid memory, such as dangling pointers.

  3. Constraints and alternatives for particular design patterns: The borrow checker’s analytical model makes structures such as doubly linked lists and graphs requiring reference cycles difficult to implement using only default rules. This demonstrates a limit in the range of programs expressible by the borrow-checker model. In such cases, developers can use Rc<T>, RefCell<T>, or unsafe blocks to handle exceptions explicitly and implement the desired structure.

Effects on productivity and related discourse

These technical characteristics affect project productivity. When new members join a team, adaptation time and training costs may arise, reducing initial productivity. Feature implementation may be delayed while compilation errors are resolved, reducing schedule predictability. In business environments where development time is a resource, these effects constitute cost and risk.

The learning curve is part of the design trade-off selected to achieve safety without runtime-performance loss. In some online discussion, the difficulty of learning Rust is reinterpreted as a means of strengthening developer capability or as an indicator of expertise. Critics argue that reducing the difficulty of the learning process to an individual’s competence can create an entry barrier for new developers and restrict discussion of improving tool usability.

5.2 The Tendency to Generalize Technology Choices and Their Engineering Trade-offs

When a new technology appears, people often try to extend its application beyond its original purpose. This phenomenon, known as the law of the instrument, can be understood as a general social and psychological dynamic in technology adoption.

Rust provides a case study for analyzing this tendency. The value of memory safety and the learning time required to master it lead developers to invest substantial effort in the technology. That investment can encourage attempts to extend its use beyond a particular domain into broader areas.

This section analyzes two ways this generalization appears in Rust-related discussion. First, it examines the tendency to use Rust’s principal characteristics—such as absence of a GC and runtime performance—as exclusive criteria when evaluating other languages. Second, through ordinary web-application development, it examines how trade-off analysis changes when the problem’s characteristics and constraints are taken into account.

Bias in comparison with other technologies

Generalizing a technology choice can introduce particular biases into comparisons with other programming languages.

Rust’s memory safety without a GC and high runtime performance are sometimes applied as the primary criteria for evaluating technology. Under this perspective, other languages may be judged as follows.

  • C/C++: The absence of enforced memory safety becomes the principal basis of evaluation, outweighing ecosystem, hardware control, and other dimensions.
  • Go, Java, and C#: The existence of a GC is analyzed mainly as a possible source of performance loss, while their development productivity and ecosystem value may be undervalued.
  • Python and JavaScript: The absence of a static type system is presented as a basis for stability concerns, while rapid prototyping and development speed are treated as secondary.

Engineering evaluation considers a broad collection of trade-offs. Selectively emphasizing one criterion can limit evaluation of how each technology fits different problem domains.

Case study: generalization in web-backend development

One example is the argument for applying Rust broadly to web-backend development.

Rust can be a reasonable option for particular web-service domains requiring high throughput and low latency, including API gateways and real-time communication servers. Memory safety may also improve server stability.

But extending requirements from those domains to other forms of web backend is a generalization. In many ordinary web applications—SaaS, internal management systems, and commerce platforms—business and engineering factors beyond performance matter as well.

  • Development speed and time to market
  • Ecosystem maturity, including completeness of authentication, payment, and ORM libraries
  • Ease of training new staff and size of the developer labor pool

By these measures, languages with established ecosystems such as Go, C#/.NET, Java/Spring, and Python/Django may be suitable choices. Claiming an overly broad scope for a particular technology without considering the problem and business constraints can therefore neglect engineering trade-off analysis.

5.3 Complexity and Engineering Trade-offs of the Asynchronous Programming Model

Rust’s asynchronous model, async/await, is designed around zero-cost abstractions to obtain runtime performance without a garbage collector or green threads. These goals originate in systems programming built on operating-system threads.

The design choice, however, imposes costs on developers: conceptual complexity, ecosystem fragmentation, and interoperability constraints.

Sources of technical complexity

Rust’s async/await works by having the compiler transform asynchronous code into a state machine. This process can create self-referential structures that contain references to their own location in memory. Rust therefore introduced the Pin<T> pointer type to guarantee address stability for such structures.

Pin<T> and related concepts such as generators are abstract mechanisms rarely encountered in other mainstream languages and require study to understand. This complexity can be viewed as a form of leaky abstraction. Developers within Rust’s asynchronous ecosystem have themselves discussed the learning curve in blogs and talks and called for usability improvements.55

Runtime fragmentation and dependency coupling

Rust deliberately omits a specific asynchronous executor from the standard library. This decision supports flexibility across environments including resource-constrained no_std targets, but has produced the structural challenge of runtime fragmentation in practice.

In the absence of a standard runtime, tokio has become the ecosystem’s de facto standard. Network and database client libraries such as reqwest and sqlx are consequently coupled strongly to particular runtime implementations. To use an external library, developers may need to align the entire project’s asynchronous runtime with Tokio, losing compatibility with alternatives such as async-std and smol. Concentrating ecosystem infrastructure in a single third-party library while a complete language-level standard remains absent carries long-term structural risk.

Limits of external interoperability: asynchronous FFI

The isolation is also visible in interoperability with other languages. One of Rust’s important strengths is smooth FFI through the C ABI, but this largely applies to synchronous code.

Rust’s Future type and state-machine model do not map directly onto the system-standard C ABI. Integrating a high-performance asynchronous Rust module with event loops in C, Python, or Go—for example, those based on epoll or kqueue—therefore requires substantial engineering effort. Developers must either block a runtime synchronously or manually build complex callback wrappers to communicate with other languages. This is a fundamental barrier for industrial requirements involving legacy-system integration and polyglot architectures.

Practical effects on development experience

The internal complexity of the async model causes the following difficulties in development and maintenance.

  1. Harder debugging: Stack traces from failures in async code often consist of runtime internals and compiler-generated state-machine calls, making the root cause difficult to trace. Unlike synchronous functions, local variables of async functions are captured inside the state-machine object, complicating inspection with a debugger.
  2. Cost shifting: Rust’s async model minimizes runtime CPU and memory use—machine time—by shifting costs toward resolving runtime fragmentation, integrating other languages, and difficult debugging—developer time.

Comparison with alternative models

The trade-off becomes clearer when compared with alternative concurrency models such as Go goroutines. Goroutines are lightweight green threads managed by the language runtime and provide developers with a simplified concurrency model.

Dimension Rust async/await Go goroutines
Design objective Zero runtime overhead Development productivity and simplicity
Runtime cost Minimized Scheduler and GC costs exist
Ecosystem integration Low (third-party dependency and fragmentation, such as Tokio) High (standardized within the language)
Learning curve High (concepts such as Pin) Low (go keyword)
Debugging Difficult (complex stack traces) Easier (clearer stack traces)

Rust’s model may provide performance advantages for CPU-bound work. In ordinary I/O-bound workloads where network or database latency dominates, however, the ecosystem fragmentation and debugging complexity required by Rust may cost more than the runtime overhead accepted by Go.

Some Rust-community discussion undervalues the Go model because it is not zero cost. That approach evaluates technology using only runtime performance and can overlook other engineering values including interoperability, development productivity, and maintainability.

5.4 Reconsidering the Practicality of Explicit Error Handling with Result<T, E>

Rust uses an explicit error-handling model based on the Result<T, E> enum, pattern matching, and the ? operator, enforcing attention to errors at compile time. The model helps prevent omitted error handling. To evaluate its practicality, this section compares alternative error models, examines the concept’s historical origin, and analyzes costs in actual use.

1. Comparison with an alternative model: try-catch exceptions

When Rust’s Result model is discussed, try-catch exception handling is often criticized for unpredictable control flow. Exception mechanisms, however, have the following engineering characteristics.

  • Separation of concerns: Normal logic can be written in a try block and exceptional handling separately in a catch block. Control moves immediately from the failure point to the handling point, avoiding manual propagation such as return Err(...) through several function layers.
  • Compile-time checking: The criticism that “one cannot know which exception may occur” does not apply universally. Java checked exceptions, for example, require functions to declare exceptions in their signatures and force callers to handle them at compile time. This achieves the goal of preventing omitted error handling through a mechanism different from Result.
  • System resilience: Exception systems support continued operation by combining error logging, resource cleanup through finally, and recovery logic rather than allowing abnormal program termination.

2. Historical origin of the concept: functional programming

Explicit error and state handling through Result and Option is not unique to Rust; it adopts an existing concept rooted in functional programming.

For decades, Haskell types such as Maybe a and Either a b, along with sum types in ML-family languages such as OCaml and F#, have represented absence and error states in the type system and required compilers to ensure that all cases are handled.

Rust’s contribution can therefore be analyzed less as invention and more as reinterpretation for systems programming and popularization through syntactic conveniences such as the ? operator.

3. Practical cost: verbosity in converting error types

The ? operator works naturally when propagating one error type, but real applications often use external libraries returning distinct types such as std::io::Error and sqlx::Error. Developers must repeatedly write boilerplate to convert them into a single application error type.

// Converting several error kinds into one application error type
fn load_config_and_user(id: Uuid) -> Result<Config, MyAppError> {
    let file_content = fs::read_to_string("config.toml")
        .map_err(MyAppError::Io)?; // std::io::Error -> MyAppError

    let config: Config = toml::from_str(&file_content)
        .map_err(MyAppError::Toml)?; // toml::de::Error -> MyAppError

    // ...
    Ok(config)
}

External crates such as anyhow and thiserror are used to reduce this repetitive conversion. The fact that third-party libraries are treated almost as standard for flexible error handling suggests that practical application development requires capabilities beyond the language’s basic facilities.

4. Case study: the Cloudflare outage and use of unwrap()

How Rust’s error-handling model behaves in production can be examined through the Cloudflare service outage of November 2025.56 The incident involved a function returning Result whose error case was not handled with match or ?; instead, unwrap() caused a panic.

Rust uses Result to require explicit consideration of errors, but also provides unwrap() as an escape from that requirement. Although unwrap() is intended mainly for prototypes and tests, production code may use it to avoid the cost of implementing complex error-handling logic.

The case suggests that language enforcement cannot completely remove choices that prioritize developer convenience. Even when the compiler enforces rules, selecting an escape hatch such as unwrap() can turn convenience into a system outage. It illustrates a limitation arising when Rust’s model of enforced safety meets human factors in actual engineering practice.

5.5 Qualitative Maturity Challenges in the Rust Ecosystem and Community Discourse

Cargo and Crates.io have supported Rust’s rapid adoption and growth, producing quantitative expansion in shared libraries, or crates. Behind that growth, however, lies the qualitative challenge of obtaining stability and trustworthiness in production. This section analyzes major quality challenges in the ecosystem and characteristic discourse patterns in community responses.

1. Major challenges in the qualitative maturity of the crate ecosystem

Developers using Rust in production may encounter the following practical library-ecosystem problems.

  • Insufficient API stability: Many crates remain on 0.x versions below semantic-versioning 1.0.0 for long periods. This signals that the public API is not considered stable and that breaking changes may occur without backward compatibility. For projects with production dependencies, it increases potential maintenance cost and risk.
  • Variation in documentation: Although cargo doc can generate standardized API documentation, the actual quality of crate documentation varies greatly. Some crates provide little beyond an API list, omitting concrete examples or explanations of design philosophy and forcing developers to inspect source code before using the library. This can undermine the productivity benefit libraries are intended to provide.
  • Continuity of maintenance: As in many open-source ecosystems, even important crates may be maintained by a small number of volunteers. If a principal maintainer stops work for personal reasons, responses to security vulnerabilities or major defects can be delayed for long periods, affecting the stability of the broader ecosystem that depends on the crate.

2. Criticism of ecosystem problems and observed response patterns

When qualitative ecosystem problems are criticized, public discussion spaces such as online forums sometimes display discourse patterns that redirect attention away from the technical substance of the issue.

  • Shifting responsibility through calls for participation: Responses such as “Pull requests are welcome” or “contribute it yourself if you need it” encourage voluntary participation, an important open-source value. When used as answers to criticism of defects or missing documentation, however, they can rhetorically transfer responsibility for solving the problem to the person who reported it. Since not every user has the expertise or time to modify a library, such reactions can suppress the feedback cycle.
  • Representativeness of success stories and statistical perspective: Criticism of ecosystem-wide maturity is sometimes countered with a few well-maintained core crates such as tokio and serde. These examples meaningfully demonstrate Rust’s potential and the quality level the ecosystem can attain. But the argument should be examined in terms of sample representativeness. A small number of successful cases cannot necessarily represent average maturity across thousands of libraries or the conditions an ordinary developer encounters. Rather than merely naming a logical fallacy, this is an engineering and statistical question: is the selected sample sufficient to describe the population? Restricting discussion to a few top cases can obscure problems faced by individual libraries and overestimate the ecosystem’s present state.

5.6 Technical Challenges in the Development Toolchain and Productivity

Rust’s developer experience combines useful capabilities with several technical challenges that can affect productivity in large projects. This section analyzes compiler resource consumption, IDE integration and debugging, and build-system flexibility.

5.6.1 Compiler Resource Use and Its Effects

The Rust compiler, rustc, tends to require substantial time and memory. This arises partly from language design, including monomorphization used to implement zero-cost abstractions and dependence on the LLVM backend.

  • Compilation time: Monomorphization generates code for each generic type, increasing the amount of code the compiler must process and optimize. It delays the development feedback loop from edit to compile to test, and can reduce productivity as projects grow. Tools such as cargo check provide fast checking, but complete builds and tests can still take significant time.
  • Memory consumption: Compiler memory use can cause problems in resource-limited environments such as personal laptops and low-capacity CI/CD workers. In large projects, compiler processes may exceed available memory and be terminated by the operating system’s OOM killer, reducing the stability of the development experience.

These costs are not fixed. The Rust project and community recognize compilation speed as an improvement area. Work on the Cranelift backend for faster debug builds and efforts to improve parallelism within rustc demonstrate active management of the trade-off.

5.6.2 IDE Integration and Debugging: Costs Behind the Abstraction

IDE integration and debugging illustrate how Rust’s design philosophy imposes costs in developers’ daily work. Rust has a language server and support for standard debuggers, but the complexity of its abstractions can create cognitive burden and lost productivity.

Reality and limitations of the language server (rust-analyzer)

The rust-analyzer language server analyzes Rust’s complex type system and macro facilities in real time, providing completion, type inference, and diagnostics. It is widely regarded as an important productivity tool.

The depth of that analysis is also its cost. rust-analyzer keeps project code and dependencies resident in memory and recomputes complex trait resolution and macro expansion after edits. This can cause the following problems.

  • Resource consumption: In a large project, the rust-analyzer process itself may consume several gigabytes of memory, burdening resource-limited development machines.
  • Unstable analysis: With complex generic types or procedural macros, type inference may fail or diagnostics may be inaccurate, causing developers to rely on the compiler’s final diagnostics rather than trusting the language server.

This is not necessarily a defect in rust-analyzer alone, but a limit of performing compiler-like work in real time and evidence of the language’s complexity.

The trade-off between abstraction and debugging

Rust’s zero-cost-abstraction principle can charge its cost to developers during debugging. Although LLDB and GDB are available, debugging abstract Rust types differs from integrated experiences in other languages.

For example, inspecting a Vec<String> in a Java or C# IDE may show values directly as ["hello", "world"]. A Rust debugger may instead expose the fields of the Vec: a pointer to heap memory, capacity, and current length.

Developers must then interpret a low-level memory representation to understand the logical state of the program. The abstraction’s removed runtime cost appears as reduced debugging convenience and additional cognitive load.

Debugging asynchronous code

The issue is especially visible when debugging async/await. As Section 5.3 described, the compiler transforms async functions into state machines, making conventional stack-based debugging difficult.

Even when execution stops at the failure point and the call stack is inspected, the logical path in which developer-written function_a called function_b may be absent. Instead, the trace may show scheduler internals from an asynchronous runtime such as Tokio and compiler-generated state-machine poll calls that developers must interpret. It can therefore be difficult to answer, “How did this code reach this point?”

This contrasts with environments such as Visual Studio for C# and IntelliJ IDEA for Java, which reconstruct and display logical asynchronous call stacks. Rust’s async debugging illustrates how a philosophy that minimizes runtime overhead can produce complexity costs during development and maintenance.

5.6.3 Flexibility of the Cargo Build System

Cargo, Rust’s official build system, improves productivity through standardized project management, dependency resolution, and a convention-over-configuration philosophy. These are important strengths.

The same characteristics can become rigid when a project departs from standard requirements. For nonstandard procedures such as complex code generation or specialized integration with external libraries, build.rs scripts may not provide sufficient flexibility. In large monorepos, combinations of feature flags can also become complex and make dependency management a separate maintenance cost. This can constrain large industrial environments that must support diverse build scenarios.

These factors show that Rust’s developer experience provides real benefits together with technical challenges. Rather than evaluating a development environment in isolation, it is more useful to understand it as a result of design choices. The next section moves beyond assigning one philosophy to each ecosystem. It compares both separated toolchains and integrated experiences while also considering ecosystem maturity.

5.7 Comparing Development Environments: Where Maturity Meets Design Philosophy

The previous section analyzed technical challenges in Rust’s development environment. Such analysis can slip into a binary comparison between “integrated Java/C# IDEs” and “Rust in VS Code,” overlooking that both ecosystems offer both a separated toolchain and an integrated experience.

The comparison should therefore place the two philosophies side by side and consider ecosystem maturity as an additional variable.

1. First comparison: separated toolchain environments such as VS Code

The Language Server Protocol enables multiple languages to receive similar support in editors such as Visual Studio Code. Under these conditions, the ecosystems differ as follows.

  • Java/C#: Eclipse JDT LS, Red Hat’s Java extensions, and the Roslyn LSP for C# have gained stability and maturity through years of development and corporate support. They provide completion, diagnostics, and refactoring for enterprise projects.
  • Rust: rust-analyzer has contributed substantially to ecosystem growth. As Section 5.6 explained, however, language complexity including macros and trait resolution still creates stability and resource-consumption challenges.
  • Analysis: Under the same separated-toolchain conditions, Java/C# language servers have matured on top of longer histories and relatively stable specifications. rust-analyzer continues to solve language-specific challenges. This does not prove the superiority of one side; it demonstrates differences in historical paths and technical problems.

2. Second comparison: integrated environments in specialized IDEs

Both ecosystems also provide integrated environments beyond baseline LSP functionality.

  • Java/C#: IntelliJ IDEA and Visual Studio use accumulated experience to provide project intelligence in addition to code analysis. Their semantic refactoring, debugging, and profiling capabilities are why they function as development platforms, and demonstrate maturity in the integrated philosophy.
  • Rust: JetBrains RustRover and CLion demonstrate that Rust developers also have an integrated option. These IDEs attempt to provide debugger integration and refactoring through their own analysis engines in addition to rust-analyzer, representing progress in Rust’s developer experience.
  • Analysis: A maturity gap remains. Compared with IntelliJ’s Java support, RustRover is at an earlier stage. Reproducing decades of Java refactoring and debugging functionality in a short period is difficult. This is better interpreted as a stage experienced by a growing technology than as an intrinsic technical limitation of Rust.

3. Conclusion: reconstructing the comparison frame

Directly comparing an integrated Java/C# IDE with Rust in VS Code creates an asymmetric frame by crossing the mature portion of one ecosystem with the popular portion of another.

The comparison supports the following conclusions.

  1. Both ecosystems offer development environments following both philosophies.
  2. In both separated-toolchain and integrated-experience environments, the Java/C# ecosystem displays maturity obtained through time and investment.
  3. Rust’s development environment continues to improve but faces maturity challenges arising from language complexity and a shorter ecosystem history.

It is therefore difficult to reduce the difference to one ecosystem’s dependency or to the superiority of a philosophy. The principal difference is the stage of maturity each has reached. Java/C# has achieved completeness in integrated and separated approaches through time and investment; Rust is growing while addressing the complexity of its language. Engineering evaluation should begin from that reality and select the tools and philosophy that fit the project’s requirements.

6. Analyzing the Real Costs of “Zero-Cost Abstractions”

Chapter 6 analyzes the real costs accompanying Rust’s principle of zero-cost abstractions (ZCA).

Section 6.1 examines how runtime costs are shifted, through monomorphization, into longer compilation and larger binaries. Section 6.2 then focuses on binary size and considers ABI instability, static linking, and concrete cases to examine how this affects suitable application domains.

6.1 The Mechanism of Cost Shifting: The Role of Monomorphization

One of Rust’s design principles is zero-cost abstractions. It means that using abstraction facilities such as generics and iterators should not reduce a program’s runtime performance.

The principle is connected to C++ design. Bjarne Stroustrup’s statement, “You don’t pay for what you don’t use,” expresses the same core idea. C++ implements it by generating code at compile time through templates and other mechanisms, removing runtime overhead.

Rust inherits this philosophy and combines it with ownership and the borrow checker to provide memory safety. But zero cost means zero runtime cost, not the absence of all cost. Rust’s ZCA can be understood as a cost-shifting mechanism that obtains runtime performance by moving cost to other stages of the development cycle.

This shift is associated with the compilation strategy of monomorphization. When compiling generic code such as Vec<T>, the compiler generates specialized code for every concrete type used, such as Vec<i32> and Vec<String>. The strategy seeks to remove indirect runtime costs such as type tests and virtual calls, but creates two other costs.

  1. Longer compilation: The compiler duplicates code for each generic instantiation and optimizes each copy. This increases the workload of the compiler, especially the LLVM backend, and lengthens compilation.
  2. Larger binaries: Specialized copies are included in the final executable. Multiple versions of the same logic therefore increase binary size, particularly when combined with static linking.

As an alternative, Rust provides dynamic dispatch through trait objects such as &dyn Trait. Instead of duplicating code, this creates one implementation and selects the required behavior at runtime, accepting runtime overhead in exchange for shorter compilation and a smaller binary.

Rust’s zero-cost abstractions are therefore a design philosophy centered on runtime performance. The resulting increases in compilation time and binary size affect productivity and deployment and should be considered when evaluating ZCA. The design pays compilation-time and binary-size costs to pursue zero runtime overhead.

6.2 Binary Size: How Design Principles Affect Application Domains

Rust executables tend to be larger than C/C++ programs providing similar functions. This matters in resource-constrained systems programming, one of the areas in which Rust is discussed as a C/C++ alternative. This section analyzes the technical causes and examines practical effects through comparisons.

1. Technical causes: ABI instability and static linking

One reason Rust binaries grow is the design choice not to maintain a stable ABI for the standard library, libstd. C has supported dynamic linking for decades through a stable libc ABI, allowing many programs to share system-installed libraries. A dynamically linked C executable can therefore remain small by containing mostly its own code.

Rust does not stabilize the internal ABI of libstd, allowing the language and library implementation to evolve. This prioritizes rapid evolution over stable binary compatibility. Because dynamic linking across versions would be difficult to guarantee, Rust defaults to static linking, embedding required library code into each executable. Even small programs consequently include relevant portions of libstd and grow in size.

2. Case studies: CLI tools and core utilities

The effect can be seen in actual program-size comparisons.

Case 1: grep and ripgrep

ripgrep is a Rust text-search tool often compared with the C-based grep. On a typical Linux system, a dynamically linked grep may occupy tens of kilobytes, while a statically linked ripgrep reaches several megabytes. This simplifies dependency management for deploying one application, but can increase total storage if replacing an operating system’s whole set of base tools.

Case 2: BusyBox and uutils

Resource-constrained embedded Linux often uses BusyBox, which supplies commands such as ls and cat in one binary. The C implementation is under one megabyte. The Rust project uutils, developed for a similar purpose, occupies several megabytes. Exact values vary by version and build environment, but the tendency is structural, arising from differences in standard-library design and default build methods. The following table uses Alpine Linux package data.

Table 6.2: Package-size comparison of core-utility implementations (Alpine Linux v3.22)57

Package Language Structure Installed size (approx.)
busybox 1.37.0-r18 C Single binary 798.2 KiB
coreutils 9.7-r1 C Separate binaries 1.0 MiB
uutils 0.1.0-r0 Rust Single binary 6.3 MiB

The data shows a mismatch between Rust’s default build model and requirements of the embedded environments targeted by BusyBox.

3. Size-reduction techniques and their trade-offs

Several techniques for reducing Rust binary size are shared through guides such as min-sized-rust.

  • Changing panic handling (panic = 'abort'): Instead of unwinding the stack after a panic, the program terminates immediately, removing related code and metadata. This reduces size but skips resource cleanup and prevents panic recovery with catch_unwind. It is therefore an engineering trade-off between binary-size optimization and system resilience.
  • Excluding the standard library (no_std): The program omits libstd, which provides operating-system-dependent facilities such as heap allocation, threads, and file I/O. Size can fall, but data structures and facilities such as Vec<T> and String must be implemented independently or obtained through external crates.

Thus, obtaining binaries comparable in size to C/C++ can require disabling facilities and some safeguards provided by default. This suggests that Rust’s default philosophy prioritizes functionality and runtime performance over binary size.

The longer compilation and larger binaries caused by zero-cost abstractions and monomorphization illustrate Rust’s design philosophy.

These costs are not maturity problems. They are inherent trade-offs that exchange development time and deployment size for runtime performance. They demonstrate the engineering principle that costs do not disappear; they move elsewhere. Developers should understand the cost-shifting mechanism behind “zero cost” and evaluate whether constraints such as compilation speed and binary size align with Rust’s design.

7. Constraints on Industrial Adoption

Chapter 7 analyzes constraints encountered when Rust is applied in industry.

It begins with challenges in specialized domains—embedded and kernel environments (7.1) and mission-critical systems (7.2)—then examines barriers to adoption in general industry (7.3). It concludes with a multidimensional analysis of narratives about adoption by large corporations (7.4).

7.1 Embedded and Kernel Environments: Practical Adoption and Engineering Challenges

Embedded systems and operating-system kernels are areas where Rust is evaluated as a C/C++ alternative. Applying Rust in these fields nevertheless presents several engineering challenges. Just as kernel C cannot use user-space libraries such as glibc, kernel Rust cannot use the operating-system-dependent standard library, libstd.

The challenge is therefore not the mere existence of no_std, but the difference in development model and the cost experienced when developers familiar with std move to it. C development conventionally assumes a low-level environment. Rust developers accustomed to std must absorb cognitive costs when heap allocation, threading, standard structures such as Vec<T> and String, and crates depending on std become unavailable, sharply narrowing the ecosystem they can use.

Rust for Linux is one effort to address these challenges. Its approach can be summarized as follows.

  1. Building safe abstraction layers: One objective is to wrap existing unsafe low-level C kernel APIs with abstractions that use Rust ownership and lifetime rules. Kernel allocation functions such as kmalloc and kfree, locking, and reference counting are represented through safe structures analogous to Box<T>, Mutex<T>, and Arc<T>. Developers can then focus on higher-level logic and benefit from compile-time checks rather than manipulating every kernel detail directly.
  2. Use of unsafe: Below those abstractions, calling C functions and accessing hardware registers still requires unsafe code. This follows from FFI with the C ecosystem. The strategy is to isolate unsafe operations at specific boundaries and permit safe Rust above them.
  3. Actual adoption and cultural challenges: On this foundation, Rust has been adopted experimentally in parts of real systems, including Android’s Binder IPC driver and Apple M1/M2 GPU drivers. Alongside technical barriers, skeptical attitudes among some C kernel developers and cultural and philosophical disputes on the Linux Kernel Mailing List form part of the integration process.

To quantify Linux-kernel integration, the source of Linux v6.15.5 distributed by kernel.org, current on July 9, 2025, was analyzed with cloc v2.04.58 Excluding comments and blank lines, total source lines of code were 28,790,641. Rust accounted for 14,194 lines, approximately 0.05 percent.

The figure describes one moment in an ongoing project and may change as Rust integration progresses. It shows the relative scale and integration status of Rust within the kernel’s C codebase in mid-2025. Quantity does not represent importance or technical influence. Existing Rust code is primarily concentrated on foundational infrastructure for driver development. Section 8.4 later examines how criticism based on this kind of data is received and defended within technical discourse.

The following table summarizes languages with the largest shares of code in that kernel version.

Table 7.1: Language share in Linux kernel v6.15.5 (lines and percent)¹

Rank Language Lines of code Share (%)
1 C & C/C++ Header 26,602,887 92.40
2 JSON 518,853 1.80
3 reStructuredText 506,910 1.76
4 YAML 421,053 1.46
5 Assembly 231,400 0.80
… … … …
14 Rust 14,194 0.05

¹Based on 28,790,641 total lines of code. Some languages are omitted.

Beyond Rust’s 0.05-percent share in the kernel, the technical issue requiring analysis is the structure of safe abstractions. Rust aims to wrap existing C APIs with ownership rules and build a layer of memory-safety assurance. The foundation of that layer, however, internally rests on unsafe blocks that require manual developer verification.

The recently reported CVE-2025-68260, a race condition in Rust Binder, provides a concrete example. During implementation of Android Binder in Rust, synchronization was omitted from an unsafe operation that removed an element from a shared list, causing a data race and memory corruption.

The engineering conclusion is that even though prevention of data races is an explicit Rust design goal, complex kernel-level concurrency still requires unsafe implementations subject to human error. Rust abstractions do not completely remove risk; they deliberately confine it to selected regions of code marked unsafe.

7.2 Mission-Critical Systems and the Absence of an International Standard

In this section, “absence of an international standard” means that the Rust language itself has not been standardized as an international language standard such as ISO/IEC in the way C, C++, and Ada have. It does not mean that there is no qualified Rust toolchain or commercial certification-support path available for safety- or mission-critical development. In fields requiring high assurance, such as aerospace, automotive, industrial control, and medical devices, standardization of the language specification, qualification of compilers and development tools, certification of libraries, and certification of the final system or product must be treated as distinct layers.

The fact that Rust itself is not an internationally standardized language remains an institutional difference from C/C++/Ada. International standards are themselves revised, however, and long-term maintainability and certifiability are not determined by language standardization alone. A real project must examine the language specification it will use, the specific compiler version, validation material, supported targets, library scope, and the vendor’s long-term support conditions together.

Ferrocene illustrates this distinction. Ferrous Systems and its subsidiary Critical Section GmbH publicly announced Ferrocene in 2021 as an effort to qualify the Rust language and compiler for safety-critical use, and in 2022 Ferrous Systems and AdaCore announced joint development for the safety- and mission-critical market. The current Ferrocene compiler has been qualified following evaluation by TÜV SÜD for use in safety-related development under ISO 26262:2018 at ASIL D/TCL 3, IEC 61508:2010 as a class T3 tool for SIL 3, and IEC 62304 Class C.59 It is therefore no longer accurate to generalize that the Rust ecosystem has no commercial toolchain or qualification path corresponding to safety standards.

That qualification must not, however, be expanded into certification of the Rust language as a whole or of every Rust program. The Ferrocene Safety Manual limits the qualification to the language scope described by the Ferrocene Language Specification (FLS) and to specified tools, target environments, and usage constraints, and it requires users to verify the applicable Tool Confidence Level and suitability of their use environment for safety-related development. Parts of bundled libraries outside the qualification or certification scope are likewise not automatically assured for end-use code.59

Compiler qualification and library certification are also distinct. As of February 2026, the certified subset of Rust’s core library distributed with Ferrocene is certified to ISO 26262 ASIL B and IEC 61508 SIL 2; the whole of core is not certified to the compiler’s ASIL D/SIL 3 levels. In aerospace, Ferrocene also states that it supports customer certification efforts toward DO-178C DAL C, but that should not be treated as a completed qualification equivalent to its ISO 26262/IEC 61508 status.59

Accordingly, the key question when evaluating Rust for mission-critical domains is not simply whether Rust is an internationally standardized language. Projects must examine which Rust specification and toolchain they will use, whether the particular version and target platform fall within the qualification scope, whether required libraries fall within a certification scope, and who is responsible for system-level certification of the final product and long-term maintenance. Ferrocene is a counterexample to the claim that the absence of an international language standard necessarily means the absence of a safety-certification path, while also showing that tool qualification does not automatically substitute for certification of an individual product.

7.3 Barriers to General Industrial Adoption and Change Strategies

The following barriers affect Rust’s expansion beyond particular fields into general industry.

  1. Workforce supply and training cost: The Rust developer pool is smaller than those for Java, C#, and Python. Hiring can be difficult and labor costs higher. Retraining existing developers also requires investment in concepts such as ownership and a period of reduced initial productivity.
  2. Maturity of the enterprise ecosystem: Some areas—ORM frameworks, cloud-service SDKs, and authentication and authorization libraries for large enterprise applications—are less mature than their Java or .NET equivalents. This can obstruct adoption where development speed and stability are prioritized.
  3. Implicit specifications in legacy systems: Long-running systems accumulate undocumented behavior in code, tests, deployment scripts, and operational procedures. If language migration fails to recover all of it, functional and compatibility regressions unrelated to memory safety can occur.
  4. Interoperability and transition costs: Incremental adoption requires FFI, conversion of data ownership, translation between error models, and parallel build and debugging toolchains. A complete rewrite can reduce such boundaries, but requires old and new systems to operate in parallel until completion and increases losses if the transition fails.

Legacy is a system state, not a moral category

Legacy generally means an existing system inherited and still operated by an organization. It may involve old technology, complex dependencies, possible end of support, or high change cost. The term itself does not mean the system is defective or must be discarded. One system may be both an asset that preserves undocumented business rules, user compatibility, data, and proven procedures, and a liability with fragile structure and high maintenance cost.

Evaluation should therefore focus not on the legacy label, but on measurable properties.

  • Sustainability of security updates and vendor support
  • Failure frequency, impact, and recovery time
  • Time required for changes and regression risk
  • Tests, documentation, observability, and workforce availability
  • Regulatory compliance, performance, scalability, and total lifecycle cost

Software does not physically wear out merely through use as hardware does. But execution environments, hardware, external interfaces, threat models, and requirements change, so software cannot necessarily remain unchanged forever.60 Rather than discarding it after an arbitrary age, organizations should assess whether it meets current requirements and can continue to be maintained.

Distinguishing sunk cost from future cost

Development spending already incurred is a sunk cost and should not by itself justify keeping a system. Future maintenance, rewrite, data migration, parallel operation, outage risk, functional regression, and opportunity cost, however, are real future costs that belong in the decision. “Keep it because we already spent money” is different from “keep it because transition cost and risk exceed the alternative’s benefit.”

Conversely, age alone is not sufficient grounds for replacement. Maintenance, modernization, partial replacement, and complete rewrite should be compared using the same criteria for expected benefit and future cost. The CMU Software Engineering Institute likewise treats legacy modernization as a decision problem that compares risks and conditions across alternatives ranging from wholesale replacement to incremental integration.61

Industrial change strategies should therefore be evaluated as a continuum.

Strategy Typical conditions Principal benefit Principal cost or risk
Reinforce the existing implementation Defects are localized and stable behavioral assets are substantial Lowest transition risk Structural limits may remain
Modernize in the same language Improve architecture and verification incrementally Easier deployment, rollback, and regression control Compliance with rules depends on organizational capability
Selective Rust adoption Boundaries of high-risk modules are clear Concentrates investment where stronger guarantees are needed FFI and dual-language maintenance cost
Implement new functionality in Rust Little existing behavior must be reproduced Builds Rust experience without rewrite risk Integration with the existing system
Complete rewrite Existing structure cannot meet fundamental requirements and adequate specification, budget, and transition plans exist Redesigns language and architecture together Schedule overrun, regression, and operational transition failure have large impacts

These are conditional alternatives, not a hierarchy. Enterprises should compare defect types and frequency, security-incident cost, change speed, staffing, tolerance for outages, and the quality of tests and specifications. A complete rewrite is one possible choice, not an automatic default derived from the assumption that other improvements are meaningless.

These factors are business and engineering constraints that real organizations must consider when choosing a technology stack and change strategy, independently of a language’s technical features.

7.4 Multidimensional Analysis of the “Large-Company Adoption” Narrative

One argument for Rust’s practicality and future value is its adoption by technology companies such as Google, Microsoft, and Amazon. Their use of Rust is cited as evidence of its technical properties and ability to solve particular problems.

Engineering evaluation, however, must examine not only which company uses a technology but also the specific context, scale, and conditions of adoption. Such analysis helps distinguish the narrative of large-company adoption from technical reality and strategic implications.

1. Context, scale, and conditions of adoption

First is context. These companies do not replace every system and product with Rust; they apply it selectively where its properties are especially relevant. Examples include low-level operating-system components, security-sensitive portions of browser rendering engines, and high-performance infrastructure where garbage-collector latency is unacceptable. Since the same firms continue to rely more broadly on C#, Java, Go, and C++, Rust functions as a strategic tool rather than a universal replacement.

Second is scale. The word adoption can imply organization-wide acceptance, but reality may differ. Relative to the total number of projects and developers at these companies, Rust remains in a growth phase. A few teams’ adoption can be amplified through the company logo into an apparent organization-wide standard, producing a halo effect.

Third is condition. Large technology companies have resources to absorb the cost of new technology: training for the learning curve, internal tools and libraries to fill ecosystem gaps, and financial and scheduling room to accept early productivity loss. Presenting those cases as universal evidence for companies with limited staff and budgets can ignore sample representativeness. Results observed in a specific sample—large technology firms—cannot automatically be assumed to reproduce across the population of all industries. This connects to the representativeness issue identified in Section 5.5.

2. Implications of strategic adoption

The fact that these firms chose Rust strategically is connected to the particular problems they sought to solve. Android, the Windows kernel, Chrome, and similar systems operate on hundreds of millions of lines of existing C++ code. Introducing memory safety without sacrificing performance has been a persistent challenge.

Rust was selected in that setting as a technical means of introducing memory safety incrementally and at scale while retaining the performance and control of the existing C++ environment. This shows that Rust can solve real problems faced by engineering organizations.

The choice can be interpreted not merely as solving a niche problem, but as a leading indicator of change in the systems-programming paradigm.

3. Conclusion: multidimensional analysis

Large-company Rust adoption has two sides. It should not be treated as evidence for every problem context; its particular conditions and limits should be analyzed. At the same time, selective adoption demonstrates Rust’s suitability for particular systems-programming problems and can signal broader paradigm change.

Engineering judgment can proceed from multidimensional analysis that evaluates both a technology’s limits and its potential.

The industrial-adoption conditions examined in this chapter cannot be adequately fixed into only two categories, “maturity problems” and “inherent trade-offs.” Properties arising from language design, ecosystem maturity, institutional qualification and certification infrastructure, and an individual organization’s transition capability change at different rates and affect projects in different ways.

The fact that the Rust language itself has not been standardized as an ISO/IEC international standard and does not promise a stable language ABI are current structural properties. The Ferrocene case in Section 7.2, however, shows that the absence of an international language standard alone does not establish that safety-related tool qualification or a commercial support path is impossible. Conversely, the existence of a qualified compiler does not by itself resolve certification for every library, target platform, or final product.

A limited developer labor pool and gaps in some enterprise libraries are maturity factors that can change as an ecosystem grows. The scope of toolchain qualification and library certification can likewise expand across new releases and targets. ABI policy, interoperability with existing systems, operation of dual toolchains, and rewrite risk should meanwhile be evaluated separately as design, transition, and lifecycle costs.

Industrial applicability should therefore not be summarized as a single “barrier to entry.” Language-level guarantees, specification and ABI policy, qualified toolchains, certified libraries, target platforms, product-certification procedures, workforce and existing assets, long-term support, and transition cost should be evaluated separately. Changes in Rust and its ecosystem may reduce some of these constraints, but improvement in one does not automatically resolve the others.

Part 4: Analysis of Technical-Community Discourse

The first three parts analyzed Rust’s technical characteristics and engineering trade-offs. Part 4 analyzes the structure of the social phenomenon surrounding Rust: its discourse.

This part approaches the formation and logical patterns of defensive discourse in a technical community as a case study. Its subject is expressly limited not to official Rust-project positions but to particular tendencies observed in some online discussion spaces. It does not attempt to overinterpret a minority of voices as the opinion of the whole community. This book attends to such unofficial discourse because even minority voices can shape a new developer’s first impression of a technology and affect the experience of entering its ecosystem. Moreover, public discourse can enter the training data of large language models (LLMs), allowing existing biases to be learned again and amplified technically. Through the concrete case of Rust, this part seeks to understand how technical discourse forms. Chapter 8 analyzes how a silver-bullet narrative62 forms and operates as a collective defense mechanism when challenged. Chapter 9 considers how this discourse affects developers’ technology choices and ecosystem sustainability. Chapter 10 then synthesizes the preceding analysis, presents the challenges and prospects of the Rust ecosystem, and concludes the book.

Part 4 aims to understand how technological ecosystems operate, beyond either advocacy of or criticism toward a particular technology.

8. Formation of the Silver-Bullet Narrative and Collective Defense Mechanisms

Chapter 8 analyzes how a silver-bullet narrative forms and how it can operate as a collective defense mechanism when challenged.

The discussion begins with the narrative’s formation and effects (8.1), then examines the limits of a total-replacement narrative (8.2) and historical precedents in technical discourse (8.3). It next analyzes specific argumentative patterns used in response to criticism (8.4), gatekeeping (8.5), governance controversies (8.6), and the proper scope for citing government recommendations and industrial success stories (8.7). It concludes by considering the official improvement efforts and governance that exist behind these discourses (8.8).

8.1 Formation and Effects of the Silver-Bullet Narrative

The analysis in this chapter limits its subject. It does not address official positions of the Rust Foundation or core development team, nor does it generalize the entire Rust community as one group. Its focus is a particular discourse that differs from the Rust project’s official culture of self-criticism.

Rust’s core developers and foundation do in fact recognize the complexity of async, compilation time, and toolchain problems described earlier in this book as areas for improvement. Through the RFC process and official blogs, they state technical limitations and seek solutions with the community.

Accordingly, the subject here is limited, separately from such official improvement work, to defensive or generalized rhetoric observed among certain supporters in some online technical forums and social media.63 Since it is difficult to measure the quantitative prevalence of this unofficial discourse, the analysis emphasizes its logical structure and effects rather than its frequency.

As discussed in Section 2.3, one factor in Rust’s growth was a narrative organized around values such as “safety without performance loss.” This narrative helped form community identity, encouraged volunteer contributions, and supported ecosystem growth.

When confronted by outside criticism or technical limitations, however, this narrative is sometimes simplified into a silver-bullet claim that “Rust solves every systems-programming problem,” leading to collective defense mechanisms. Some concepts from social psychology can be used as an analytical framework for examining the social drivers of this phenomenon. This is not an attempt to diagnose the psychology of a group or individual, but to explain the structure and effects of discourse formation in a technical community with a shared identity.

For example, cognitive dissonance describes the state that arises when people encounter information conflicting with their effort or beliefs. Applied here, a developer may have invested substantial time and effort in overcoming Rust’s learning curve. Criticism of the language’s disadvantages or limits can then conflict with the motivation to justify that investment. To reduce the dissonance, an individual may emphasize the advantages of the chosen technology and minimize its disadvantages.

From the perspective of social identity theory, when mastery of a technology becomes connected to professional identity, a community may form an in-group. External criticism can then be perceived not as technical review but as a challenge to the in-group’s values or identity. This dynamic may contribute to defensive discourse that discounts the value of other technology ecosystems as an out-group.

This in-group/out-group division can be strengthened in some online spaces by an echo-chamber effect, in which similar views are amplified through repetition within a closed system. Information consistent with the community’s dominant narrative is shared, while criticism or alternatives may be marginalized. Existing beliefs are reinforced, solidifying the silver-bullet narrative and sustaining a defensive posture toward outside criticism.

On this psychological foundation, the narrative appears to be reinforced through particular ways of framing information.

Structural causes of selective framing

The tendency of Rust discourse to emphasize a confrontation with C/C++ while giving relatively little attention to alternatives such as Ada/SPARK cannot be explained solely as an intention to seize control of the discourse. Several structural features of the developer ecosystem interact.

  1. Asymmetry in information access and learning resources: How developers learn and compare technologies depends on the quantity and quality of available information. C/C++ has accumulated decades of books, university courses, tutorials, and community discussions. Rust has also built a learning ecosystem around official documentation such as The Book and its community. Ada/SPARK, by contrast, developed mainly in specialized high-assurance industries such as aerospace and defense, so current learning materials and public discussion accessible to general developers are relatively limited. This difference helps make C/C++ the primary reference point.
  2. Industrial relevance and changing market demand: Technical discourse tends to center on technologies currently used and competing in the market. C/C++ underpins operating systems, game engines, financial systems, and many other industries, while Rust has emerged as an alternative in high-performance fields such as cloud-native infrastructure, web infrastructure, and blockchain. The languages therefore compete or are considered substitutes in real industrial settings. Ada/SPARK’s mission-critical market has different requirements and an ecosystem distinct from the general software market, reducing the perceived need for direct comparison.
  3. Education and developers’ shared experience: C/C++ is used in computer-science courses on operating systems, compilers, and architecture and thus functions as a common language among programmers. Its memory-management problems are a shared experience. Rust discourse gains resonance by referring to those familiar problems. Ada is absent from most standard curricula, making it harder to build a shared frame of reference around it.

Taken together, the C/C++-centered opposition is better explained not simply as deliberate exclusion but as the combined result of an asymmetric information ecosystem, actual market demands, and developers’ shared educational background.

Agenda ownership and discursive leadership around memory safety

One outcome of this process was Rust’s capture of memory safety as an agenda in systems programming.

Mainstream languages such as Java, C#, and Go had long provided memory safety through garbage collection and related mechanisms. Because memory safety was assumed in those ecosystems, it was not usually a subject of debate.

Some pro-Rust discourse emphasized memory safety as the language’s distinctive value within the opposition to C/C++. Developers consequently encountered and learned the term “memory safety” through Rust, producing an agenda-setting effect. This can be analyzed as bringing a value to the center of discussion, shaping public recognition of it, and turning it into brand capital.

In conclusion, the silver-bullet narrative was formed among some supporters through selective framing of comparison targets and agenda ownership. It helped promote Rust and strengthen community identity, while also leaving room for criticism that it can obstruct broader views of the technology ecosystem.

Effects on the information ecosystem and AI training data

Once a dominant discourse about a technology forms, it can spread beyond the boundaries of its community and influence the wider technical information ecosystem.

First, it affects information access for new learners. When searching for information about an area such as safe systems programming, a quantitatively dominant online discourse is likely to rank highly in search results. Learners may encounter Rust first as the alternative to C/C++ and remain unaware of less-discussed alternatives such as Ada/SPARK. This can narrow the opportunity set for technology choice.

Second, it can create bias in the training data of large language models. Because LLMs learn from internet text, the quantitative distribution of training material affects their answer tendencies. If framing that emphasizes Rust’s advantages dominates the discourse, a model answering “What is the safest systems programming language?” may mention Rust before Ada/SPARK or assign it greater weight according to frequency in the data. Existing discursive bias can thereby be relearned and amplified by AI.

8.2 Limits of the Narratives of Total Replacement and “Only Rewriting Is Improvement”

The silver-bullet narrative often expands into the prediction that “Rust will replace existing systems programming languages.” In a stronger form it claims that “the only meaningful refactoring of C/C++ code is a Rust rewrite, and every other improvement is meaningless.” This goes beyond describing technical advantages and narrows the range of valid change strategies to one.

1. Category confusion: equating code improvement with language replacement

As distinguished in Section 3.3, refactoring improves internal structure while preserving existing behavior, whereas rewriting replaces the implementation. The former can improve coupling, ownership boundaries, testability, error handling, and the scope of changes in the existing code. The latter can redesign these structures and add Safe Rust’s compile-time guarantees, but must reimplement existing behavior.

Calling both operations “refactoring” merges two separate questions:

  • How can the current implementation be made more understandable and verifiable?
  • Should the current implementation be replaced by a new implementation in another language?

Declaring the second question to be the only answer to the first changes the category of the problem and presupposes the conclusion.

2. False dichotomy and the nirvana fallacy

It may be true that refactoring C/C++ does not guarantee complete memory safety. It does not follow that such work has no value. Better testability, a smaller raw-pointer surface, isolation of hazardous code, static analysis, and simpler interfaces can reduce both defect probability and blast radius without providing an absolute guarantee.

Conversely, a Rust rewrite does not eliminate every bug or outage. Logical errors, deadlocks, resource exhaustion, availability loss from panics, unsafe and FFI boundaries, and functional regressions still require separate treatment. Requiring perfection from one strategy while demanding only a particular guarantee from another is an asymmetric comparison.

3. Change method and assurance method are different axes

Clear technical discussion must separate two axes:

  • Change method: maintenance, refactoring, modernization, partial replacement, new implementation, total rewrite
  • Assurance method: developer discipline, coding standards, static and dynamic analysis, runtime checks, compiler enforcement, formal verification

Same-language refactoring changes the first axis; Rust’s ownership model is a method of providing stronger defaults on the second. A Rust rewrite changes both axes at once, but improvement does not require changing both. A project can raise assurance within C/C++, replace only selected modules with Rust, or begin using Rust for new components.

4. Ecosystem conditions that constrain total replacement

  • Technical constraint: dependence on the C ABI Modern operating systems, hardware drivers, and libraries use C calling conventions as standard interfaces. Rust must also use the C ABI to interoperate with this established ecosystem. Rust is therefore structurally positioned to coexist and integrate with C for a long period rather than immediately replacing it.
  • Market constraint: the existing application ecosystem The value of a software market is formed not only by languages but by applications, data formats, plug-ins, user workflows, and operational knowledge built with them. Commercial and open-source assets accumulated in C/C++ over decades carry transition costs that technical language features alone cannot erase.
  • Time constraint: replacement while continuing service Most organizations cannot stop feature development and incident response until a new implementation is complete. If the rewrite team must continually catch up with features and security fixes in the existing system, the target moves and divergence between old and new implementations can accumulate.
  • Organizational constraint: transfer of knowledge and responsibility Changing language is not merely changing syntax. It restructures hiring, training, review, debugging, deployment, incident response, and long-term maintenance responsibility. Organizations differ in their capacity to perform this transition.

5. Moralizing legacy and false analogy

Some discourse treats legacy systems not as a technical state but as a moral evil:

“Saying legacy is not bad is like saying a harmful substance is not bad.”

This is a false analogy. A harmful substance can be evaluated by physiological effects on the human body, whereas legacy is a relational term describing a system’s history and present organizational position. The risks of a legacy system should be evaluated through support status, vulnerabilities, change cost, incident history, and fitness for current requirements—not age alone.

This moralization creates several problems:

  1. Replacing evaluation criteria: It prejudges the conclusion through “good/bad” value judgment instead of comparing defect rates, operating cost, and transition risk.
  2. Generalization by age: It ignores accumulated verification assets and compatibility and treats age as a sufficient condition for defectiveness.
  3. Ad hominem and gatekeeping: It characterizes people choosing a technology as abnormal or incompetent, which does not establish whether the technical choice is sound.
  4. Technological monism: Claims such as “only Rust should be used for backends” define one technology as a universal answer while ignoring problem domain, ecosystem, and operating conditions.

It is also inaccurate to classify JSP and PHP as “frontend technologies” in the ordinary sense. JSP is a Java-based server technology that processes requests and generates responses, while PHP is a general-purpose language used primarily for server-side scripting.64 Whether they are suitable for a modern project requires separate evaluation; classification errors and insults cannot replace that evaluation.

In conclusion, Rust is an important tool that strongly blocks particular defect classes, but its advantages do not imply that every improvement to C/C++ is meaningless or that a total rewrite is the only rational choice. Such conclusions are better analyzed as discursive claims combining category error, false dichotomy, the nirvana fallacy, and reduction to a single metric than as engineering comparisons.

8.3 Historical Precedent in Technical Discourse: Operating-System Competition in the 1990s and 2000s

Narratives and collective identities centered on a particular technology are not unique to Rust. They recur throughout technological history. One example is the competition between Linux and Microsoft Windows in the 1990s and early 2000s.

Many voices coexisted in the Linux community, but one narrative formed around the values of freedom and sharing. Its participants saw themselves as a technical and moral alternative to a “giant monopoly,” and this identity sometimes referred to Microsoft as “M$.”65 Similar patterns appeared:

  • Oppositional framing: Binary frames such as openness versus closedness and hacker culture versus commercialism were used.
  • Technical superiority: Facility with a text CLI and compiling kernels was treated as evidence of a “real developer,” separating such users from those relying on GUIs.
  • Response to criticism: Usability and hardware-compatibility criticisms were dismissed as a user’s lack of effort or understanding—for example, “RTFM: Read The Fucking Manual.”66
  • Optimism about the future: Independently of objective market share, belief in the coming “Year of the Linux Desktop” was shared as a future victory.

This historical example shows what can occur when a technical community’s discourse forms around values and identity in addition to technical characteristics. It suggests that some phenomena in the Rust community can be approached through the sociology of technology as well as individual psychology.

8.4 Analysis of Argumentative Patterns in Responses to Criticism

Communities with an established discourse around a technology sometimes display recurring response patterns toward criticism. This section analyzes such patterns through examples of argumentative structures. They are observable in comments on technical blogs comparing technologies and on platforms such as X, Hacker News, and Reddit. Rather than establishing the facts of any one incident, the section connects structures found in public discussion to the logical fallacies catalogued in the appendix.

Case Study 1: Responses to Objective Data

Situation: In an online forum, an analysis using cloc showed that Rust represented less than 0.1% of Linux-kernel code. A critic used this objective datum to point out practical limits to the claim that “Rust will replace all systems programming.”

Observed response patterns: Some users tended to respond as follows.

  1. Red herring: Instead of directly addressing Rust’s low share, they shifted the subject by saying that “other languages such as Ada have not entered the kernel at all,” or questioned the critic’s motive by saying that support for another language made the critic biased.67
  2. Ad hominem: Responses referred to the critic’s intelligence or character rather than the argument, for example, “You lack the intellectual capacity to understand that logic” or “Your attitude shows your level.”68
  3. Substitution of another case: Rather than address the specific kernel-share data, they selectively cited that “Google and Microsoft use Rust” to defend the broader claim. This can relate to cherry-picking or the hasty-generalization fallacy.

Analysis: These response patterns correspond to recognized logical fallacies. They illustrate how responses other than direct rebuttal may appear when objective data conflicts with an established narrative.

Case Study 2: Boundaries and Discussion of the Definition of Safety

Situation: A developer observed that a memory leak caused by an Rc<RefCell<T>> reference cycle could create problems in a long-running server application. This connects to Section 3.2.4.

Observed response patterns: Some users focused on the definition of terms.

  1. Argument by definition: They invoked the official technical definition: “Rust’s memory safety means the absence of undefined behavior. A memory leak is not UB, so it is unrelated to Rust’s safety guarantee. Your observation is therefore off topic.”
  2. Assignment of responsibility: They said, “Creating a reference cycle is a developer mistake, and Rust provides solutions such as Weak<T>. It is unfair to call the language limited because a developer failed to use the available tool correctly.”

Case Study 3: Intellectual Honesty and Conflict Between Communities

Situation: A nonprofit security foundation released a Rust port of a video decoder written in C and offered a reward for performance improvements, producing a controversy.

The technical issues and conflict can be summarized as follows.

  1. Performance and safety claims: The Rust port referred to memory safety, but its actual performance came from assembly code in the original C project, called through unsafe blocks that bypassed Rust’s safety checks.
  2. Criticism concerning intellectual honesty: Developers around the original C decoder argued that marketing this as an achievement of “safe Rust,” despite C/assembly being the actual source of performance, failed to credit the original project fairly.
  3. Maintenance model: The Rust port had to manually backport updates from the original C project. The C community criticized this as an asymmetrical contribution structure that depended on the original project for core R&D while extracting its results.

Case Study 4: A CVSS 10.0 Vulnerability and Discussion of Memory Safety

Situation: In April 2024, a CVSS 10.0 (Critical) command-injection vulnerability, CVE-2024-24576, was found in Rust’s standard library (std::process::Command). It was a security defect arising in “safe” Rust code.

Observed response patterns: Some online discourse argued that the incident did not undermine Rust’s safety guarantee.

  1. Narrowing the issue to memory safety: The argument was, “This is a bug, but it is not a memory-safety vulnerability.” The CVE was a logical error (CWE-78), not a memory error such as a buffer overflow.
  2. Reference to external factors: Passages from the official Rust blog attributing the vulnerability to the complexity of cmd.exe were cited, framing the source of the problem as the design of the Windows operating-system API.

Case Study 5: The Structure of Argument by Definition Around an unsafe Defect

Situation: CVE-2025-68260, a data-race vulnerability caused by a design error in unsafe logic, was found inside the Rust Binder implementation for the Linux kernel. It was a case in which thread safety intended to be guaranteed through static analysis was not clearly maintained at the systems-driver implementation level.

Observed response patterns: When the vulnerability became public, discourse in the technical community showed the following structure.

  1. Individualization of responsibility: The defect was defined not as a flaw in the language specification but as a logical error by the developer who implemented the unsafe block. The integrity of the Safe Rust region was thereby preserved.
  2. Unequal application of comparison criteria: Similar errors in C/C++ tended to be interpreted as an inherent risk of language design, while an unsafe error in Rust tended to be attributed to the skill of an individual developer.

Analysis: This discourse has the structure of the argument by definition defined in this book. It operates through the logic that “safe regions do not produce such errors, and the place where the error occurred is by definition an unsafe region, so Rust’s safety-guarantee model remains valid.”

This structure reflects a tendency to preserve the integrity of a favored technology within a technical community. By limiting the cause to individual developer carelessness rather than language design, it restricts discussion of the engineering trade-off that systems implementation necessarily requires unsafe and is therefore exposed to human error.

Case Study 6: “There Is No Alternative to Rust” and the Omission of Requirements

Situation: An online forum post argued, in effect, that “in a real-world project where the deployment environment cannot be chosen freely, I would not feel confident using C++, and there is no alternative to Rust.” The claim uses C++’s memory-safety risks and deployment constraints to conclude that Rust is the only option.

Argument structure: Simplified, the claim is:

  1. C++ is not a memory-safe language, so it is difficult to choose for a real-world project.
  2. The deployment environment is constrained.
  3. Therefore, there is no alternative to Rust.

The first premise may be sufficient reason to exclude C++ from a particular project. However, excluding one candidate does not mean that every other candidate has also been excluded. To justify the third conclusion, at least the following must be specified.

  • The target system’s performance, latency, memory, real-time, certification, and supported-platform requirements
  • Whether GC, a VM, or a managed runtime is permitted, and the actual deployment conditions such as a single binary or static linking
  • Constraints involving existing code, libraries, ABIs, operational tooling, and organizational personnel
  • The candidate set being compared and the grounds for excluding each candidate under the same criteria

The candidates vary with these conditions. If a managed runtime is permitted for a backend or business system, Java, C#, Go, Python, and Ruby may be candidates (Section 3.5). If GC-free native execution and compile-time memory-safety guarantees are central, Rust is a strong candidate; if strong runtime checks, predictable real-time behavior, and formal verification matter, Ada/SPARK also warrants consideration (Section 3.4). If substantial C/C++ assets already exist, alternatives include modernization within the same language, isolation of risky modules, selective Rust adoption, and mixed-language architectures (Section 3.3). Depending on the platform and ecosystem, other languages such as Swift may also be suitable.

Also, “real-world project” is not a requirement but a rhetorical category. Web services, desktop applications, embedded devices, operating-system kernels, financial systems, and safety-critical control systems are all real-world projects, but they have different defect models and deployment conditions. Using the phrase “real-world” to erase those differences turns a judgment derived from one experience into a rule for every project.

Deployment constraints likewise do not select Rust automatically. Rust may be advantageous where installing a runtime is prohibited, but another choice may be more realistic in an organization where only the JVM or .NET is approved, on a device fixed to a particular ABI and vendor toolchain, or in a system requiring a certified Ada toolchain. The stronger the deployment constraints, the more necessary it is to examine whether introducing a new language and toolchain is itself an additional constraint.

Assessment criteria: To establish the strong claim that “there is no alternative to Rust,” one must (1) state the requirements, (2) construct a realistic candidate set, (3) apply the same comparison criteria to every candidate, and (4) show that Rust satisfies those requirements while the other candidates do not. Without that comparison, anxiety about C++ and unspecified deployment constraints demonstrate not Rust’s uniqueness, but an omitted candidate set and a false dilemma.

A more accurate claim is:

If a project simultaneously requires GC-free native execution, strong static memory safety, target-platform support, and the organizational capacity to maintain Rust, and no other candidate satisfies those conditions, Rust may be the strongest option. Until those conditions and comparisons are shown, however, a “strong candidate” must be distinguished from the “only alternative.”

8.5 The Status-Making of Technology Choice: Qualification, Normality, Intelligence Hierarchies, and Discursive Exclusion

In technical discussion, a speaker’s experience and expertise can be relevant to determining how far the evidence supports a claim. It is also legitimate engineering judgment to assess when a particular language is a stronger option and whether someone has the capability to use it in practice. The discussion moves from technical evaluation to ranking people and groups by status, however, when a technology’s advantages are converted into the general superiority of those who choose it and are used to lower the intelligence, qualifications, or normality of non-users.

This book calls that movement the status-making of technology choice. The phrase is not the name of a single widely agreed psychological concept or formal fallacy. It is a descriptive category for analyzing the following sequence observed in public technical discourse.

  1. A technology’s conditional advantages are expanded into universal superiority.
  2. Understanding or choosing that technology is used as a marker of the user’s intellectual or professional superiority.
  3. Non-users are classified not simply as people making a different choice under different conditions, but as an ignorant or backward outside group.
  4. Technical counterarguments are explained through the speaker’s inferiority, fear, sunk costs, or lack of understanding rather than through their content.
  5. When even disagreement and offense are absorbed as evidence confirming the existing status classification, the argument acquires a self-sealing structure.

This section does not infer the personality, mental state, or clinical characteristics of any particular person. Its objects of analysis are the classification criteria, burdens of proof, and argumentative structures observable in public statements. The quotation-style passages are also not verbatim statements by any particular person. They are composite examples reconstructed to make structures recurring in public technical discussions explicit. They are therefore material for analyzing the possible existence of such arguments, not a statistical sample from which to infer their frequency or the attitudes of Rust users as a whole.

1. Distinguishing expertise review from exclusion of the speaker

Pointing out a lack of expertise is not always gatekeeping. For questions requiring specialized knowledge—such as the soundness of a particular unsafe implementation, compiler internals, or operating-system kernel interfaces—it is legitimate to examine relevant experience and the quality of the evidence. An expertise review can, however, become a device for excluding the speaker rather than evaluating the claim in cases such as the following:

  • dismissing a claim solely because of the speaker’s affiliation, preferred language, or job title when those facts are unrelated to the criticism;
  • concluding that the speaker is unqualified without examining submitted data or reproducible results;
  • introducing a new definition of a “real developer” or “real systems programming” only after a counterexample appears; or
  • applying different expertise standards to supporters and critics even when they present evidence of comparable quality.

Composite example: “Your project did not implement its own event loop or scheduler, so it is not real systems programming. Your experience with the ecosystem and productivity therefore has no value as evidence.”

This response removes the force of the criticism by pushing the speaker’s work outside the relevant category without first explaining what kind of experience the evaluation actually requires. Not every boundary distinction, however, is a No True Scotsman fallacy. The fallacy generally requires an initial generalization about a group, a counterexample to that generalization, and an arbitrary narrowing of the group’s definition to exclude the counterexample.69 If no such prior generalization and retrospective redefinition can be shown, the statement may still be criticized as gatekeeping or an unjustified restriction of scope, but it should not automatically be labeled a No True Scotsman fallacy.

2. Coupling technical superiority with user status

A judgment that one language is safer or more productive than alternatives under particular conditions says nothing about a user’s general intelligence or human worth. A proposition about a technology and a proposition about the person who selected it require different evidence. Some discourse nevertheless performs the following transformation.

Composite example: “A developer capable of understanding the fundamental principles of this language will eventually choose it. People who insist on another choice have a lower level of reasoning or are trapped by their past careers.”

In this structure, the superiority of the technology and the superiority of its users certify one another circularly. A person is classified as superior because they chose the superior technology, and the technology is treated as superior because superior people choose it. Language choice, however, can vary with requirements, existing code, personnel, tools, certification, deployment environments, real-time constraints, transition costs, and an organization’s tolerance for risk. Developers who understand the same facts can reach different conclusions under different conditions.

When a technology begins to function as a status marker for its users, the meaning of technical criticism also changes. A criticism of a language’s performance, safety guarantees, or ecosystem can be interpreted not as an examination of the scope of a particular claim, but as a denial of the insight, pioneering status, or professional value of the users and inside group who selected it. Responses then increasingly assess the critic’s qualifications and psychology instead of answering the technical counterargument.

This analysis does not treat strong technical preferences or community affiliation as problems in themselves. Technical claims and user status remain separate when a technology is strongly recommended with its scope and counterexamples stated, and when non-users’ abilities and value are assessed independently. The problem arises when one technology choice is used as a proxy for ranking the whole person.

3. Defining normality and constructing inside and outside groups

This book uses defining normality as a descriptive category for a rhetorical pattern that treats the practice of one ecosystem as a universal norm without independent support. It is not the name of a single, widely agreed formal fallacy.

The words “normal,” “standard,” and “common” are not inherently improper. They can be useful technical descriptions when their scope is limited by an international standard, an explicit organizational rule, market share, compatibility requirements, or measured frequency of use. The problem arises when the criteria and population being evaluated are left unstated and the practices familiar to one speaker are presented as defaults that every language and organization should follow.

Composite example: “A normal language should provide build tooling, package management, code analysis, and editor support in one prescribed way. Developers who cannot accept the new standard are already a backward generation.”

This example combines the normality of a technical arrangement with the normality of its users in a single statement. The first sentence proposes a criterion for tooling, while the second classifies people who do not follow it as a backward outside group. Terms such as “normal,” “modern,” “real,” and “responsible” can thus do more than describe technical properties: they can define the qualifications of an inside group and the deficiencies of an outside group.

Real development environments include integrated-IDE models, independent language-server models, command-line-centered toolchains, and organization-specific internal platforms. These models have different costs in installation convenience, automation, replaceability, offline operation, long-term support, and organizational control. The relevant comparison is therefore not which arrangement or language universally proves that its users are modern or normal, but which choice is suitable for which users and operating conditions.

4. Distinguishing language proficiency, cognitive effects, and job performance

Some discourse directly links the ability or willingness to learn a particular language with general intelligence and professional fitness as a programmer.

Composite example: “Anyone who lacks the intelligence to learn Rust, or refuses to learn it, ultimately lacks the qualifications to work as a professional programmer.”

This claim combines four separate questions.

  1. Learning and transfer to cognitive tasks: Programming education includes learning a language’s concepts and tools as well as some problem-solving strategies. A meta-analysis synthesizing 105 studies and 539 effect sizes reported a moderate overall transfer effect (g = 0.49) and a moderate far-transfer effect (g = 0.47) from learning programming. This supports the possibility that programming education can positively affect some cognitive tasks.70
  2. General intelligence and ranking people: Better performance on particular tasks or transfer from learning does not by itself establish a comprehensive increase in psychometric general intelligence, nor a human or professional hierarchy between learners and non-learners. Those stronger conclusions require separate measures and research designs.
  3. Rust-specific and selection effects: The meta-analysis combined multiple programming languages and educational settings and did not test a cognitive effect unique to Rust. Likewise, even if people who voluntarily choose Rust have greater prior knowledge or technical interest, education, work experience, and self-selection must be controlled before the language can be said to have caused the difference.
  4. Job relevance: Proficiency in Rust, or the ability to learn it, can be a direct selection criterion when writing and maintaining Rust code is a core duty. For roles in other languages, domains, or functions, the relevant abilities—design, debugging, testing, operations, security, collaboration, and domain knowledge—must be assessed separately. As one methodological reference, the U.S. Uniform Guidelines on Employee Selection Procedures connect the validity of a selection criterion to important job tasks and the knowledge, skills, and abilities required for them, rather than assuming validity from reputation or anecdote alone.71

Being proficient in Rust can therefore be evidence of particular Rust-related capabilities, but it does not by itself represent performance across all software-development work or general intelligence. Conversely, not yet knowing Rust or finding it difficult to learn does not by itself negate a person’s potential as a programmer.

5. Psychologizing technical counterarguments and attributing motives

Psychological and social factors can genuinely affect technology choices. Sunk costs in education and code, an organization’s reputation, or a person’s career can make a change of choice difficult, while uncertainty about a new technology or changes in existing status can also influence decisions. These possibilities, however, cannot be assigned as the cause of a particular counterargument without specific evidence, and attributing a motive does not by itself refute the counterargument’s content.

Composite example: “They cannot admit the limits of the old language because they fear that the career and code they invested in will become worthless. They offer technical reasons, but the real motive is resistance to protect their own status.”

This response replaces questions about performance, productivity, ecosystem, certification, hiring, and integration with existing systems with the speaker’s presumed motive. Even if sunk costs or status defense partly exist, that does not make false the technical claim that an existing system should be maintained or transitioned incrementally. Whether the motive exists and whether the claim is true must be evaluated separately.

Motive attribution must also be applied symmetrically. If a critic’s argument cannot be dismissed merely because the critic invested in an established technology, a supporter’s argument cannot be dismissed merely because the supporter invested in learning, projects, reputation, or group identity around a new language. In either case, the code, measurements, costs, risks, and scope of application should be examined first.

6. Universalizing a favored technology and repeated validation

When technology choice is coupled with user status, the technology’s real advantages can be expanded beyond their original scope. A strength in memory safety can become a conclusion that the technology should be the default language for all software; the success of one service or new component can become a conclusion that every existing system should be rewritten. The favored technology is then treated not as one engineering instrument among several, but as the default answer repeatedly applied to diverse problems.

Composite example: “Problems of security, performance, productivity, maintainability, and developer quality ultimately have the same cause. Making this language the default can replace obsolete technology and obsolete ways of thinking together.”

Different problems require different comparison criteria and evidence. Memory safety, throughput, latency, certifiability, developer productivity, staffing, and legacy integration cannot be reduced to a single measure. Moving a strong result in one domain into a claim of superiority in another requires additional evidence. Section 8.7 separately examines the scope of industrial cases and policy evidence.

When the same claim and status classification are repeatedly approved within a homogeneous group, repetition can appear to be evidence for the claim itself. The consensus or response volume of an inside group, however, cannot substitute for identifying the population and conditions under which the conclusion holds. Repeated validation must be distinguished from technical verification, and channels for examining external counterexamples and different cost structures must remain open.

7. Self-sealing arguments

In this book, a self-sealing argument is an argumentative structure that absorbs contrary evidence and reactions as further support for its existing conclusion, so that no observation can weaken it. The term is used here descriptively for analysis; it does not imply that every inference about psychological motives automatically has this structure.

Composite example: “A programmer of normal intelligence recognizes Rust’s superiority and the value of learning it. Anyone who disagrees lacks the ability to understand it, and being offended by this judgment proves that the person is aware of their own inferiority.”

This argument has the following closed structure.

  1. Begging the question: Rust’s universal superiority and the normality of its supporters are treated as premises for classification rather than conclusions to be tested. Agreement becomes evidence of normality and disagreement evidence of inferiority.
  2. Circular certification of technology and user status: A person is said to choose Rust because they are superior, and to be superior because they chose Rust. Neither claim is tested by an independent measure.
  3. Psychologizing technical counterarguments: Counterarguments about performance, productivity, ecosystem, certification, hiring, or integration with existing systems are replaced by presumed motives such as inferiority, fear, sunk costs, or resistance.
  4. Eliminating falsifiability: If disagreement, discomfort, indifference, and attempts at explanation are all interpreted as evidence for the same conclusion, no observation can cause the claim to be revised.
  5. Asymmetric burden of proof: Critics are required to acknowledge every advantage of the language and overcome its learning barriers, while those asserting superiority are not required to provide comparative evidence, scope conditions, or failure criteria.
  6. Confusing conditional technical judgment with human hierarchy: Rust can be a strong option where memory safety and performance are simultaneously important, and its learning cost may be worthwhile under those conditions. It does not follow that every programmer must choose the same technology or that another choice proves inferior intelligence.

8. Criteria for evaluating status-making claims

When evaluating claims about qualification, normality, or user status in technical discussion, the following questions should be kept distinct:

  • What expertise is actually necessary to determine whether the claim is true?
  • Was that expertise criterion stated before the counterargument appeared?
  • Were the code, data, measurements, and reproduction procedure examined independently of the speaker’s background?
  • Does evidence about the technology’s advantages actually measure users’ general intelligence or professional superiority?
  • Are non-users’ choices being explained only through ignorance, inferiority, fear, or sunk costs rather than requirements and costs?
  • Are the same standards of evidence, expertise, and motive attribution applied to supporters and critics?
  • Is there additional evidence for extending success in one domain to other problems and every existing system?
  • Is repeated agreement within an inside group distinguished from independent technical verification?
  • What counterexample or result would cause the existing judgment to be revised?
  • If language proficiency is being assessed, how does it relate to the important tasks of the particular job?

In conclusion, expertise, standards, language proficiency, and technical recommendations can all be legitimate factors in evaluation, but their scope and supporting evidence must be stated. Discourse that converts a language’s advantages into the general superiority of its users, classifies non-users as an inferior outside group, and explains disagreement solely through defects in the speaker determines personal status before examining technical facts and job relevance.

Technology is not a marker that measures the intelligence or human worth of its users. Recognizing strong technical results is compatible with refusing to expand those results into every problem, every organization, and a hierarchy of all developers. The purpose of separating the status-making of technology choice is not to devalue a particular community, but to return conditional engineering judgments to claims that can be tested.

8.6 The 2023 Trademark-Policy Controversy and Governance

As an open-source project grows and becomes institutionalized, informal practices can conflict with new formal policies and prompt review of the governance model. The controversy over the draft Rust trademark policy in 2023 is a case study of this process.

In April 2023, the Rust Foundation released a new draft policy governing use of the Rust name and logo and requested community feedback. The draft was perceived as more restrictive than existing informal practices, provoking criticism and resistance. Critics worried that restrictions on using the Rust marks for community events, project names, and crate names could suppress ecosystem activity.72

The controversy produced several results.

First, community resistance led to public discussion of a possible language fork named “Crab-lang.” This demonstrated that dissatisfaction with policy could lead to the possibility of project fragmentation.

Second, it exposed differences in communication and perception between the Rust Foundation and the developer community making up the project. Critics argued that while fulfilling its legal responsibility to protect trademarks, the foundation failed to account for the culture and values maintained by the community.

The Rust Foundation ultimately accepted the feedback, withdrew the draft, and stated that it would redevelop the policy with the community.73

This case is recorded as raising questions about the relationship of trust between Rust-project leadership and the community and about its governance model. It illustrates both the process through which an open-source project establishes formal governance and the need for communication and consensus-building with the community during that process.

8.7 Scope of Government Recommendations and Industrial Success Stories

Government recommendations, corporate adoption, and quantitative results are often used to strengthen claims for a technology. In Rust discourse, recommendations to move to memory-safe languages and examples from Android, Discord, Cloudflare, AWS, and the Linux kernel are sometimes joined into one continuous body of evidence supporting the conclusion that Rust has become the default standard for every system. This section distinguishes what each source actually supports from the additional evidence required to move from individual cases to a universal technical norm.

1. The NSA’s list of memory-safe languages (2022–2023)

In November 2022, the U.S. National Security Agency published an information sheet titled “Software Memory Safety.” It emphasized the importance of memory safety and recommended migration to memory-safe languages. It explicitly listed C#, Go, Java, Ruby, Rust, and Swift as examples; an April 2023 revision added Python, Delphi/Object Pascal, and Ada.74

The report began to be used as evidence that an institution discussing reliability at the national-security level had placed Rust in the same category as other memory-safe languages.

2. The White House call to move to memory-safe languages (2024)

In February 2024, the U.S. Office of the National Cyber Director issued a report stressing the need for the technical ecosystem to move toward memory-safe languages.75 It described vulnerabilities from memory-unsafe languages such as C/C++ as a serious national cybersecurity threat and urged developers to adopt memory-safe languages by default. It did not present a language list, but mentioned Rust as an example of a memory-safe language.

3. Joining the two reports through selective interpretation

Because the reports differ in purpose, content, and publication time, they can be selectively linked into a particular chain of reasoning.

  1. Premise 1 (NSA report): A technical agency supplied a concrete list of memory-safe languages.
  2. Premise 2 (White House report): The highest executive institution declared transition to memory-safe languages an urgent national task.
  3. Inference and filtering: The NSA list is filtered for languages considered suitable for systems programming.
    • Python, Java, C#, Go, Swift, and other GC languages tend to be excluded as unsuitable because of runtime overhead.
    • Ada, one of the non-GC languages on the NSA list, is omitted or given little attention.
  4. Conclusion: After this filtering, the claim becomes that “among the NSA’s safe-language list, Rust is the only realistic way to satisfy the White House’s systems-programming memory-safety goal without a GC.”

This illustrates how sources with different purposes and contexts can be linked and how selectively applying a criterion such as the absence of GC can generate a conclusion aligned with the initial framing.

4. Causal attribution and external validity of industrial success stories

Industrial cases are important evidence for the effectiveness of a technology choice. But when a language changes, data structures, architecture, concurrency model, connection reuse, deployment, hardware, team skill, and measurement practices may change too. Attributing the entire result to the language requires a common workload and baseline, disclosure of co-occurring changes, a comparison period, and a counterfactual.

  1. Android security results: Google reported that memory-safety vulnerabilities in Android fell from 76% in 2019 to 24% in 2024 and below 20% for the first time in 2025. Its 2025 analysis estimated a vulnerability density more than 1,000 times lower than historical C/C++ data based on about five million lines of Android Rust and one potential vulnerability found and fixed before release.76 77 This strongly supports Rust’s performance in new and actively developed Android code and at high-risk boundaries. The full decline, however, also reflects a broader memory-safe-language strategy including Java and Kotlin, maturation of existing code, sandboxing, and defense layers; it should not all be assigned to Rust.
  2. Discord latency case: Discord reported that after rewriting a particular Read States service from Go to Rust, periodic latency spikes disappeared and latency, CPU, and memory metrics improved. The source describes the specific conditions of a Go 1.9.2-era implementation, a huge LRU cache, and forced GC every two minutes, and explicitly does not recommend rewriting every system in Rust. It does not report a 50% reduction in P99 latency.78
  3. Pingora resource savings: Cloudflare compared equal traffic and reported that Pingora used about 70% less CPU and 67% less memory than its former NGINX/OpenResty service. The official explanation attributes this not only to efficient Rust code but also to a multithreaded architecture, removal of copies across the C–Lua boundary, and better connection reuse. It states that latency improvement came primarily from the new architecture’s shared connection pool rather than code-execution speed.79 The result is therefore evidence for a redesign implemented in Rust, not a controlled experiment changing only the language.
  4. Firecracker startup time: AWS’s published startup time below 125 milliseconds applies to a Firecracker system using i3.metal, the default microVM size, and a minimal device model. AWS did choose Rust for memory and thread safety, but the data do not isolate the language as an independent cause of startup performance.80
  5. Continuing Linux-kernel adoption: After the 2025 Linux Kernel Maintainers Summit, Miguel Ojeda stated that the Rust-support experiment had concluded and Rust would remain. The same explanation noted that many kernel configurations, architectures, and toolchain combinations were still incomplete and that substantial work and experimental combinations remained.81 This demonstrates continued support, not that Rust has become the kernel’s default implementation language.

5. Tracing the sources of numbers, vulnerabilities, and roadmaps

Quantitative claims appear more persuasive when numbers are large or precise, but conclusions change when survey year, population, denominator, vulnerability description, or roadmap state changes.

  1. Ecosystem size: The estimate of 2.267 million developers is JetBrains’ estimate, based on its 2024 Developer Ecosystem data, of people who used Rust during the previous twelve months.82 The 2025 State of Rust Survey collected 7,156 responses and explicitly warns against extrapolating the entire community from roughly seven thousand respondents.83 The two sources have different purposes and populations and cannot be cited as one common count.
  2. CVE attribution: The official description of CVE-2025-30388 is a heap buffer overflow in Windows Win32K-GRFX requiring local execution and user interaction. It does not attribute the code to Rust, so it cannot support the claim that this was “the first remote-code-execution vulnerability in Rust code in the Windows kernel.”84 CVE-2025-68260, by contrast, involved concurrent access to an unsafe Rust Binder list-removal operation causing a data race and pointer corruption.85 It requires auditing the unsafe contract and shared state, but supports neither the conclusion that Safe Rust’s guarantee does not exist nor that the impact is automatically confined within the unsafe block.
  3. Status of async features: The Rust project’s 2026 roadmap states that current destructors are synchronous, identifies the need for asynchronous cleanup, and places foundations for guaranteed destructors and async drop among topics to explore in 2026–2027.86 This is a direction of investigation, not a promise of inclusion in a particular “2027 edition.”

6. Distinguishing policy recommendation from a declaration of standard

Joint NSA and CISA guidance in 2025 recommends adopting memory-safe languages as a direct way to improve software security.87 This is strong support for treating memory safety as a default requirement, particularly for new high-risk code processing external input. But the recommendation covers multiple memory-safe languages, and the appropriate language and change strategy can differ according to real-time requirements, certification, ecosystem, hardware, existing assets, and transition risks.

DARPA’s TRACTOR program researches automatic translation of legacy C into Rust of a quality comparable to skilled developers.88 This shows that C-to-Rust conversion is a problem of national research value; it is not evidence that all code can already be converted economically and automatically, nor a guarantee of research results.

At least three meanings of “has become the standard” must therefore be distinguished:

  • Standard security requirement: Government guidance and industrial evidence strongly support treating memory safety as a default requirement for new high-risk software.
  • De facto standard tool choice: Whether Rust has become a primary choice in a particular domain or organization can be examined through adoption rate, duration of continued use, and comparison with alternatives.
  • Normative default for every system: The claim that every decision not to use Rust requires special justification needs a separate argument covering application domains, alternative languages, risks in existing systems, and transition costs.

It is consistent both to recognize strong industrial results and policy direction and to avoid declaring a universal obligation beyond the scope of that evidence. The burden to justify memory-unsafety may become stronger, but that fact alone does not force every software-language decision to converge on one language.

8.8 Behind the Discourse: Official Improvement Work and Community Governance

This chapter has analyzed patterns of defensive discourse shown by some supporters in response to technical criticism. These phenomena do not represent the Rust ecosystem as a whole. Alongside such unofficial discourse, official efforts acknowledge Rust’s technical limitations and seek to improve them.

One characteristic of the Rust project is its governance model represented by the RFC process. Language changes and new feature proposals are publicly discussed through RFC documents. Developers debate technical validity, potential problems, and compatibility with the existing ecosystem before decisions are made. This is an example of a culture that accepts criticism in order to develop the technology.

Rust developers and working groups also treat many of the technical challenges identified in this book as improvement goals. Developers have acknowledged the complexity and learning curve of the async model in public writing and proposed visions for improvement, while reduction of compilation time remains an area of compiler-team research and development.

In conclusion, understanding a technological ecosystem requires distinguishing defensive voices in unofficial online spaces from improvement efforts conducted through official project channels. The presence of such an official feedback loop in the Rust ecosystem can be interpreted as evidence of the technology’s potential and capacity for development.

Part 5: Synthesis and Conclusion

Part 5 analyzes Rust’s utility and constraints based on the technical analysis and current ecosystem conditions.

Chapter 9 reassesses Rust’s technical strengths and limits, models of developer ability, and community culture. Chapter 10 presents tasks for ecosystem maturity and expansion, proposes an analytical framework for technology choice, and concludes the discussion.

9. Reassessing Rust: Utility, Constraints, and Technology-Selection Strategy

Chapter 9 synthesizes Rust’s utility and constraints based on the technical characteristics and ecosystem realities discussed above.

Section 9.1 examines how compile-time memory-safety guarantees are used in industry and where Rust is positioned in the market. Section 9.2 analyzes the relationship between technology-preference discourse and the actual labor market and considers how Rust’s level of abstraction relates to developer ability. Section 9.3 discusses the role of community culture and feedback loops in ecosystem sustainability.

9.1 Analysis of Rust’s Technical Characteristics and Application Areas

1. Strength: compile-time memory-safety guarantees

One of Rust’s technical characteristics is prevention of particular memory errors at the language and compiler levels. Buffer overflows, use-after-free, and null-pointer dereferences—common causes of vulnerabilities in C/C++—are statically analyzed and blocked at compile time through Rust’s ownership and borrow-checker model.

This changes the security paradigm from runtime detection and defense to prevention at compilation. When safe code compiles, it can provide a guarantee against these classes of memory vulnerability.

Memory safety helps prevent not only system takeover but also disclosure of sensitive information. Heartbleed in 2014 demonstrated how a missing bounds check can leak information. Rust performs bounds checking by default for array and vector access and structurally reduces these bugs by preventing access to freed memory through its ownership system.

Microsoft, Google, and other companies have reported that roughly 70% of security vulnerabilities in some product sets stemmed from memory-safety problems.89 90 Such external analyses demonstrate the value of Rust’s structural safety guarantees.

2. Application areas: where performance and reliability intersect

Rust’s technical properties are used in cloud-native infrastructure and network services. These fields require low latency without garbage-collector pauses, along with security and reliability against external attacks.

  • Case Study 1: Discord’s performance problem
    Discord experienced latency spikes caused by garbage collection in a Go service. Such latency affects real-time communication. The team rewrote backend services such as Read States in Rust, eliminating GC pauses while retaining memory safety without C++-style manual management. This is a case in which Rust was used as an alternative to the constraints of GC.91

  • Case Study 2: Linkerd’s proxy implementation
    Linkerd implemented its data-plane proxy, linkerd-proxy, in Rust. Because a service-mesh proxy is deployed throughout infrastructure, it requires low resource consumption, speed, reliability, and security. Rust supplies C/C++-class performance and low memory use through zero-cost abstraction while compile-time guarantees reduce vulnerability risks in infrastructure components. This shows Rust’s use for system components requiring both performance and safety.92

Cloudflare and AWS likewise use Rust in network services and virtualization technologies such as Firecracker, while Figma has used Rust for graphical rendering in WebAssembly. These cases show Rust’s practical use in particular markets.

3. Market position and limits

Rust is used as an alternative to established languages in particular domains that require both performance and safety and restrict the use of garbage collection.

That use does not automatically extend to every area of software development.

  • Traditional systems programming (C/C++): Decades of accumulated code and ecosystem assets in operating systems, embedded systems, and game engines create a barrier to entry.
  • Enterprise business applications (Java/C#): Large organizations often evaluate development productivity, library ecosystems, and labor availability in addition to runtime performance. In web-backend environments requiring frequent business-logic change and continuous service, garbage collection and exception handling may support productivity and availability more effectively than strict manual control of memory.

Rust’s present position can therefore be analyzed as that of a specialized tool solving particular market problems. To become a mainstream general-purpose language, it must address technical and ecosystem challenges in other domains.

9.2 Ecosystem Reality and a Multidimensional Model of Developer Ability

Rust’s technical properties and ecosystem condition relate to developers’ technology choices and skill-development strategies.

1. The gap between preference discourse and the labor market

Rust has ranked highly in “most loved language” categories in surveys such as Stack Overflow’s, demonstrating developer preference. Adoption by technology companies also shapes perceptions of its potential.

Yet a gap remains between technology-preference discourse and actual labor demand. As of 2025, demand for Rust developers was growing but remained small relative to the markets for Java, Python, and C++.

This gap can be understood through factors companies consider when adopting new technology: learning cost, ecosystem maturity, and integration cost with existing systems. Career planning should therefore consider market size and ecosystem maturity in addition to popularity and potential.

2. Relationship between abstraction level and foundational computer-science knowledge

Rust’s ownership and lifetime model requires developers to understand memory-management principles and can strengthen systems-programming ability.

At the same time, its abstractions can limit direct experience with some fundamentals. Because Rust enforces safe management, developers have fewer opportunities than in C/C++ to encounter and repair errors such as leaks or double frees during manual malloc/free work.

Likewise, using standard structures such as Vec<T> and HashMap<K, V> is a different learning experience from implementing a linked list or hash table in a low-level language and directly confronting memory layout and pointer operations.

No single language therefore covers every computer-science foundation. Direct implementation experience in a low-level language can provide a basis for understanding both the value and internal operation of Rust’s abstractions. Data structures, algorithms, operating systems, and other foundational knowledge remain useful independently of mastery of any one language.

3. Tool dependence and defensive coding

A further component of developer ability is awareness of tool limits. As Section 4.2 explained, “the language is safe” does not mean “the code written in it is safe.” Rust prevents memory-corruption UB but not service interruption from logical errors, panics, or loss of availability.

Dependence on language guarantees can reduce defensive practices such as validating exceptional conditions. Developers must understand the guarantee boundary and apply separate verification and discipline to matters outside it, including logical correctness and system resilience.

4. Developer ability and the multidimensionality of hiring evaluation

Software engineering consists of more than language syntax. Requirements, architecture, design, implementation, testing, security, operations, maintenance, quality, and specialized practice are interconnected. The IEEE Computer Society’s SWEBOK Guide V4.0 organizes software engineering into eighteen knowledge areas and does not treat one programming language as a proxy for the profession.93

Hiring criteria are not valid merely because they are numerous or few. Overly fragmented or job-irrelevant checklists can exclude strong candidates; using proficiency in one language to predict performance in every role loses information and creates error. Criteria should be connected to actual work through job analysis and, where possible, their predictive validity examined using work samples, structured interviews, and historical job-performance data. Personnel-selection research likewise treats validity as a question of measurement and verification, and has suggested that some conventional estimates may have been overstated.71

When hiring a Rust developer, an organization can directly assess Rust coding, understanding of ownership, and relevant ecosystem experience. General developer assessment, however, should combine the following dimensions according to the role.

  • Ability to understand the problem and requirements accurately
  • Ability in design, implementation, debugging, and testing
  • Ability to address performance, safety, reliability, and operational problems
  • Code review, communication, collaboration, and domain knowledge
  • Ability to learn new technologies and transfer existing knowledge

9.3 Technical Communities, Organizational Evaluation, and Ecosystem Sustainability

The sustainability of a programming language and software organization depends not only on technical properties but also on community culture and evaluation systems. How criticism is received, how newcomers are treated, work priorities, metrics, and reward structures can affect knowledge sharing, retention, and long-term maintainability.

1. The role of criticism and feedback loops

External criticism and internal problem reports function as feedback mechanisms in a technical ecosystem. Discussion with language communities based on different design philosophies—C++, Ada, Go, and others—provides opportunities to examine a technology’s characteristics and limits.

How a community receives and processes outside feedback is therefore related to ecosystem maturity. Defensive responses to technical criticism, as observed in some online discussion, can reduce technical exchange. A culture that incorporates criticism into formal procedures, as in Rust’s RFC process, can contribute to development.

2. Effects of newcomer onboarding and knowledge-sharing culture

Ecosystem sustainability depends on the arrival of new participants. The Rust project formally has a Code of Conduct.

Apart from such formal aims, two response patterns can be observed in some online technical forums.

  • Pointing to lack of knowledge: A reply refers to the questioner’s lack of knowledge or effort rather than the question (“Read the official documentation first”), or denies the premise (“You do not need that approach”). Such interaction can delay problem solving and reduce willingness to participate.
  • Providing information and alternatives: A reply acknowledges the difficulty, explains that its cause may lie in the technology’s complexity rather than personal ability, and offers information or alternatives. This helps newcomers acquire knowledge, shapes their perception of the community, and provides a basis for becoming contributors.

3. Organizational environment, talent loss, and the formation of ability

Some discourse claims that in irrational software organizations every capable person leaves, only incompetent people remain, and tenure develops internal political skill rather than design ability. This combines testable organizational hypotheses with unsupported rankings of an entire industry.

  1. Leaving and staying are conditional selection processes: Poor work environments can relate to turnover intention, but who leaves and remains is jointly influenced by satisfaction, labor-market options, compensation, personal constraints, organizational relationships, and career prospects. A 2026 cross-sectional survey of 224 software professionals found job satisfaction and organizational embeddedness negatively associated with turnover intention, with organizational justice an important predictor of embeddedness. It does not establish actual turnover causality or the intelligence of those who stay.94
  2. Psychological safety is one part of a learning environment: Teams that punish questions, reports, or mistakes may conceal defects and bad news. Edmondson’s study of fifty-one teams associated psychological safety with learning behavior, which was linked to team performance.95 This shows that environments can promote or suppress learning, not that people who remain in a particular organization are inherently incompetent.
  3. Incentives can change technical behavior: If organizations reward only short-term feature counts and schedules and treat design review, tests, documentation, and refactoring solely as costs, people will prioritize visible short-term output over long-term quality. SEI work on technical debt recommends making debt visible, protecting repayment from new-feature pressure, and explicitly allocating resources.96 Recurrent quality problems should be investigated through organizational goals and allocation as well as individual ability.
  4. Tenure and expertise do not coincide automatically, but are not unrelated: Years of service alone do not guarantee design ability. Without feedback, review, incident analysis, varied assignments, and learning time, experience may harden into repetition of narrow practices. Conversely, long-tenured staff can accumulate tacit specifications, incident history, and cross-organizational dependencies. Reducing all of this to politics is also an error. Stakeholder alignment and resource negotiation can be necessary coordination skills in large systems and should be distinguished from concealment, blame shifting, and factional competition.
  5. Productivity and ability are multidimensional: The SPACE framework argues that developer productivity cannot be represented by one activity measure and should include satisfaction and well-being, performance, activity, communication and collaboration, and efficiency and flow.97 High short-term output can coexist with burnout, knowledge concentration, rework, and turnover that weaken long-term results.
  6. Organizational and individual responsibility must both be evaluated: Employers are responsible for examining workload, the alignment of authority and responsibility, promotion and reward criteria, blame culture, maintenance budgets, and learning opportunities. An environmental explanation does not erase individual responsibility for harassment, negligence, or skill development. Making organizational and individual responsibility a dichotomy weakens both causal analysis and improvement.

4. Asymmetry of evaluation information and distortion by proxy metrics

Prevention, maintainability, design quality, and long-term risk are difficult to observe immediately. When evaluators cannot directly inspect them, visible signals—overtime, code volume, emergency response, difficult terminology, complex structures—may become proxies for real performance. Proxies can inform evaluation, but when rewarded as goals they can displace the qualities they were intended to measure.

  1. Invisible prevention and incident heroism: Work that prevents an incident appears as the absence of an event and is hard to see, while prolonged recovery from a severe incident is visible. Rapid recovery deserves recognition, but rewarding only sacrifice during recovery rather than prevention, automation, observability, and follow-up makes recurring incidents and overwork difficult to reduce. This book calls the domination of evaluation by dramatic recovery over prevention incident heroism. Google SRE guidance likewise emphasizes contributing causes and preventive action over personal blame and recommends rewarding postmortems and prevention themselves.98
  2. Confusing activity with outcomes: Hours worked, commits, lines, and tickets show some activity but are not identical to reliability, user value, or maintainability. Removing a problem with little code or automating repeated work may reduce activity counts. A single activity metric can therefore penalize simplification and prevention. SPACE rejects a single metric because productivity includes satisfaction, outcomes, activity, collaboration, and flow.97
  3. Display of complexity and readability: Jargon, abbreviations, abstractions, and complex structures can be necessary, but are not themselves evidence of expertise. The hypothesis that obscurity can look like depth to nontechnical evaluators is testable; actual judgment should use review, change cost, defect rate, and comprehensibility. Buse and Weimer built a readability metric from judgments by 120 people and reported correlations with change and defect-related measures.99 This shows that readability is a reviewable quality attribute, not that one style causes defects in every system.
  4. Mismatch between evaluator and developer criteria: Developers and managers can define productivity and quality differently. Storey and colleagues found that the two groups’ definitions did not fully coincide and that developers did not precisely predict managers’ views.100 This does not prove that nontechnical managers always evaluate incorrectly; it suggests that roles, quality goals, and time horizons should be explicitly agreed rather than left implicit.
  5. Validation of evaluation systems: Evaluation should combine evidence across periods rather than depend on personal impressions. It should examine incident and recurrence rates, change-failure rate, recovery time, follow-up completion, review results, technical debt, user impact, and team sustainability. An internal Google panel study associated code quality, technical debt, tools and support, communication, goals, and organizational processes with perceived productivity and reported that improvements in code quality tended to precede productivity improvements.101 Results from one organization should not be generalized unchanged to every company.

5. Samples, national generalization, and stigmatizing analogies

Personal experience with organizations and developers can be a starting point for identifying a problem, but is not a sample for judging all programmers in a country.

  1. Separating observation scope from population: Online posts, a few companies, or a personal career do not support estimating the intelligence or technical level of all Korean developers. Samples with unknown recruitment, roles, experience, company size, and industry do not guarantee representativeness.
  2. The leap from nationality to cause: The possibility that evaluation or contracting structures distort quality is distinct from the claim that this results from the intrinsic ability of a nationality. Without cross-national data and controls for institutions, nationality is a classification label, not an explanatory variable.
  3. Separating service work from technical ability: Interpreting requirements and coordinating with customers, operators, and managers are parts of software engineering. Organizational behavior aimed only at pleasing stakeholders can be criticized, but the presence of a service component does not make development work technically inferior.
  4. Irrelevance of stigmatizing analogy: Slurs involving disability or mockery of a group as an object of care do not explain how evaluation systems work. They convert verifiable organizational criticism into stigma against people and transfer insult to groups unrelated to the analysis.
  5. Causal leap to a Rust conclusion: Even if defective organizational evaluation exists, it does not by itself prove the cause of criticism of Rust, Rust’s universal superiority, or low intelligence among nonusers. Hypotheses about incentives and engineering validity of language choices require separate tests.

Organizational hypotheses should be tested with data, not insults. Large organizations should observe voluntary turnover and reasons, tenure, onboarding time, concentration of critical knowledge, time spent on prevention, after-hours incident burden, recurrence, follow-up completion, rework, escaped defects, technical-debt repayment, psychological safety, and promotion fairness over long periods by team, role, and tenure group. Particular anecdotes or grievances cannot establish the cognitive capacity of an industry or nation.

In conclusion, environments that accept criticism, share knowledge, and reward prevention and long-term quality can support the sustainability of technical ecosystems and organizations. Attributing structural problems to individual intelligence or nationality, automatically converting visible hardship and obscurity into expertise, or declaring all members of an organization inferior obstructs verifiable causal analysis.

10. Conclusion: Challenges and Prospects for Ecosystem Sustainability

Chapter 10 presents the challenges facing the Rust ecosystem and synthesizes the book’s discussion.

Section 10.1 first analyzes technical and policy challenges for the ecosystem’s qualitative maturation and expansion into industrial fields. Section 10.2 then redefines Rust’s values of “safety” and “performance” in engineering context, proposes an analytical framework for technology selection, and concludes the book.

10.1 Challenges for Structural Improvement of the Ecosystem

For Rust to expand as a general-purpose systems programming language, qualitative maturation across the ecosystem is required in addition to the language’s technical features. This section analyzes technical and policy challenges that may affect the Rust ecosystem in the future.

1. Technical challenge: the trade-off between ABI stability and design philosophy

Rust currently does not provide a stable Application Binary Interface (ABI) for its standard library (libstd), and most programs use static linking. This is one cause of larger binaries and constrains expansion into resource-limited systems.

This design enables improvement and optimization of the language and libraries, but the absence of dynamic linking limits integration with other languages and use as a system library. Whether to stabilize the libstd ABI will therefore remain a technical question in which the Rust project must choose between the values of “evolution” and “compatibility.”

2. Ecosystem challenge: securing library stability and reliability

The Rust library ecosystem centered on crates.io has grown quantitatively, but it still has room for qualitative improvement. Many core libraries remain below version 1.0, implying API instability, while maintenance models that depend on a small number of individuals create potential risks to long-term reliability.

Other open-source ecosystems use measures such as the following to address these problems.

  • Financial and human support for core libraries: Foundations or corporate sponsorship support the maintenance of critical projects.
  • Maturity models: Rating systems assess library stability, documentation quality, and maintenance status to help users choose dependencies.

Such institutional mechanisms can help the Rust ecosystem progress toward qualitative maturity.

3. Scalability challenge: flexibility for application across industries

For Rust’s application domains to expand, greater flexibility in the language and ecosystem is an important challenge.

  • Language and tool usability: Work related to cognitive cost and productivity, such as the Polonius project that changes how the borrow checker analyzes programs, affects language accessibility.
  • Execution models: Rust’s current async model is based on zero-cost abstractions. Optionally providing a lightweight-thread or green-thread model like Go’s goroutines could influence Rust adoption in network services.
  • Ecosystem expansion: Library development in areas such as desktop GUI and data science, together with Foreign Function Interface (FFI) technology, can affect Rust’s range of use.

These questions are being discussed through the Rust community and working groups, and their outcomes will influence Rust’s future position.

10.2 Synthesis: A Framework That Jointly Considers Technology, Change Strategy, Competence, Measurement, and Organizational Environment

This book analyzed the Rust language’s characteristics and discourse and described engineering trade-offs through comparison with other technical alternatives. A central conclusion is that we must distinguish yet jointly examine language characteristics, methods for changing existing systems, methods for evaluating developer competence, measurement systems used to observe that competence, and the organizational environment in which competence is exercised.

The meanings of “safety,” “performance,” “improvement,” “competence,” “measurement,” and “organization”

  • Expanding safety: Compile-time memory-safety guarantees are an important Rust capability. Software-system reliability, however, also includes logical correctness, resilience that keeps services operating when errors occur, deployability and rollback, and the collaborative environment of the community.
  • Expanding performance: Rust is designed with runtime-performance optimization in mind. Project efficiency also includes developer productivity, feedback-loop speed including compilation time, incident-recovery time, and maintenance cost.
  • Expanding improvement: Improvement is not synonymous with language replacement. Refactoring improves structure and changeability; analysis and testing improve defect-detection capability; partial replacement concentrates strong guarantees on particular risks; and a full rewrite redesigns both language and architecture. Each strategy has different benefits and failure modes.
  • Expanding competence: Proficiency in a particular language can be an important job skill, but it is not synonymous with general intelligence, total software-engineering competence, or human worth. Competence assessment should center on knowledge and actual performance required by the role.
  • Expanding measurement: Easily observed activity must be distinguished from actual outcomes. No single metric represents total quality, and we must examine what behavior is induced when a metric is tied to rewards.
  • Expanding organization: Individual performance is affected by tools, workload, authority, feedback, rewards, psychological safety, and the distribution of knowledge. Organizational problems should not be reduced to individual incompetence, but individual responsibility should not be erased in the name of environment either.

An analytical framework for technology selection and change strategy

  1. Problem Domain: What are the requirements of the problem to be solved? Which takes priority: latency, throughput, hardware control, development speed, resilience, or formal proof?
  2. Defect Model and Baseline: What types of actual failures and vulnerabilities occur? Which dominate: memory-lifetime errors, data races, logical errors, or operational mistakes? Have defect rates, failure impact, repair time, and performance been measured in the current state?
  3. Required Assurance: Are developer discipline and analysis tools sufficient, is compiler enforcement necessary, or is formal verification such as SPARK required? Does every component require the same assurance level?
  4. Change Strategy: Which scope is proportionate to the problem: same-language refactoring, modernization, selective replacement of risky modules, implementing new components in Rust, or a full rewrite?
  5. Decision Horizon: Have sunk costs that cannot be recovered been separated from future maintenance, transition, parallel-operation, outage, and opportunity costs? Is age itself being used as an independent reason for disposal?
  6. Lifecycle Cost: Does the calculation include not only implementation but training, dual-language maintenance, FFI, build, debugging, deployment, operations, rollback, and long-term staffing?
  7. Ecosystem and Longevity: Do the stability, standardization, vendor support, security response, and maintenance continuity of essential libraries and tools match the project’s expected lifetime?
  8. Failure and Transparency: If the new strategy fails, how much can be rolled back? Are limitations and failure cases discussed by the same standards as advantages?
  9. Construct and Measure: Are technical properties of a language being translated into developer intelligence or character? Do hiring criteria measure actual job behavior and performance, or the identity of a particular technical community?
  10. Organization and Incentives: Do schedules, promotion, rewards, and accountability encourage long-term quality, knowledge sharing, and problem reporting? Are high turnover, burnout, knowledge concentration, and technical debt treated only as individual problems?
  11. Falsifiability and Motive Attribution: What result would cause the current judgment to change? Is the conclusion being protected by attributing ignorance, fear, or inferiority to critics instead of addressing their arguments?
  12. Proxy Measures and Incentives: Are work hours, code volume, emergency response, and obscure expression used as proxies for performance? Do these measures disadvantage prevention, simplification, and knowledge sharing?
  13. Sample and Generalization: What population do the observed team, company, or online group represent? Are limited experiences being expanded into claims about an entire industry, nation, or human group?
  14. Attribution and Traceability: Which part of an observed improvement came from the language, redesign, architecture, hardware, or team expertise? Were numbers, CVEs, survey years, and roadmap status checked against original sources, with estimates distinguished from observations?

Evidence-based change procedure

Technology selection should resemble a comparative experiment more than a declaration.

  1. Fix existing behavior with regression tests and observable metrics.
  2. Identify the boundaries where actual defects and costs are concentrated.
  3. Test both improvements within C/C++ and selective Rust replacement on representative modules.
  4. Compare defect-detection rate, runtime performance, development time, operational complexity, binary and memory use, and maintainability over the same period and under the same conditions.
  5. Record data structures, architecture, runtime, hardware, and operating policies changed along with the language so that language effects can be distinguished from redesign effects.
  6. Trace numbers, survey sizes, CVE descriptions, and roadmap status to original sources, distinguishing observations, estimates, pre-release discoveries, and self-reported data.
  7. Measure team workload, review structure, capacity to manage technical debt, incident-response burden, turnover, and knowledge concentration so that technical effects can be separated from organizational effects.
  8. Record preventive work separately from incident response, and evaluate both the visibility of recovery and long-term improvement through recurrence rates and completion of post-incident actions.
  9. Regularly examine whether metrics encourage dysfunction such as increasing code volume, unnecessary complexity, overwork, or concealment of problems.
  10. Distinguish government recommendations, research programs, and particular companies’ success cases as policy direction, research objectives, and conditional empirical evidence respectively.
  11. Expand adoption only when results meet objectives; otherwise stop or roll back.

Under this framework, the central questions are not “Which language is absolutely superior?”, “Which language’s users are more intelligent?”, or “Which nation’s developers are inherently inferior?” They are: “Which defects should be reduced by which guarantees and at what cost?”, “What portion of the observed result is attributable to the language itself?”, “Which job capability should be assessed with what evidence?”, “What behavior do the measurements induce?”, “Which organizational conditions encourage learning and long-term quality?”, and “What evidence would change the judgment?” Refactoring and rewriting are engineering means that can be combined according to the scale of the problem and the evidence, while language proficiency and organizational environment are different variables that must be evaluated according to role and context. Claims that reinterpret disagreement as a defect in the opponent and thereby block falsification cannot be used for technical comparison in this framework.

Epilogue

This book analyzed the Rust language’s technical characteristics and discourse in historical and engineering context. The analysis found that Rust provides compile-time memory-safety guarantees within Safe Rust, an important engineering achievement in systems programming.

Rust’s design principles—the ownership model, zero-cost abstractions, and type-system-based error handling—integrate and enforce existing ideas from C++ RAII, Ada/SPARK safety models, and functional programming. In doing so, they entail engineering trade-offs such as a learning curve, compilation time, binary size, and complexity in implementing certain design patterns.

The choices for an existing system are not a binary between “leaving C/C++ untouched” and “rewriting everything in Rust.” Same-language refactoring can improve structure, verifiability, defect rates, and maintenance cost, while selective or comprehensive Rust adoption can provide stronger defaults against particular defect classes. Refactoring and rewriting are not synonyms, and the existence of one does not reduce the value of the other to zero.

Learning Rust is a valuable activity that teaches new concepts and tools. Its learning outcomes, however, do not prove general intelligence or the inferiority of other developers. Developer competence results from a combination of language proficiency, design, verification, operations, collaboration, and domain knowledge.

In evaluating software organizations, visible overtime, code volume, emergency response, and obscure expression are not automatic evidence of quality. Less dramatic outcomes such as prevention, simplification, readability, recurrence reduction, and sustainable collaboration must also be measured. Nor should evaluation failures observed in some organizations be generalized into claims about the intelligence or character of every developer in a nation.

The analysis also observed that when narratives emphasizing technical superiority form within technical communities, they can affect both evaluation of the technology and interaction with other ecosystems. This describes some of the discourse examined in this book, not the whole community. Similar patterns appear in past operating-system rivalries and can be interpreted as social dynamics that emerge when technical choices become linked to group identity.

Ultimately, this book is not intended to endorse or exclude any particular technology. Its purpose is to examine separately the scope of technical guarantees, change costs, failure modes, and discourse structures. Developers and technical communities can combine refactoring, modernization, partial replacement, and rewriting according to the nature of the problem and measurable outcomes rather than slogans.

Appendix: Analysis of Argumentative Fallacies Observed in Technical Discussions

This appendix analyzes types of argumentative patterns observed in online technical discussions in order to explain the communication practices discussed in the main text. The cases are examples for explaining fallacies. Each has been anonymized, and the purpose is to analyze its argumentative structure and effect on discussion.

Case 1: Ad hominem fallacy

  • Context: When a developer pointed out the effects of Rust’s learning curve and async complexity on productivity, some users were observed responding with remarks about the speaker rather than the technical issue.
  • Observed response: “Honestly, your failure to understand async is not Rust’s problem but a problem with your ability. You may not be ready to handle complex systems. Consider going back to an easier language.”
  • Analysis: Instead of discussing the technical criticism—learning curve and async complexity—the response comments on the claimant’s ability and qualifications. This is an ad hominem fallacy, attacking the person rather than addressing the issue. Such reasoning can distort technical discussion.
  • Socio-technical cause analysis: This reaction may connect to community identity around Rust’s “safety.” When memory safety is treated not only as a feature but as a Rust value or philosophy, criticism of mechanisms that implement it, such as async or the borrow checker, may be perceived as an attack on the technology itself. The discussion then shifts from “What problems does this feature have?” to “Why can’t you understand this feature?”, creating conditions for an ad hominem response that relocates the issue from technology to individual ability.

Case 2: Genetic fallacy and circumstantial fallacy

  • Context: Rust’s borrow checker checks memory-access rules at compile time to prevent errors such as data races. A C++ user argued that the borrow checker can constrain developer flexibility in certain situations. Some responses then focused on the claimant’s background or motive rather than the content.
  • Observed response: “You see Rust’s rules as a ‘constraint’ only because decades of familiarity with C++’s ‘unsafe’ style have made you resistant to a new paradigm. Your view is biased by attachment to the old way.”
  • Analysis: Rather than rebutting the claim, the response questions the motive and background for making it—familiarity with C++. This is a form of the genetic fallacy, evaluating a claim by its source or presumed motive, and it shifts a technical issue into psychological interpretation.
  • Socio-technical cause analysis: The fallacy draws on the “alternative to C++” narrative in Rust discourse, where C++ is often framed as an unsafe past. Criticism from a C++ user may therefore be treated, regardless of content, as the viewpoint of someone attached to “the old way.” This creates conditions for dismissing the claim by attacking its origin instead of examining its technical substance.

Case 3: Straw man fallacy

  • Context: A blog post compared Rust’s Result type with Java checked exceptions. Some users responded by transforming the comparison into a stronger claim and attacking that version.
  • Observed response: “So your claim is that Rust error handling is useless? You clearly do not understand how panic and Result solved the null-pointer problem. You just want lazy coding where everything is wrapped in try...catch.”
  • Analysis: The response changes the original comparative analysis—“it has disadvantages relative to…” —into “it is useless,” then attacks the altered claim. This attacks an easily defeated substitute rather than the actual position and is therefore a straw man fallacy.

Case 4: Category mistake, false dilemma, and nirvana fallacy

  • Context: In a discussion about improving an existing C/C++ system, same-language refactoring was compared with a Rust rewrite.
  • Observed response: “Refactoring C/C++ means rewriting it in Rust; every other form of refactoring is meaningless.”
  • Analysis 1 — Category mistake: It treats behavior-preserving internal restructuring and replacement with a new implementation as the same operation. Placing different categories of change under one term predetermines the conclusion.
  • Analysis 2 — False dilemma: It leaves only the status quo and a complete rewrite, excluding intermediate strategies such as stronger static analysis, test construction, isolation of dangerous code, modern C++, and selective Rust replacement.
  • Analysis 3 — Nirvana fallacy: Because C/C++ refactoring does not eliminate every memory error at the language level, it dismisses even partial reductions in defect probability and maintenance cost as worthless. It rejects a real improvement by comparing it with a perfect ideal.
  • Analysis 4 — Reduction to a single metric: It reduces software quality to memory safety and removes logical correctness, availability, compatibility, validated behavior, operational risk, and transition cost from the comparison.
  • Discursive function: Instead of requiring concrete defect data and cost comparison, the claim defines one language choice as the “only meaningful improvement.” Technology selection can thus become an identity statement rather than a testable hypothesis.

Case 5: Moralization of legacy, false analogy, and ad hominem

  • Context: In discussing maintenance, modernization, or replacement of an existing system, a claim characterized the existence of legacy systems itself as morally bad.
  • Observed response: “Saying legacy is not bad is like saying a harmful substance is not bad, and anyone who chooses a backend technology other than Rust is abnormal.”
  • Analysis 1 — False analogy: It places a physiologically harmful substance and “legacy,” a term describing a system’s historical and organizational state, in the same evaluative category. Their relevant properties differ, so the comparison does not support the conclusion.
  • Analysis 2 — Moralization and age bias: It converts age directly into evil or a reason for disposal without measuring support status, defect rate, maintenance cost, and transition risk.
  • Analysis 3 — Misuse of sunk cost: Continuing solely because of past expenditure may be wrong, but future transition costs and functional-regression risks are not sunk costs and must not be excluded as such.
  • Analysis 4 — Ad hominem and false dilemma: It attacks the ability or normality of people who make a different choice instead of presenting technical evidence and offers only adoption of a particular language or irrationality.
  • Analysis 5 — Factual error: It classifies JSP and PHP as frontend technologies executed in the browser, although both are generally used server-side to process requests and generate responses.
  • Discursive function: Instead of examining actual system quality and transition conditions, it turns a technology choice into a moral and intellectual qualification and excludes alternatives from discussion.

Case 6: Equating language proficiency with intelligence and reducing evaluation to one metric

  • Context: Alongside criticism that developer hiring uses too many formal evaluation items, a claim proposed making proficiency in one language the more important criterion.
  • Observed response: “Multiple evaluation criteria are meaningless; what matters is learning Rust and becoming more intelligent.”
  • Analysis 1 — Category mistake: Knowledge and experience in Rust are learned domain-specific proficiency. Equating them with general intelligence or total developer competence treats distinct psychological and occupational constructs as one.
  • Analysis 2 — Causal leap: Even if certain abilities are observed among Rust learners, it remains necessary to distinguish whether Rust learning caused them or whether they reflect prior knowledge, educational opportunity, interest, and self-selection.
  • Analysis 3 — Single-metric reduction: It reduces software-development performance to proficiency in one language, excluding requirements analysis, design, debugging, testing, operations, security, collaboration, and domain knowledge.
  • Analysis 4 — Self-contradiction: While criticizing excessive multiple criteria as harmful to the industry, it evaluates all developers by one criterion whose job validity has not been established. The issue is not the number of criteria but job relevance and predictive validity.
  • Conditionally valid element: If the role requires immediately working in a Rust codebase, evaluating Rust proficiency is reasonable. The result is evidence of capability for that role, not of general intelligence or human superiority.
  • Discursive function: By depicting study of one technology as ascent in intellectual status and classifying non-users as inferior, it turns testable discussion of technology choice and hiring criteria into identity competition.

Case 7: Overgeneralizing an organizational-selection hypothesis and insulting a group

  • Context: A claim criticized how irrational work structures and internal politics in software organizations affect talent retention and capability growth.
  • Observed response: “Most people in software are of low intelligence and cannot even learn a particular language; all normal people leave, only incompetent people remain, and experienced employees learn politics rather than design.”
  • Analysis 1 — Testable structural hypothesis: The hypothesis that poor working conditions, unfair evaluation, overload, and punishment for raising problems can impede retention and learning is empirically testable. The demand that employers inspect the environment rather than blame individuals alone for hiring failures or quality problems can also be conditionally valid.
  • Analysis 2 — Hasty generalization and asserted selection effect: It concludes from experiences in some organizations or online cases that all competent people leave the industry and only incompetent people remain. In reality, job satisfaction, compensation, alternatives, organizational embeddedness, and personal constraints all affect leaving and staying.
  • Analysis 3 — Substitution of the measured construct: It turns organizational behavior—leaving or staying—into evidence of intelligence, then uses proficiency in one language as another proxy for intelligence. Because neither step is directly measured, the conclusion merely repeats its premise.
  • Analysis 4 — Single-cause account: It fails to distinguish experienced employees’ design skill, tacit knowledge, coordination capacity, and political behavior, reducing all accumulated experience to power struggle. The existence of organizational politics does not negate professional development.
  • Analysis 5 — False choice of responsibility: Organizational responsibility and individual responsibility for professional development and conduct can coexist. Recognizing only one side overlooks improvable causes.
  • Discursive function: Although it raises structural problems, it classifies all practitioners as intellectually and morally inferior, turning verifiable organizational analysis into insult and ranking by technical identity.

Case 8: Self-sealing argument and motive attribution to dissent

  • Context: In a debate about a language’s advantages and learning value, a claim explained criticism of the language by the critic’s low intelligence and inferiority complex.
  • Observed response: “A normal programmer recognizes Rust’s superiority and its value to learn. People disparage or reject Rust because they are less intelligent, and they react negatively when told Rust is good because their inferiority has been exposed.”
  • Analysis 1 — Circular definition of qualification: It defines people who agree with Rust as normal and dissenters as inferior, then reuses that classification as evidence of Rust’s superiority and an intelligence difference. The conclusion is already embedded in the premise.
  • Analysis 2 — Genetic fallacy and motive attribution: It does not rebut criticism about performance, productivity, ecosystem, or application conditions, but devalues the claim by presuming it arose from an inferiority complex. A speaker’s motive cannot substitute for judging the content’s validity.
  • Analysis 3 — Self-sealing structure: Agreement becomes evidence for the claim; disagreement becomes evidence of inferiority; discomfort and denial become further evidence of inferiority or defensiveness. No possible observation is allowed to refute the claim, so it cannot be tested as a technical hypothesis.
  • Analysis 4 — Deletion of conditional judgment: Rust’s advantages and learning value can vary with the project’s defect model, performance requirements, ecosystem, staffing, and transition cost. Removing these conditions and defining a single conclusion as normal converts engineering choice into intellectual rank.
  • Discursive function: It absorbs every counterargument about technical strengths and weaknesses into a psychological defect of the opponent, protecting the existing belief and distributing participation rights according to agreement.

Case 9: Misuse of proxy measures, national generalization, and stigmatizing analogy

  • Context: An organizational criticism that nontechnical evaluators fail to judge software-developer performance and thereby lower industry quality was expanded into claims about the intelligence of developers in one country and their attitude toward Rust.
  • Observed response: “People who work overtime to recover are recognized more than those who prevent problems, and obscure abbreviations and complex code look more professional than readable code. This evaluation structure has turned Korean programmers into a low-intelligence group that only caters to customer feelings instead of solving technical problems.”
  • Analysis 1 — Testable evaluation hypothesis: Organizations may reward visible recovery more than prevention or reward readily observable activity and appearance rather than actual quality. This hypothesis can be tested using evaluation criteria, incident recurrence, follow-up actions, and quality data.
  • Analysis 2 — Incident heroism and outcome bias: A responder’s ability and effort deserve recognition, but the occurrence of an incident can make recovery visible while prevention remains invisible. Long-term evaluation should include prevention, recurring failures, and post-incident actions together with response speed.
  • Analysis 3 — Proxy metrics and displays of complexity: Overtime, code volume, difficult terminology, and obscure structure are not sufficient conditions for expertise. Rewarding these signals instead of outcomes can cause people to optimize the metric and sacrifice maintainability and simplicity.
  • Analysis 4 — Hasty national generalization: A few companies and online groups encountered by an individual do not represent all Korean programmers. Without comparison samples and control of institutional variables, no conclusion about an entire nation’s intelligence or technical level follows.
  • Analysis 5 — Causal leap to Rust: The existence of distorted evaluation does not establish either the cause of criticism of Rust or Rust’s universal superiority. Organizational evaluation and language selection are separate claims requiring separate data and comparison criteria.
  • Analysis 6 — Category error about service work: Coordinating customer and stakeholder requirements is part of software engineering. Requirements distortion or excessive emotional labor can be criticized, but service elements themselves cannot be equated with technical incompetence.
  • Analysis 7 — Stigmatizing analogy: Analogies that demean disabled people or ridicule care relationships do not explain organizational incentives and instead transfer stigma to groups unrelated to the analysis. Such language weakens the verifiability and persuasiveness of structural criticism.
  • Discursive function: It raises a potentially valuable problem with evaluation systems, then expands it into a hierarchy of nationality, intelligence, and language identity, converting organizational analysis into justification for group insult.

Case 10: Accumulating industrial success cases, causal attribution, and declaring a standard

  • Context: An article urging Rust study and adoption on the basis of memory safety, industry adoption, and government recommendations listed Android, Discord, Cloudflare, AWS, the Linux kernel, vulnerabilities, and ecosystem size in sequence.
  • Observed response: “Android’s vulnerability ratio and Rust vulnerability density, Discord and Pingora performance, Firecracker startup time, Linux kernel adoption, and government recommendations all point in the same direction. The question is no longer whether to use Rust, but how long to trust unverifiable code; now the side not using Rust must justify the exception.”
  • Analysis 1 — Conditionally strong evidence: There are real cases in which Rust contributed to memory safety, predictable latency, resource efficiency, and development stability in new high-risk systems code. Reducing it to a fashion or hobby language is also inconsistent with the evidence.
  • Analysis 2 — Mixed attribution of results: A service rewrite changes not only the language but often data structures, connection pools, multithreaded architecture, cache size, and operating practices. Treating the whole before-and-after difference as a language effect prevents separation of architecture and implementation effects.
  • Analysis 3 — Combining different denominators: Android vulnerability ratios, code-density estimates based on pre-release potential vulnerabilities, operational metrics for a particular service, and developer-population estimates describe different populations and measurement methods. Several numbers pointing in one direction do not become one universal effect size.
  • Analysis 4 — Precision laundering of sources: Presenting a P99 reduction absent from the original text, a developer count from another survey, a CVE not attributed to Rust, or an unconfirmed roadmap with precise numbers and years may look exact, but precision that does not match the original source does not strengthen evidence.
  • Analysis 5 — The two-sided meaning of unsafe: Marking unsafe in a small area and concentrating audit there is a real advantage. But an incorrect safety contract can propagate through safe APIs and shared state, so the audit scope must include invariants and call boundaries rather than merely the number of lines inside braces.
  • Analysis 6 — Distinguishing policy direction from a single-language mandate: Government recommendations to adopt memory-safe languages and DARPA research on C-to-Rust are important directional signals. Turning recommendations covering multiple memory-safe languages or a research objective into mandatory Rust for every system requires an additional argument.
  • Analysis 7 — Levels of technical default: Making memory safety a default requirement for new high-risk systems code, prioritizing Rust for consideration in particular domains, and making Rust the normative default for every existing system are different propositions. Their burdens of proof and exception conditions must be separated.
  • Discursive function: Listing genuinely strong industry results broadly while removing the conditions and source differences can make a conditional technology choice appear to be a historically settled single standard. This raises the evidence burden for dissenters while leaving the extra premises of universalization unexamined.

  1. A memory-management technique in which a runtime tracks object reachability and related state to reclaim memory that is no longer in use automatically. ↩

  2. Rust Core Team, Laying the foundation for Rust’s future; Aaron Turon, Abstraction without overhead: traits in Rust. The former explains Rust’s origin as a Mozilla Research project and its transition to an independent project; the latter describes the design axes of memory safety, data-race prevention, and abstraction cost. ↩

  3. The Rust Reference, Behavior considered undefined and Behavior not considered unsafe; The Rustonomicon, How Safe and Unsafe Interact. The official documentation also states the soundness responsibilities of unsafe contracts, the incompleteness of the semantic rules, and the distinction between memory unsafety and deadlock, resource leaks, and logical errors. ↩ ↩2

  4. Aaron Turon, Abstraction without overhead: traits in Rust. The article presents zero-cost abstraction as a core Rust design principle, but does not universally guarantee the performance outcome of a particular program. ↩

  5. The Rustonomicon, Data Races and Race Conditions; The Rust Programming Language, Using Threads to Run Code Simultaneously. The official documentation distinguishes Safe Rust’s prevention of data races from the separate problems of general race conditions and deadlock. ↩

  6. The Rust Programming Language, Understanding Ownership, References and Borrowing, and Validating References with Lifetimes. The official documentation distinguishes the roles of ownership, access permissions, and reference validity, and explains that lifetime annotations do not change how long references actually live. ↩ ↩2 ↩3

  7. Rust Project Goals, Stabilize and model Polonius Alpha and The Borrow Checker Within. The official 2026 goals explain that conditional borrowing and lending iterators rejected by the current NLL analysis are intended to be accepted, while some patterns requiring full flow sensitivity remain future work. ↩

  8. The Rust Programming Language, Rc<T>, the Reference-Counted Smart Pointer, RefCell<T> and the Interior Mutability Pattern, Reference Cycles Can Leak Memory, and Shared-State Concurrency. These documents describe runtime borrow checking, reference counting, cyclic leaks, the performance cost of atomic reference counting, locking, and the possibility of deadlock. ↩

  9. Standard C++ Foundation, What is the zero-overhead principle?; Aaron Turon, Abstraction without overhead: traits in Rust. These sources describe the principle as a C++ design principle and a related goal for Rust abstractions; they do not specify a universal performance result for a particular program. ↩ ↩2

  10. Rust Compiler Development Guide, Monomorphization; The Cargo Book, Profiles; The rustc book, Codegen Options; Richard Uhlig et al., Instruction Fetching: Coping with Code Bloat. These sources describe the compile-time and binary-size costs of monomorphization, trade-offs involving optimization, code-generation units and LTO, and the possible effects of code size on instruction fetching. ↩ ↩2 ↩3

  11. The Rust Reference, Trait object types; Rust standard-library keyword documentation, dyn; Rust standard library, Box<T>, Vec<T>, and String; The Rust Reference, Panic. These documents distinguish runtime dispatch through trait objects, heap allocation and reallocation, and the panic behavior of out-of-bounds indexing. ↩ ↩2

  12. The Rust Programming Language, Performance in Loops vs. Iterators. The official example observes similar performance for one workload and states that a broader comparison would require varied inputs and conditions. ↩

  13. The Rust Programming Language, Defining an Enum and Recoverable Errors with Result; Rust standard library, Option and Result; The Rust Reference, Pointer types. The official documentation distinguishes state modeling with Option and Result, the must_use warning for an unused Result, and the boundary between non-null references and raw pointers that may be null. ↩ ↩2 ↩3

  14. The Rust Reference, match expressions, Patterns, and The non_exhaustive attribute. These documents describe the conditional behavior of pattern guards, exhaustiveness checking, wildcards, and API-evolution rules for external non-exhaustive types. ↩

  15. The Rust Reference, Behavior considered undefined. The reference classifies constructing invalid enum discriminants, references, and typed values as undefined behavior and explains that implementers must preserve validity premises across unsafe and FFI boundaries. ↩

  16. The Rust Reference, Type layout and Panic; Rust standard library, Option representation, Option::unwrap, and Result::unwrap. These sources distinguish the limited guarantees of default enum layout, null-pointer optimization for particular types, and the panic behavior and panic strategy of the unwrap family. ↩ ↩2

  17. The Cargo Book, Why Cargo Exists and cargo. The official documentation defines Cargo as Rust’s package manager and build tool and describes the scope in which it provides dependency downloading, building, checking, testing, documentation, packaging, and publishing through a common command system. ↩

  18. The Cargo Book, Dependency Resolution, Features, FAQ — Why have Cargo.lock in version control?, SemVer Compatibility, Rust Version, and cargo. These documents distinguish the determinism boundary of the lockfile, differences in offline resolution, duplicate versions, feature unification, the SemVer premise, and the limits of rust-version/MSRV. ↩ ↩2 ↩3 ↩4 ↩5

  19. The Cargo Book, Build Scripts and Specifying Dependencies; The Rust Reference, Procedural macros. The official documentation describes execution of build.rs, native-library linking, target-specific and build dependencies, and security boundaries such as compile-time execution and file access by procedural macros. ↩ ↩2 ↩3 ↩4

  20. The Cargo Book, Registry Index, Publishing on crates.io, cargo owner, and The Manifest Format. These sources describe the scope of SHA-256 checksums for .crate files, permanent retention and yanking of published versions, ownership management, and license metadata. ↩ ↩2

  21. The Cargo Book, Cargo Home and cargo vendor; RustSec, cargo audit and RustSec Advisory Database; CMake, cmake(1); Meson, Overview; Microsoft, vcpkg overview; Conan, Conan 2 documentation. These sources support the comparison boundaries concerning caches, vendoring, vulnerability-audit tooling, and the existence of actual build and package-management tools in C and C++ ecosystems. ↩ ↩2 ↩3

  22. The Rust Programming Language, What Is Ownership?, References and Borrowing, and Reference Cycles Can Leak Memory; The Rust Reference, Behavior considered undefined; The Rustonomicon, Data Races and Race Conditions. These sources distinguish ownership-based memory management without a GC, the boundaries of data races and undefined behavior, and the fact that general race conditions and memory leaks remain outside the guarantee. ↩ ↩2

  23. C++ Core Guidelines, C++ Core Guidelines. The guidelines describe modern C++ resource-safety practices including RAII and resource handles, automatic resource management through smart pointers and containers, and reducing the use of raw owning pointers and direct new/delete. This source is used to avoid comparisons implying that C++ lacks safer resource-management techniques; it does not mean that these recommendations provide the same guarantee as Rust’s compiler enforcement. ↩

  24. Oracle Java SE, Garbage Collector Implementation and Available Collectors. The official documentation treats throughput and latency as separate garbage-collection metrics and shows that trade-offs among pause time, throughput, and memory use, as well as applicability conditions, differ among collectors. ↩

  25. The Cargo Book, Why Cargo Exists and cargo; The rustup book, Components, Profiles, and Overrides; The Rust Programming Language, Useful Development Tools. These sources describe the scope of Cargo’s common workflow, rustup’s toolchain/component management, rustfmt and Clippy in the default profile, installable rust-analyzer, and per-project toolchain specification through rust-toolchain.toml. ↩

  26. Rust Compiler Performance Working Group, Rust compiler performance survey 2025 results; Rust Survey Team, 2025 State of Rust Survey Results. The former reports Cargo-command usage and build/CI waiting costs from more than 3,700 responses; the latter addresses productivity-limiting issues based on 7,156 completed responses. Both surveys draw from self-selected Rust-related respondents, so they are not used as controlled cross-language comparisons or direct estimates of Cargo’s causal effect. ↩

  27. CMake, cmake(1) and CMake Presets; Meson, Overview; Microsoft, vcpkg overview and Manifest mode; Conan, Introduction. These sources show that the C/C++ ecosystem also has actual tools for building, testing, packaging, manifest-based dependency and version management, binary packages, and private repositories. ↩

  28. The rustup book, Cross-compilation; The Rust Programming Language, Installation. The official documentation explains that rustup target add may provide the target standard library while an external linker or SDK is still required, that ordinary Rust builds need a linker, and that some crates may require a C compiler. ↩

  29. Maxwell E. McCombs and Donald L. Shaw, The Agenda-Setting Function of Mass Media, Public Opinion Quarterly 36(2), 1972, pp. 176-187. The original study compared a survey of Chapel Hill voters during the 1968 U.S. presidential election with content analysis of the media they used, examining the relationship between media emphasis on issues and audience perceptions of issue importance. Applying “agenda setting” to Rust discourse in this book therefore requires comparable discourse material, a defined time period, measures of audience salience, and explicit limits on causal inference rather than mere repetition of expressions. ↩ ↩2

  30. Rust Core Team, Announcing Rust 1.0 Alpha; The Rust Programming Language, Fearless Concurrency; Rust Core Team, A new look for rust-lang.org; Rust Project, Rust Programming Language. These sources show the early value propositions of safety, performance, and concurrency; the official phrase “fearless concurrency”; the 2018 redesign of the website’s messaging and slogan; and the Performance, Reliability, and Productivity structure of the front page at the time of this revision. They document the content and changes of official messaging, not audience effects or the frequency of discourse across the community. ↩

  31. Rust Core Team, Laying the foundation for Rust’s future and Next steps for the Foundation Conversation; Rust Foundation, Hello World!; Rust Project, Governance. The 2020 sources describe Mozilla’s financial and legal sponsorship, the purpose of creating the Foundation, and the boundary intended to preserve the decision-making authority of most Rust teams; the 2021 launch source records the founding members and board composition at that time. The Governance page shows the Rust Project’s separate governance structure at the time of this revision. These sources document institutional support and structure; they do not independently measure effects on external trust or adoption. ↩ ↩2 ↩3 ↩4

  32. Rust Project, Code of conduct and Learn Rust; The Rust Programming Language, The Rust Programming Language. The Code of Conduct states behavior standards and moderation procedures for official Rust spaces, while the learning page and Book show the existence and scope of official learning resources. Their existence alone is not treated as evidence measuring community-wide behavior, reductions in barriers to entry, learning outcomes, or contributor retention. ↩

  33. The Rust Reference, Influences; The Rust Programming Language, What Is Ownership? and References and Borrowing; C++ Core Guidelines, C++ Core Guidelines. The Rust Reference lists C++ references, RAII, smart pointers, and move semantics as direct influences, and separately lists region-based memory management in ML Kit and Cyclone. The Rust Book explains the relationship between resource release through drop at the end of a scope and C++ RAII, while the C++ Core Guidelines define automatic resource management through RAII and resource handles. These sources are used to establish historical influence and the different locations of enforcement, not to attribute the first invention of the general concept of “ownership” to a particular language. ↩ ↩2

  34. Ada Resource Association, Ada 83 Rationale, LRM, & Guides; Ada Reference Manual, Introduction; Ada 95 Rationale, Part Two, Chapter 3; Altran Praxis/AdaCore, SPARK - The SPADE Ada Kernel; SPARK User’s Guide, Applying SPARK in Practice; AdaCore, Programming Languages for Space Software. The Ada material documents the 1983 standard, the original goals of reliability, maintainability, and efficiency, and the tradition of run-time checks for types and subtypes; the older SPARK document records that the original SPARK was based on Ada 83. Current SPARK material explains the scope and assumptions of AoRTE and contract proofs, while AdaCore’s current overview states that later SPARK pointer support was based on the Rust ownership model. This footnote therefore uses Ada/SPARK to distinguish historical comparison and verification scope rather than treating it as a direct ancestor of Rust ownership. ↩ ↩2

  35. The Rust Reference, Influences; Rust standard library, Option and Result; OCaml, Options. What the Rust Reference explicitly identifies is influence from SML/OCaml algebraic data types, pattern matching, and type inference. The official Rust and OCaml material shows the variant structure of Option/Result and option, respectively, but these sources alone do not establish a direct lineage for Rust’s concrete error-handling APIs or for monadic error handling as a whole. ↩ ↩2

  36. The Rust Reference, Behavior considered undefined. This document lists data races, access through dangling or misaligned pointers, aliasing violations, calls using the wrong ABI, and creation of invalid values among examples of UB, and states that UB itself is not permitted even inside unsafe. It also describes the soundness boundary in terms of preventing a safe client from causing UB when safe code interacts with an unsafe implementation. ↩ ↩2

  37. The Rust Reference, Array and array index expressions and The unsafe keyword. Ordinary array and slice indexing performs a run-time bounds check when the result cannot be determined statically and panics on failure, while an unsafe function such as get_unchecked imposes the additional safety condition that the index be in bounds. ↩

  38. The Rust Reference, The unsafe keyword and Behavior considered undefined. The Reference explains that constructs such as unsafe fn and unsafe trait define additional safety conditions, while constructs such as unsafe blocks and unsafe impl indicate proof obligations that those conditions have been satisfied. It also defines unsafe code as sound when safe clients cannot use it to cause UB. ↩ ↩2

  39. The Rust Reference, External blocks and Application binary interface. External blocks are the boundary for foreign-item declarations, and the Rust 2024 Edition requires unsafe extern. Rust defines several ABIs, including "C", "system", and "C-unwind"; verifying that an ABI and signature match the actual external-code contract is a separate responsibility at that boundary. ↩ ↩2

  40. Cargo Reference, Profiles: panic; Rust standard library, std::panic::catch_unwind, UnwindSafe, and JoinHandle::join; The Rust Reference, Destructors. These sources describe the difference between unwind and abort strategies, the limitation that catch_unwind catches only unwinding panics, the scope in which a thread panic can be observed through join, and the boundary that soundness must not depend on destructors necessarily running. ↩ ↩2 ↩3

  41. The Rust Reference, Behavior not considered unsafe; Rust standard library, std::mem::forget; The Rust Programming Language, Reference Cycles Can Leak Memory. These sources state that leaks and failure to run destructors are not the same as Rust’s unsafe category, and that Safe Rust can still leak resources through mechanisms such as reference cycles or mem::forget. ↩ ↩2

  42. The Rust Reference, Behavior not considered unsafe; Cargo Reference, Profiles: overflow-checks. The Reference distinguishes deadlocks, memory/resource leaks, and termination without running destructors from unsafe. It also explains that when debug_assert! is enabled overflow checking must panic, while in other builds the implementation may panic or perform defined two’s-complement wrapping; Cargo profiles control run-time overflow checking with the overflow-checks setting. ↩ ↩2

  43. The Rustonomicon, Data Races and Race Conditions. It classifies data races as UB while explicitly distinguishing them from general race conditions, which Safe Rust does not prevent. ↩

  44. Rust Security Response WG, Security advisory for the standard library (CVE-2024-24576) and Security advisory for the standard library (CVE-2024-43402). The first advisory records the conditions under which Command argument escaping for Windows batch files was insufficient and the fix in Rust 1.77.2; the second records a particular bypass of that mitigation and the additional fix in Rust 1.81.0. These cases are used only as bounded examples that a safe API’s logical and security contract is distinct from memory safety, not as measurements of the frequency of memory-safety defects. ↩

  45. Martin Fowler, Definition Of Refactoring, 2004. Fowler defines refactoring as changing the internal structure without changing observable behavior. This definition is used here to distinguish language replacement and new implementations from refactoring in the narrow sense. ↩

  46. C++ Core Guidelines project, C++ Core Guidelines; LLVM/Clang, Clang-Tidy, AddressSanitizer, ThreadSanitizer, and UndefinedBehaviorSanitizer. The Core Guidelines describe modern C++ resource, memory, and concurrency rules and gradual adoption; the Clang documentation describes the diagnostic scope and instrumentation costs of the relevant analyses and sanitizers. The AddressSanitizer and ThreadSanitizer documentation each states that its runtime is not designed to be linked into production executables and was not developed under security-sensitive constraints. These sources are used to avoid conflating tool-based detection with language-level guarantees, or testing instrumentation with production deployment. ↩ ↩2

  47. Android Open Source Project, Memory safety, updated 2026-07-16; Google Security Blog, Rust in the Android platform, 2021; Google Security Blog, Safer with Google: Advancing Memory Safety, 2024. Android combines memory-safe languages for new native code with detection and hardening for existing C/C++, as well as sandboxing and hardware mitigations. This is used as a bounded large-platform example showing that a mixed strategy is possible, not as evidence that it is the optimal strategy for every codebase. ↩ ↩2

  48. Martin Fowler, Strangler Fig, 2024 update. The article describes the practical difficulty of discovering the detailed specification of an important existing system and the risk of a large cut-over, and presents gradual replacement as a design pattern. It is used here to define a change-strategy option, not as population-level evidence that gradual migration universally has lower cost or higher quality than a full rewrite. ↩

  49. Google Security Blog, Rust/C++ interop in the Android Platform, 2021; Google Security Blog, Deploying Rust in Existing Firmware Codebases, 2024. The first analyzes interoperability as a practical requirement without assuming a wholesale C++ rewrite in Android; the second describes gradual Rust adoption that prioritizes new and high-risk code while retaining a C API through a shim. The first explicitly limits its analysis to the Android platform, so further evidence is required before generalizing either strategy to other codebases. ↩

  50. Google Security Blog, Bare-metal Rust in Android, 2023. The Android team records rewriting the AVF protected-VM firmware in Rust. This is used as a bounded example of a rewrite chosen at a specific security boundary, not as evidence that a full rewrite of Android or large legacy systems in general is justified. ↩

  51. AdaCore, SPARK User’s Guide 27.0w — Levels of Software Assurance and Prove Absence of Run-Time Errors. The documentation distinguishes Stone, Bronze, Silver, Gold, and Platinum as different verification objectives, states that Storage_Error is outside Silver AoRTE analysis, and explains that Platinum depends on contracts adequately covering the functional requirements. ↩ ↩2 ↩3

  52. Ada Resource Association, Ada 2022 Reference Manual, especially 11.5 Suppressing Checks, 11.4 Exception Handling, 9 Tasks and Synchronization, C.6 Shared Variable Control, and 13.9.1 Data Validity. The Ada 2022 Reference Manual corresponds to ISO/IEC 8652:2023(E). These sources are used to distinguish language-defined check failures and exception semantics, the erroneous-execution boundary created by check suppression, and the limits of atomic/protected synchronization and unchecked access. ↩ ↩2 ↩3

  53. AdaCore, SPARK User’s Guide 27.0w — Managing Assumptions and How to Write Subprogram Contracts. GNATprove results can depend on modular contracts and assumptions about unanalyzed code or the external environment; the documentation requires these assumptions to be justified separately through testing, manual analysis, review, or other suitable evidence. ↩ ↩2

  54. AdaCore, SPARK User’s Guide 27.0w — Concurrency and Ravenscar Profile. The documentation restricts tasking to avoid erroneous concurrent access to shared data, that is, data races, while its atomic read-modify-write example explicitly shows that a lost-update race condition can remain without a data race. It also describes the Priority Ceiling Protocol for single-core Ravenscar protected-object locking to ensure absence of deadlock and explains that GNATprove checks potentially blocking actions and several tasking restrictions. At the same time, it documents the implementation limitation that current project-wide tasking analysis depends on the with closure of the source file being processed and may miss related checks in some disconnected library/task configurations. Thus documented data-race or deadlock guarantees are not extended to general concurrency correctness or to a whole-system guarantee outside the analyzed context. ↩ ↩2

  55. The complexity of Rust’s async model is recognized within the project as an area for improvement. Jon Gjengset, for example, devoted a Crust of Rust talk, “The Why, What, and How of Pinning in Rust,” to explaining Pin in detail. Core developer Niko Matsakis has also repeatedly discussed related visions and improvements on his blog. The need for such explanation is evidence that these concepts remain a learning hurdle within the Rust community. ↩

  56. Matthew Prince, “Cloudflare outage on November 18, 2025,” Cloudflare Blog, 2025-11-18. https://blog.cloudflare.com/ko-kr/18-november-2025-outage/ ↩

  57. Package sizes use the “Installed size” values in the official Alpine Linux v3.22 stable package database. The purpose is not to compare the latest performance at a particular moment, but to show the structural tendency of ecosystem design choices to affect binary size. Because small patch and version changes within a stable release do not substantially alter that underlying tendency, one stable release is used for reproducibility and consistency. The package versions are those listed in the table. ↩

  58. The result was obtained by extracting linux-6.15.5.tar.xz and running cloc . with no additional options in the source root. This information is included so readers can reproduce the analysis. ↩

  59. Ferrous Systems, Ferrocene Part 3: The Road to Rust in mission- and safety-critical, 2021; AdaCore, AdaCore and Ferrous Systems Joining Forces to Support Rust, 2022, and Announcements around Rust, 2023; Ferrous Systems, Officially Qualified - Ferrocene, 2023; Ferrocene, Qualification Plan and Safety Manual - Qualification scope; Ferrous Systems, Ferrocene 26.02.0 now available!, 2026. Ferrous Systems publicly announced Ferrocene with its subsidiary Critical Section GmbH in 2021 as a project to qualify the Rust language and compiler for safety-critical domains. AdaCore and Ferrous Systems announced joint development in 2022 and the end of that joint-development partnership in 2023. Current public qualification material documents the compiler’s ISO 26262 ASIL D/TCL 3, IEC 61508 class T3, and IEC 62304 scope together with the Safety Manual’s usage constraints. Ferrocene’s 2026 material describes TÜV SÜD qualification for ISO 26262 ASIL D, IEC 61508 SIL 3, and IEC 62304 Class C; it separately identifies the certified core subset at ISO 26262 ASIL B and IEC 61508 SIL 2 and describes DO-178C DAL C as support for customer certification efforts. This does not mean that an individual application or system built with Ferrocene automatically receives the corresponding safety certification. ↩ ↩2 ↩3

  60. CMU Software Engineering Institute, “The Growing Importance of Sustaining Software for the DoD: Part 1.” It explains that software does not physically wear out, but requires continuing maintenance because hardware and execution environments age, requirements change, and defects and performance problems emerge. https://sei.cmu.edu/blog/the-growing-importance-of-sustaining-software-for-the-dod-part-1/ ↩

  61. Robert C. Seacord et al., “Legacy System Modernization Strategies,” CMU/SEI-2001-TR-025. It compares advantages and disadvantages of several alternatives, including incremental modernization, in light of the scale, complexity, and vulnerability of large legacy systems. https://www.sei.cmu.edu/library/legacy-system-modernization-strategies/ ↩

  62. The term silver-bullet narrative is used here as an analytical term from the sociology of technology, not to disparage a particular technology or community. It denotes the tendency to believe that one simplified technical solution exists for a complex problem and is related to technological triumphalism. The term is used to describe the structure of the discourse under analysis. ↩

  63. The discourse analysis in Part 4 does not target particular individuals or private communities. It is based on qualitative observation of recurring argumentative patterns in publicly accessible sources: discussions on platforms such as X (formerly Twitter), Hacker News, and Reddit (for example r/rust and r/programming); numerous technical blog posts on “Why Rust?”; and question-and-answer sessions at relevant technical conferences. Its purpose is not to measure statistical frequency but to understand the structure and logic of the discourse. ↩

  64. Oracle, “JavaServer Pages Technology”; PHP Documentation Group, “What is PHP and what can it do?”. JSP constructs responses using server-side objects, and the PHP documentation explains that PHP code is executed on the server and its result sent to the client. https://docs.oracle.com/javaee/5/tutorial/doc/bnagx.html, https://www.php.net/manual/en/intro-whatis.php ↩

  65. “M$” was an expression used in parts of the Linux and open-source communities in the 1990s to criticize Microsoft’s commercial policies. Replacing the “s” in Microsoft with the dollar sign (“M$,” “Micro$oft”) conveyed criticism of perceived commercialism. ↩

  66. RTFM abbreviates “Read The Fucking Manual.” It was often used in 1990s hacker culture to demand that users asking elementary questions find the answer themselves, illustrating an exclusionary aspect of that culture. ↩

  67. Evaluating a claim by its source or alleged motive rather than its content is the genetic fallacy. See Appendix, “Case 2: Genetic Fallacy.” ↩

  68. Attacking the capacity or character of the person making a claim instead of the validity of the criticism is an ad hominem fallacy. See Appendix, “Case 1: Ad Hominem.” ↩

  69. Antony Flew, Thinking about Thinking: Or, Do I Sincerely Want to Be Right?, Fontana/Collins, 1975. Flew’s “No-true-Scotsman Move” refers to excluding a counterexample by retrospectively changing the definition of a “true” member rather than accepting the counterexample to a generalization. ↩

  70. Ronny Scherer, Fazilat Siddiq, and Bárbara Sánchez Viveros, “The Cognitive Benefits of Learning Computer Programming: A Meta-Analysis of Transfer Effects,” Journal of Educational Psychology, 111(5), 2019, pp. 764–792, DOI: 10.1037/edu0000314. The study reported an overall transfer effect of g = 0.49, a near-transfer effect of g = 0.75, and a far-transfer effect of g = 0.47. It did not test a Rust-specific effect or an increase in general intelligence, and differences by study design and control-group type must also be considered. ↩

  71. Paul R. Sackett, Charlene Zhang, Christopher M. Berry, and Filip Lievens, “Revisiting Meta-Analytic Estimates of Validity in Personnel Selection: Addressing Systematic Overcorrection for Restriction of Range,” Journal of Applied Psychology, 107(11), 2022, pp. 2040–2068, DOI: 10.1037/apl0000994. Analyzes how traditional estimates of the predictive validity of selection methods may have been systematically overcorrected. ↩ ↩2

  72. Thomas Claburn, “Rust Foundation apologizes for bungled trademark policy,” The Register, April 17, 2023. https://www.theregister.com/2023/04/17/rust_foundation_apologizes_trademark_policy/ ↩

  73. Rust Foundation, “Rust Trademark Policy Draft Revision & Next Steps,” Rust Foundation Blog, April 11, 2023. https://rustfoundation.org/media/rust-trademark-policy-draft-revision-next-steps/ ↩

  74. National Security Agency, “Software Memory Safety,” CSI-001-22, November 2022. https://media.defense.gov/2022/Nov/10/2003112742/-1/-1/0/CSI_SOFTWARE_MEMORY_SAFETY.PDF ↩

  75. Office of the National Cyber Director, “Back to the Building Blocks: A Path Toward Secure and Measurable Software,” February 2024. https://bidenwhitehouse.archives.gov/wp-content/uploads/2024/02/Final-ONCD-Technical-Report.pdf ↩

  76. Jeff Vander Stoep and Alex Rebert, “Eliminating Memory Safety Vulnerabilities at the Source,” Google Online Security Blog, September 25, 2024. Reports the fall in Android memory-safety vulnerabilities from 76% to 24% over six years and explains a strategy prioritizing safe new code. https://security.googleblog.com/2024/09/eliminating-memory-safety-vulnerabilities-Android.html ↩

  77. Jeff Vander Stoep, “Rust in Android: move fast and fix things,” Google Online Security Blog, November 13, 2025. Presents the 2025 Android vulnerability share, approximately five million lines of Rust, a density estimate based on one potential pre-release vulnerability, and data on review and rollback. https://security.googleblog.com/2025/11/rust-in-android-move-fast-fix-things.html ↩

  78. Jesse Howarth, “Why Discord is switching from Go to Rust,” Discord Blog, February 4, 2020. Describes the cache and GC conditions of a specific Read States service and its rewrite, while explicitly not recommending that every system be rewritten. https://discord.com/blog/why-discord-is-switching-from-go-to-rust ↩

  79. Yizhou Zhang, “How we built Pingora, the proxy that connects Cloudflare to the Internet,” Cloudflare Blog, September 19, 2022. Explains multiple causes of CPU and memory reduction, including connection reuse, multithreading, and removal of a language boundary. https://blog.cloudflare.com/how-we-built-pingora-the-proxy-that-connects-cloudflare-to-the-internet/ ↩

  80. Arun Gupta, “Announcing the Firecracker Open Source Technology: Secure and Fast microVM for Serverless Computing,” AWS Open Source Blog, November 26, 2018. Reports startup below 125 milliseconds for the default microVM size and minimal device model on i3.metal. https://aws.amazon.com/blogs/opensource/firecracker-open-source-secure-fast-microvm-serverless/ ↩

  81. Miguel Ojeda, “[PATCH] rust: conclude the Rust experiment,” Linux Kernel Mailing List, December 13, 2025. Describes the end of the experiment and continued support while identifying incomplete combinations and remaining work. https://lists.openwall.net/linux-kernel/2025/12/13/212 ↩

  82. Ilia Afanasiev, “Is Rust the Future of Programming?”, JetBrains Blog, May 13, 2025. Based on 2024 Developer Ecosystem data, estimates 2.267 million Rust users in the previous twelve months and 709,000 primary-language users. https://blog.jetbrains.com/rust/2025/05/13/is-rust-the-future-of-programming/ ↩

  83. Rust Survey Team, “2025 State of Rust Survey Results,” Rust Blog, March 2, 2026. Reports 7,156 responses and states the limits of extrapolating from the sample. https://blog.rust-lang.org/2026/03/02/2025-State-Of-Rust-Survey-results/ ↩

  84. National Vulnerability Database, “CVE-2025-30388.” Records a heap buffer overflow and local attack vector in Windows Win32K-GRFX without attributing it to a Rust implementation. https://nvd.nist.gov/vuln/detail/CVE-2025-30388 ↩

  85. Ubuntu Security, “CVE-2025-68260.” Describes how parallel access to an unsafe list-removal operation in Rust Binder caused a data race and pointer corruption. https://ubuntu.com/security/CVE-2025-68260 ↩

  86. Rust Project Goals, “Just add async,” 2026. Describes gaps between synchronous and asynchronous code, the limits of synchronous destructors, and exploration targets for 2026–2027. https://rust-lang.github.io/rust-project-goals/2026/roadmap-just-add-async.html ↩

  87. National Security Agency and Cybersecurity and Infrastructure Security Agency, “Memory Safe Languages: Reducing Vulnerabilities in Modern Software Development,” June 24, 2025. Recommends reducing vulnerabilities through adoption of multiple memory-safe languages. https://www.nsa.gov/Press-Room/Press-Releases-Statements/Press-Release-View/Article/4223298/nsa-and-cisa-release-csi-highlighting-importance-of-memory-safe-languages-in-so/ ↩

  88. Defense Advanced Research Projects Agency, “TRACTOR: Translating All C to Rust.” Describes the goals and evaluation structure of a research program for automatically translating legacy C into Rust. https://www.darpa.mil/research/programs/translating-all-c-to-rust ↩

  89. Microsoft Security Response Center, “A Proactive Approach to More Secure Code,” 2019-07-16. https://msrc.microsoft.com/blog/2019/07/16/a-proactive-approach-to-more-secure-code/ ↩

  90. Google has emphasized memory safety across several projects.
    Chrome: “The Chromium project finds that around 70% of our serious security bugs are memory safety problems.” The Chromium Projects, “Memory-Safe Languages in Chrome,” https://www.chromium.org/Home/chromium-security/memory-safety/ (continuously updated).
    Android: “Memory safety bugs are a top cause of stability issues, and consistently represent ~70% of Android’s high severity security vulnerabilities.” Google Security Blog, “Memory Safe Languages in Android 13,” 2022-12-01. https://security.googleblog.com/2022/12/memory-safe-languages-in-android-13.html ↩

  91. Discord Engineering, “Why Discord is switching from Go to Rust,” 2020-02-04. https://discord.com/blog/why-discord-is-switching-from-go-to-rust ↩

  92. Linkerd, “Under the Hood of Linkerd’s Magic,” Linkerd Docs. https://linkerd.io/2/reference/architecture/#proxy ↩

  93. IEEE Computer Society, Guide to the Software Engineering Body of Knowledge (SWEBOK Guide) V4.0, 2024. The current guide presents eighteen knowledge areas including requirements, architecture, design, construction, testing, operations, maintenance, and security. https://www.computer.org/education/bodies-of-knowledge/software-engineering ↩

  94. Miikka Kuutila et al., “Staying or Leaving? How Job Satisfaction, Embeddedness and Antecedents Predict Turnover Intentions of Software Professionals,” Proceedings of the 48th IEEE/ACM International Conference on Software Engineering (ICSE 2026), 2026. Analyzes a cross-sectional survey of 224 geographically diverse software professionals and reports negative associations of job satisfaction and embeddedness with turnover intention. https://arxiv.org/abs/2512.00869 ↩

  95. Amy C. Edmondson, “Psychological Safety and Learning Behavior in Work Teams,” Administrative Science Quarterly, 44(2), 1999, pp. 350–383, DOI: 10.2307/2666999. Examines psychological safety, learning behavior, and performance in fifty-one manufacturing teams. ↩

  96. Ipek Ozkaya and Brigid O’Hearn, “5 Recommendations to Help Your Organization Manage Technical Debt,” Carnegie Mellon University Software Engineering Institute, 2024, DOI: 10.58012/7wn9-tk57. Recommends making debt visible, setting goals, creating measurement environments, and explicitly allocating resources to repayment. ↩

  97. Nicole Forsgren et al., “The SPACE of Developer Productivity: There’s More to It Than You Think,” ACM Queue, 19(1), 2021, pp. 20–48, DOI: 10.1145/3454122.3454124. Treats developer productivity as multidimensional rather than a single metric. ↩ ↩2

  98. John Lunney and Sue Lueder, “Postmortem Culture: Learning from Failure,” in Betsy Beyer et al., Site Reliability Engineering, O’Reilly Media, 2016. Describes recording contributing causes and prevention, focusing on systems rather than blame, and organizationally rewarding postmortems and preventive work. https://sre.google/sre-book/postmortem-culture/ ↩

  99. Raymond P. L. Buse and Westley R. Weimer, “Learning a Metric for Code Readability,” IEEE Transactions on Software Engineering, 36(4), 2010, pp. 546–558, DOI: 10.1109/TSE.2009.70. Builds a metric from readability judgments by 120 evaluators and examines correlations with code-change and defect measures. ↩

  100. Margaret-Anne D. Storey, Brian Houck, and Thomas Zimmermann, “How Developers and Managers Define and Trade Productivity for Quality,” Proceedings of ICSE-SEIP 2022, 2022. Compares by survey how developers and managers define productivity and quality. https://www.microsoft.com/en-us/research/publication/how-developers-and-managers-define-and-trade-productivity-for-quality/ ↩

  101. Lan Cheng et al., “What Improves Developer Productivity at Google? Code Quality,” Proceedings of ESEC/FSE 2022: Industry Track, 2022. A Google panel analysis linking code quality, technical debt, tools and support, communication, goals, and organizational processes with perceived productivity and reporting that quality improvement tended to precede productivity improvement. https://research.google/pubs/what-improves-developer-productivity-at-google-code-quality/ ↩