Rust: A Language for the Next 40 Years - Carol Nichols
ChariotSolutions
AI-assisted summary of Rust: A Language for the Next 40 Years - Carol Nichols — original source. Check the original for full context.
Source published:
Key ideas
- Microsoft security updates over a 12-year window revealed that roughly 70% of all vulnerabilities were caused by memory safety defects, underscoring that human discipline alone cannot fix C and C++ safety risks. (12:35)
- Rust guarantees compile-time memory safety without a garbage collector via its ownership and borrowing system, which eliminates use-after-free, double frees, and data races while matching C's execution performance. (16:04)
- The Rust Editions mechanism allows the language to evolve syntax and introduce reserved keywords without breaking backward compatibility, since all editions lower to a shared Mid-Level Intermediate Representation (MIR). (30:25)
- Mozilla's audit of Firefox's legacy styling engine revealed that 51 out of 69 historical vulnerabilities (roughly 74%) would have been prevented entirely had the component been written in Rust instead of C++. (35:43)
Detailed notes
## Background Published on YouTube by ChariotSolutions on May 9, 2019, this presentation features Carol Nichols speaking at Philly ETE 2019. The session covers what makes the Rust programming language unique, exploring its compile-time memory safety guarantees, how the Rust Editions mechanism enables continuous evolution without breaking backwards compatibility, and the companies deploying Rust for critical systems.
## TL;DR Drawing an extended parallel to the 19th-century railroad industry's shift from deadly manual braking to the automated Westinghouse air brake, Carol Nichols argues that software engineering must move beyond relying on human discipline to prevent memory safety bugs in C. She breaks down how Rust's ownership and borrow-checking model guarantees memory and concurrency safety without runtime garbage collection, freeing developers from excessive cognitive overhead. Nichols explains the architecture of Rust Editions, which lowers distinct language editions to a shared intermediate representation to ensure long-term stability without stagnation. Highlighting real-world enterprise adoption across tech giants like Mozilla, Amazon, and Microsoft, she concludes with an impassioned plea for the industry to embrace memory safety and stop repeating the same forty-year-old vulnerabilities.
## Atmosphere & style Nichols establishes an engaging, candid, and witty rapport with the audience, pairing deep technical analysis with playful self-deprecation about her Pittsburgh sports loyalties and her self-acknowledged bias as a member of the Rust Core Team. The talk weaves seamlessly between an evocative historical narrative of railroad disasters and detailed discussions of compiler internals, maintaining clarity and accessibility throughout. The emotional arc feels pragmatic and grounded rather than evangelistic, culminating in an earnest, realistic appeal for the software industry to overcome systemic inertia and finally eliminate preventable classes of bugs.
## Bulletin - [12:35](https://www.youtube.com/watch?v=A3AdN7U24iU&t=755s) Microsoft security updates over a 12-year window revealed that roughly 70% of all vulnerabilities were caused by memory safety defects, underscoring that human discipline alone cannot fix C and C++ safety risks. - [16:04](https://www.youtube.com/watch?v=A3AdN7U24iU&t=964s) Rust guarantees compile-time memory safety without a garbage collector via its ownership and borrowing system, which eliminates use-after-free, double frees, and data races while matching C's execution performance. - [30:25](https://www.youtube.com/watch?v=A3AdN7U24iU&t=1825s) The Rust Editions mechanism allows the language to evolve syntax and introduce reserved keywords without breaking backward compatibility, since all editions lower to a shared Mid-Level Intermediate Representation (MIR). - [35:43](https://www.youtube.com/watch?v=A3AdN7U24iU&t=2143s) Mozilla's audit of Firefox's legacy styling engine revealed that 51 out of 69 historical vulnerabilities (roughly 74%) would have been prevented entirely had the component been written in Rust instead of C++.
## Key takeaways - [04:40](https://www.youtube.com/watch?v=A3AdN7U24iU&t=280s) The 19th-century railroad industry suffered massive brakeman fatalities until George Westinghouse invented the fail-safe air brake, which made safety the default operational state. - [06:48](https://www.youtube.com/watch?v=A3AdN7U24iU&t=408s) Railroad operators vigorously lobbied against safety mandates using contradictory economic and technological arguments until the Railroad Safety Appliance Act of 1893 legally enforced adoption. - [11:02](https://www.youtube.com/watch?v=A3AdN7U24iU&t=662s) C remains prevalent due to minimal runtime overhead, universal compiler targets, and platform stability, but demands severe compromises regarding memory safety. - [12:35](https://www.youtube.com/watch?v=A3AdN7U24iU&t=755s) The belief that developers can simply 'be more careful' to prevent memory flaws is a proven myth refuted by widespread vulnerabilities found by elite security teams at Google and Microsoft. - [16:04](https://www.youtube.com/watch?v=A3AdN7U24iU&t=964s) Rust enforces memory safety at compile time using ownership, moves, and borrowing, automatically reclaiming heap memory at scope exit without a runtime garbage collector. - [19:39](https://www.youtube.com/watch?v=A3AdN7U24iU&t=1179s) Rust prevents data races through strict aliasing rules that allow either a single mutable reference or multiple immutable references, but never both simultaneously. - [19:39](https://www.youtube.com/watch?v=A3AdN7U24iU&t=1179s) Offloading manual memory bookkeeping to the compiler conserves the developer's finite cognitive capacity ('person-bytes') and democratizes systems programming. - [22:41](https://www.youtube.com/watch?v=A3AdN7U24iU&t=1361s) The `unsafe` keyword isolates operations that cannot be statically verified by the compiler, turning reactive debugging into a localized audit of bounded code blocks. - [25:54](https://www.youtube.com/watch?v=A3AdN7U24iU&t=1554s) Rust allows incremental adoption through C-compatible foreign function interfaces (FFI), enabling teams to rewrite high-churn or bug-prone components without full rewrites. - [30:25](https://www.youtube.com/watch?v=A3AdN7U24iU&t=1825s) Rust achieves 'stability without stagnation' via three-year Editions that desugar into a shared MIR representation, preventing ecosystem fragmentation across compiler versions. - [35:43](https://www.youtube.com/watch?v=A3AdN7U24iU&t=2143s) Enterprise roadblocks remain for Rust, including the absence of ANSI/ISO formal standardization, certified compilers for mission-critical industries, and formal LTS release channels. - [38:17](https://www.youtube.com/watch?v=A3AdN7U24iU&t=2297s) Major technology firms across the 'ABAMAGUBOXOFT' landscape—including Amazon (Firecracker), Google (Fuchsia), Facebook (Mononoke), and Microsoft—have deployed Rust in production systems. - [40:20](https://www.youtube.com/watch?v=A3AdN7U24iU&t=2420s) Rust is governed by open, specialized working groups and public RFC debates rather than a single benevolent dictator, fostering long-term community trust. - [43:26](https://www.youtube.com/watch?v=A3AdN7U24iU&t=2606s) Because invisible memory safety defects are unlikely to receive legislative safety mandates like physical train air brakes, software engineers must proactively demand safe defaults. - [49:05](https://www.youtube.com/watch?v=A3AdN7U24iU&t=2945s) While Go targets garbage-collected application and microservice environments, Rust targets systems programming without runtime overhead or garbage collection pauses. - [51:47](https://www.youtube.com/watch?v=A3AdN7U24iU&t=3107s) Rust tooling is maturing rapidly around the Language Server Protocol (LSP), which provides IDE diagnostics and autocompletion that benefit from Rust's strong static types.
## Detailed walkthrough ### [00:13](https://www.youtube.com/watch?v=A3AdN7U24iU&t=13s) Introduction and Speaker Background
Carol Nichols (also known as Carol Goulding) introduces the presentation, "Rust: A Language for the Next 40 Years." Addressing her online handle `@carols10cents`, she points the audience to a GitHub repository containing links to the slides and follow-up reference materials. She is a prominent figure in the Rust ecosystem: she co-authored *The Rust Programming Language* book (freely available online and published in print by No Starch Press) and co-created the Manning live video course *Rust in Motion*. To encourage audience participation through the Slido Q&A platform, she offers three free access codes for the video course to the askers of her favorite questions.
Beyond authoring educational materials, Nichols is a co-founder of Integer 32, which she notes was the world's very first dedicated Rust consulting company. She organizes the regional Rust Belt Rust conference (scheduled for October 18–19, 2019, in Dayton, Ohio) and serves as an active member of the official Rust Core Team. Acknowledging her deep investment in the technology, she cheerfully warns the audience that she is not here to deliver an impartial assessment: “so if you were hoping for an objective unbiased look at rust you're not gonna get that from this talk I clearly have a slant here.” She even jokes about her Pittsburgh sports loyalty, stating her favorite hockey player is two-time Stanley Cup champion Bryan Rust of the Pittsburgh Penguins, daring the Philadelphia audience to throw tomatoes or batteries at her.
- Speaker: Carol Nichols / Goulding (`@carols10cents`) - Co-author of *The Rust Programming Language* (No Starch Press) and *Rust in Motion* (Manning) - Co-founder of Integer 32 (first Rust consulting firm) - Rust Belt Rust 2019 organizer (Dayton, Ohio, October 18–19) - Member of the Rust Core Team
---
[02:26](https://www.youtube.com/watch?v=A3AdN7U24iU&t=146s) The Perils of Early Railroads and the Brakeman's Dilemma
Setting up the roadmap for the talk, Nichols outlines an unexpected agenda: examining the 19th-century American railroad industry alongside the C programming language, introducing Rust, and dissecting what modern software engineering can learn from railroad safety evolution. Commercial rail transit emerged in the United States around 1830, rapidly outpacing legacy stagecoaches and transforming long-distance transportation. However, this runaway infrastructure growth introduced severe physical dangers because stopping a massive moving locomotive presented immense physical hurdles.
Collisions and derailments were frequent, but the most hazardous position fell to the brakeman. Because trains possessed no automated or centralized braking mechanism, the engineer signaled deceleration via a dedicated whistle pattern. Upon hearing the signal, brakemen had to manually run along the catwalks atop swaying railcars in rain, ice, or darkness, turning heavy hand wheels car-by-car to slowly apply individual friction brakes. If hand-braking failed or was delayed, trains routinely overshot depots or collided at high speeds. Falling from car roofs caused thousands of brakemen fatalities each year, making the profession the second deadliest job in the United States during the 1800s, surpassed only by underground mining.
```mermaid flowchart TD accTitle: The Manual Hand Brake Process accDescr: Sequence diagram showing how manual braking worked and failed on 19th-century trains.
subgraph Signalling["Signalling"] A["Engineer blows whistle signal"] end
subgraph ManualAction["Physical Execution"] B["Brakemen climb on top of cars"] C["Turn individual hand brake wheels car-by-car"] end
subgraph FailureModes["Failure Modes & Hazards"] D["Delayed or uneven stopping: Overshoot / Crash"] E["Slippery roofs in rain/ice: Brakeman falls & dies"] end
A --> B B --> C C --> D B --> E ```
---
[04:40](https://www.youtube.com/watch?v=A3AdN7U24iU&t=280s) George Westinghouse and the Invention of the Air Brake
In 1869, Pittsburgh inventor George Westinghouse introduced the railway air brake, a mechanical breakthrough whose core operational concepts remain the foundation of train safety today. Instead of individual physical labor atop car roofs, the Westinghouse air brake used compressed air supplied by a locomotive-driven compressor piped through hoses running the entire length of the train. This design allowed the engineer to control braking directly from the locomotive cab, instantly decelerating every car in unison without whistle cues.
Crucially, Westinghouse engineered a "fail-safe" architecture into the compressed-air lines. Air pressure in the line kept the brake shoes disengaged; if line pressure was vented by the engineer or lost due to a decoupled car or ruptured hose, internal reservoir pressure automatically drove the brake shoes against the wheels. Safety was guaranteed by default: any failure automatically forced the entire train to an emergency halt rather than allowing it to careen down the tracks. Despite early skepticism—including Cornelius Vanderbilt questioning how "mere air" could halt an iron train—rigorous public trials, complete with passenger cars padded with pillows to survive test impacts, proved that Westinghouse air brakes reliably outperformed manual methods.
- Air brake invented by George Westinghouse in 1869. - Controlled directly by the engineer via pressurized air lines. - Applied braking force to all connected cars simultaneously. - Fail-safe design: loss of air line pressure automatically engages the brakes, making the system safe by default.
---
[06:48](https://www.youtube.com/watch?v=A3AdN7U24iU&t=408s) The Battle Over Railroad Safety Mandates
While passenger train operators swiftly adopted air brakes because customer safety concerns dictated market demand, freight operators stubbornly resisted retrofitting their rolling stock. Lorenzo Coffin, a member of the Iowa Railroad Commission, became a crusader for mandatory safety appliances. When Coffin initially joined the commission, commissioners resigned themselves to tragedy, viewing high brakeman mortality rates as an unavoidable byproduct of heavy industry. Dismayed by steady streams of horrific casualty reports, Coffin recognized that these recurring deaths had a common root cause and pushed aggressively for federal intervention.
Nichols highlights the fascinating 1890 transcripts of Senate Interstate Commerce Committee hearings, where railroad executives mounted fierce resistance against government mandates. Railroad representatives argued that brakemen were cheap and expendable, and claimed that because air brakes could still occasionally fail, switching was pointless. They deployed contradictory anti-regulatory arguments: claiming that mandatory rules would freeze ongoing voluntary safety innovation, while simultaneously complaining that adopting air brakes right away risked locking them into obsolete sunk capital if better brake tech appeared later. Others pleaded poverty, complained that Congress should have regulated decades earlier, or resorted to slippery-slope fallacies. Nichols recounts her favorite rebuttal from the president of the Pennsylvania Railroad: “are you're gonna regulate the trains what's next are you gonna regulate the bridges it's like yes please we want the bridges to be safe too actually.”
Despite industry pushback, Congress passed the Railroad Safety Appliance Act in 1893, mandating air brakes and standard automatic couplers across interstate railroads. The law took full effect in 1900, producing an immediate and dramatic reduction in operating casualties, derailments, and brakeman fatalities.
---
[11:02](https://www.youtube.com/watch?v=A3AdN7U24iU&t=662s) The Persistence of C in Enterprise Computing
Transitioning back to modern software engineering, Nichols asks how many people in the room represent companies operating C in active production environments. A substantial number of hands go up, prompting an analysis of why companies have leaned so heavily on C for more than forty years. C is a battle-tested, highly predictable runtime environment that sits exceptionally close to bare-metal hardware and assembly code, giving developers fine-grained control with negligible overhead and minimal memory footprints.
```mermaid flowchart LR accTitle: Motivating Factors for Using C accDescr: Key technological and organizational reasons development teams select C.
subgraph Hardware["Hardware & Platform"] H1["Minimal overhead & memory usage"] H2["Direct machine/assembly mapping"] H3["Universal compiler availability"] end
subgraph Business["Enterprise & Ecosystem"] B1["40-year proven track record"] B2["Massive existing codebase"] B3["Slow language churn / stability"] end ```
The language features unmatched ubiquity, with compliant compilers targeting virtually any hardware architecture or embedded chip. Its core syntax appears deceptively simple and easy to pick up, and decades of legacy C libraries provide compelling integration momentum. For slow-moving enterprise environments that cannot afford shifting language standards or runtime deprecations, C provides rare platform stability. Yet, Nichols emphasizes, these operational advantages demand a steep compromise: unlocking this performance forces developers to accept a massive, fundamental disadvantage inherent to the language design.
- Proven reliability spanning more than 40 years of continuous use. - Extremely fast execution with minimal runtime overhead. - Universal compiler coverage across embedded, mobile, and server hardware. - High enterprise stability with minimal language-level syntax drift.
[12:35](https://www.youtube.com/watch?v=A3AdN7U24iU&t=755s) The Myth of "Just Be More Careful" in C
Shipping C code in production forces developers to accept a massive catalog of memory safety pitfalls: use-after-free, double frees, memory leaks, buffer over-reads, buffer overwrites, null pointer dereferences, and data races. When confronted with these chronic issues, a common defense from seasoned programmers is that developers should simply exercise greater vigilance. Nichols vigorously rejects that mindset, stating flatly: “It's not a matter of being more careful. It's the experience in past 40 years has shown we're not capable of being careful enough.”
To prove that raw human discipline cannot solve memory safety, Nichols points to high-profile security research. A famous Android vulnerability called Stagefright stemmed from a C code defect where, as one analysis blog post observed, avoiding it would require an individual programmer to be more careful than the entirety of the Android security team. Similarly, Microsoft analyzed its issued security updates over a 12-year window and discovered that roughly 70% of all vulnerabilities were caused by memory safety flaws. Relying on sheer attentiveness means demanding that ordinary C developers outperform Microsoft's entire elite security engineering organization on every single line of code they ship.
Existing remedies for C and C++ remain fundamentally reactive. Developers turn to tools such as Valgrind, AddressSanitizer (ASan), UndefinedBehaviorSanitizer (UBSan), MISRA C guidelines, or NASA’s IKOS tool, which performs abstract interpretation through static analysis. While NASA’s tooling exemplifies top-tier engineering rigor, Nichols points out that all these external checks share a core structural flaw: they are applied after the fact. Teams must remember to integrate them into CI pipelines, allocate dedicated sprint time to run them, and continually remediate findings. Meanwhile, alternative modern dialects of C have failed to gain traction, still lack rich abstractions, and force developers to reinvent basic wheels without modern tooling. C++ introduces useful idioms but retains pervasive undefined behavior, dangerous raw pointers, and complex multi-threaded concurrency bugs.
- Common C memory hazards: use-after-free, double free, memory leaks, buffer over-reads/overwrites, null pointers, and data races. - Microsoft security study: approximately 70% of all security patches issued over 12 years traced back to memory safety bugs. - C safety tooling evaluated: Valgrind, AddressSanitizer, UndefinedBehaviorSanitizer, MISRA guidelines, and NASA's IKOS static analyzer.
---
[16:04](https://www.youtube.com/watch?v=A3AdN7U24iU&t=964s) Reason 1: Memory Safety via Ownership and Borrowing
```mermaid flowchart TD accTitle: Rust Ownership and Lifetime Flow accDescr: Diagram illustrating how Rust checks value ownership, moves, immutable borrows, and scopes at compile time.
subgraph Alloc["Allocation"] A["String created on heap"] --> B["Owner: Variable x"] end
subgraph Actions["Assignment Scenarios"] B -->|"Scenario 1: Move (let y = x)"| C["y becomes sole owner"] C --> D["x invalidated; using x fails compilation"]
B -->|"Scenario 2: Borrow (let y = &x)"| E["y borrows x immutably"] E --> F["Both can read; x frees at scope exit"]
B -->|"Scenario 3: Return reference from inner scope"| G["Inner scope ends; x dropped"] G --> H["Dangling pointer prevented at compile time"] end ```
Rust emerged from Mozilla Research designed specifically to absorb the hard-won lessons of C while importing powerful concepts from across modern programming language research. Nichols identifies five reasons why Rust has the resilience to endure for the next 40 years, starting with its direct elimination of memory safety flaws at compile time through its ownership and borrowing model.
In basic Rust code, allocating a growable heap string binds that resource to an owner variable (such as `x`). When `x` reaches the end of its enclosing scope, the compiler automatically inserts cleanup instructions. There is no manual invocation of `free()`, nor is there a garbage collector pausing execution at runtime; the cleanup lifecycle is entirely determined during compilation. If a developer reassigns the value using `let y = x;`, Rust performs a move: ownership transfers completely to `y`, instantly invalidating `x`. Attempting to reference `x` thereafter triggers a compile-time rejection, eliminating both use-after-free and double-free vulnerabilities before the binary can even be produced.
Borrowing allows developers to inspect data without seizing ownership. By creating an immutable reference with `let y = &x;`, `y` is permitted to read the heap data while `x` remains the designated owner responsible for deallocation at scope exit. When programmers attempt to create dangling pointers—such as returning a reference to heap data initialized inside an inner scope—the borrow checker detects that the underlying owner will be deallocated as that inner block closes. The compiler halts the build immediately, refusing to permit a pointer that outlives its target.
---
[19:39](https://www.youtube.com/watch?v=A3AdN7U24iU&t=1179s) Eliminating Data Races and Expanding the "Person-Byte"
Beyond basic pointer lifecycles, Rust enforces strict aliasing guarantees: code may hold either a single mutable reference to a piece of data or any number of immutable references, but never both simultaneously. This invariant eradicates data races by guaranteeing that no thread or function can mutate a value while another context is reading it. Furthermore, Rust does away with null pointers entirely, substituting the algebraic `Option` enum (`Some(T)` or `None`), which forces developers to explicitly handle missing values at compile time. Out-of-bounds collection accesses trigger controlled runtime panics rather than allowing arbitrary memory corruption. Because these ownership invariants cross thread boundaries in the type system, multithreaded and parallel concurrency bugs are captured before execution.
Nichols connects these language mechanics to a cognitive concept introduced earlier in the conference by Jessica Kerr: the "person-byte," defined as the finite amount of state, context, and complexity an individual developer can hold in their mind simultaneously. Keeping track of pointer lifecycles, manual allocations, and subtle aliasing hazards in C exhausts that mental cache, leaving little room for actual business logic. Nichols emphasizes: “There's someone who's really good at keeping track of tedious things and making sure that they're right every single time: it's our computers.” Rust assigns the exhaustive bookkeeping to the compiler.
This automated vigilance forms Nichols's second key reason why Rust will endure: it democratizes systems programming. By eliminating the prerequisite of an impossibly massive "person-byte" capacity to hand-track raw memory layouts, Rust makes writing high-performance low-level code accessible to far more developers without sacrificing safety or correctness.
- The aliasing rule: either one mutable reference XOR many immutable references at any given point in time. - Null replacement: Rust requires exhaustive pattern matching over `Option::Some` and `Option::None`. - Concurrency: thread-safe transfer of ownership and references enforced by the compiler's type system.
---
[22:41](https://www.youtube.com/watch?v=A3AdN7U24iU&t=1361s) The `unsafe` Escape Hatch and Safety Trade-Offs
Rust acknowledges that certain low-level operations—such as direct pointer arithmetic, operating system calls, and foreign function interfaces (FFI) to external C libraries—cannot be verified statically by the compiler. For these specific situations, Rust supplies the `unsafe` keyword. Writing an `unsafe` block does not disable all compiler checks; rather, it allows the programmer to declare that they are manually auditing and upholding memory invariants that the compiler cannot deduce. Nichols underscores the structural value of this design: “What I like about this is that when if you have a seg fault or memory access problem at runtime, you know it came from one of those unsafe blocks.” Instead of hunting through millions of lines of code, debugging efforts can immediately focus on the contained `unsafe` boundaries.
Crucially, `unsafe` preserves Rust's safety posture because safety remains the baseline default. In contrast to sanitizers in C that require proactive, opt-in vigilance, Rust requires developers to explicitly opt *out* of compiler guardrails. Safe abstractions can be built around minimal unsafe foundations, a practice thoroughly documented in the community text known as *The Rustonomicon* and featured in conference talks like "Building an Unsafe Foundation."
Nichols cautions that Rust does not guarantee bug-free software; just as train air brakes cannot prevent every railway accident, the borrow checker cannot detect flawed business logic. Programmers still need unit tests, integration suites, and fuzz testing. However, choosing Rust removes the entire class of memory corruption vulnerabilities that plague C while preserving C-like execution speed, as Rust's safety guarantees operate almost entirely at compile time without a runtime garbage collector.
- The `unsafe` keyword: a deliberate, narrow opt-out for FFI, raw pointer manipulation, and extreme hardware/performance operations. - Debugging containment: runtime memory faults are localized to explicitly marked `unsafe` blocks. - Reference material: *The Rustonomicon* (the definitive book on advanced and unsafe Rust). - Runtime overhead comparison: Rust matches C's performance tier because its checks occur at compile time with zero garbage collection overhead.
[25:54](https://www.youtube.com/watch?v=A3AdN7U24iU&t=1554s) Performance, Portability, and Gradual Interop
Carol Nichols explains that Rust minimizes runtime overhead by focusing on compile-time checks and zero-cost abstractions: “We have the goal of having zero cost abstractions which means that the abstractions you use are compiled down to code that you could not write better by hand.” While there is always room to optimize, the overall design aims to match C's execution performance in critical systems contexts.
Portability in Rust is tied directly to the LLVM infrastructure. Because the Rust compiler emits LLVM intermediate representation (LLVM IR), developers can target any architecture supported by LLVM. Nichols acknowledges that C compilers still target certain legacy or niche architectures that LLVM does not support. While a non-LLVM backend for Rust is technically feasible if the community chooses to invest the labor, current platform coverage might still be a deal-breaker for specialized embedded hardware.
On the ergonomic side, Rust has a significantly higher baseline complexity than C. Nichols notes that expressing intricate borrow-checker semantics and correctness guarantees requires richer language features and syntax, prompting an ongoing community effort to flatten the learning curve with books and courses.
For projects containing existing codebases, Rust supports direct foreign function interfaces (`extern` functions) to call C from Rust and expose Rust to C. Because many runtimes (like Python and Ruby) interface directly with C, teams can bridge to Rust through standard C-compatible boundaries. Nichols highlights an incremental conversion strategy she presented in another talk about rewriting the Zopfli compression library:
> “And the thing I like about this technique is that you don't even have to finish you don't have to convert the whole thing to Rust to see benefit you could convert just the parts that change the most the parts that have the most bugs and you could set it aside for a while if you have other high priority things to work on but you still get those benefits along the way of converting little pieces to Rust so you don't have to rewrite all of your stuff in Rust to see benefits.”
- Rust's Zopfli port was converted function by function while remaining compilable and test-green on every commit. - Interop capabilities allow mixed architectures without requiring full rewrites. - Lack of non-LLVM backends remains the primary barrier to matching C's absolute platform reach.
---
[28:47](https://www.youtube.com/watch?v=A3AdN7U24iU&t=1727s) Stability Guarantees and Upgrades
Rust follows a six-week train release cycle modeled on the release cadences of browsers like Firefox and Chrome. Despite frequent releases, the project has maintained a strict backward compatibility policy since the release of Rust 1.0 in May 2015. Nichols explains that the project preserves limited escape hatches: the team reserves the right to fix compiler bugs, patch safety holes, and adjust type inference algorithms even if they occasionally demand new type annotations. However, the core language promises that valid code continues to compile without disruptive breaks.
Empirical evidence from community surveys backs up this design. In the 2018 Rust survey, 92.6% of respondents confirmed that updating the compiler had never broken their code. Nichols candidly points out a limitation in the phrasing of that survey question: it fails to isolate breakages in compilation (the specific guarantee Rust provides) from runtime regressions, performance swings, or bug repairs that alter execution behavior. She expresses an eagerness to capture more granular survey data on pure compile-time stability.
---
[30:25](https://www.youtube.com/watch?v=A3AdN7U24iU&t=1825s) Stability Without Stagnation: The Editions Mechanism
To ensure Rust remains viable for decades without fracturing or freezing progress, the core team adopted the principle of "stability without stagnation." To evolve the language and introduce features requiring reserved words—such as the `async` keyword for asynchronous functions—without invalidating existing code that uses identifiers named `async`, Rust introduced Editions. Planned roughly on a three-year cycle, Editions allow opt-in changes without causing code breakage across compiler versions. Rust 2015 established the baseline, followed by Rust 2018.
Initially, Nichols had serious reservations about the architecture: “When I first heard of this idea I thought it sounded terrible from a compiler maintenance point of view you have to maintain two ways to use every feature forever because we wanted to commit to all editions being supported forever but it's actually not that bad.” The maintenance burden is constrained because Editions only modify surface-level syntax and desugaring into High-Level Intermediate Representation (HIR). Both editions lower into a shared Mid-Level Intermediate Representation (MIR), where critical systems tasks like borrow checking, optimization passes, and code generation take place.
```mermaid flowchart TD accTitle: Rust Edition Lowering Pipeline accDescr: Diagram illustrating how Rust 2015 and Rust 2018 source codes lower to a shared MIR representation.
subgraph Surface["Surface Level (Edition-Specific)"] direction LR Src2015["Rust 2015 Source"] --> HIR2015["HIR (2015)"] Src2018["Rust 2018 Source"] --> HIR2018["HIR (2018)"] end
subgraph Core["Shared Engine (Agnostic)"] direction TB HIR2015 --> MIR["Mid-Level IR (MIR)"] HIR2018 --> MIR MIR --> Passes["Borrow Checking & Optimizations"] Passes --> LLVM["LLVM IR"] LLVM --> Target["Machine Code"] end ```
Because editions lower into the same unified intermediate form, crates compiled under different editions interoperate seamlessly. A Rust 2015 crate can depend on a Rust 2018 dependency, and vice versa, eliminating language-level ecosystem splits. Nichols stresses that upgrading an edition is completely optional: “Never is a totally valid choice we plan to support Rust 2015 edition code for as long as Rust exists.” To assist migrations, the tooling suite includes `cargo fix` / `rustfix`, which automatically rewrites source files to match newer idioms. This design leads Nichols to conclude: “The editions concept I am confident that with using this to evolve the language means we're never going to have a Rust 2.0 we're not going to break backwards-compatibility so we hope to be as stable as C is for the next 40 years.”
---
[35:43](https://www.youtube.com/watch?v=A3AdN7U24iU&t=2143s) Enterprise Adoption and Industry Roadblocks
Nichols outlines several institutional hurdles that must be addressed for broader enterprise penetration: - **Language Formalization:** Rust currently lacks a formal ANSI/ISO-style standard specification, which historically took decades for C to obtain. - **Compiler Certification:** Mission-critical and safety-critical industries require formally certified compilers, which do not yet exist for Rust. - **Release Cadence Options:** There is no official Long-Term Support (LTS) release pipeline for frozen compiler versions with backported security fixes. - **Enterprise Tooling:** Cargo assumes modern, connected development environments, making it harder to integrate into bespoke multi-language enterprise build systems or private package registries without open-source publishing. - **Library Breadth:** The ecosystem is still maturing, leaving gaps in specialized domains.
Despite these hurdles, major technology companies have bet heavily on Rust for foundational systems. The prime example is Mozilla's Firefox Quantum release, which replaced the legacy browser styling engine with a parallel CSS engine written in Rust (Stylo). Mozilla audited historical security vulnerabilities in the old C++ styling subsystem: out of 69 critical security bugs recorded across Firefox's history in that module, Rust’s memory-safety model would have completely prevented 51 of them—representing roughly three-quarters of all vulnerabilities.
[38:17](https://www.youtube.com/watch?v=A3AdN7U24iU&t=2297s) Industry Adoption Across Tech Giants: The "ABAMAGUBOXOFT" Metric
Carol Nichols examines industry adoption of Rust by referencing a tongue-in-cheek acronym coined by Patrick McKenzie (`@patio11` on Twitter): **ABAMAGUBOXOFT**, representing the dominant tech giants (Apple, Amazon, Google, Facebook/Meta, Microsoft). Nichols notes that Rust has established a public presence across four out of these five major software ecosystems:
- **Apple**: Nichols notes she does not know of any public uses of Rust at Apple. Instead, Apple focuses on Swift, which Nichols observes is remarkably similar to Rust. Attending a Swift presentation earlier at the conference, she found herself constantly translating technical terms: “they have a lot of the same problems and a lot of trying to solve the same problems that rust is but use different words for it so I was like sitting there trying to translate him like ah stats oh oh they're hitting the same problem that we are they're really similar and there is cross-pollination there.” - **Amazon**: Nichols points to Amazon's open-source release of the Firecracker microVM, an infrastructure virtualization component written entirely in Rust. - **Google**: Despite Google being traditionally guarded about internal initiatives, Nichols highlights the open-source Fuchsia operating system project, noting that parts of its public codebase are written in Rust. - **Facebook**: Facebook developed the Mononoke Mercurial server in Rust to power their monolithic Mercurial repository after the canonical Mercurial implementation proved unable to scale quickly enough. - **Microsoft**: Microsoft announced an IoT Edge platform running Rust to perform local device-level analytics before streaming distilled results back to central servers.
```mermaid flowchart TD accTitle: Tech Giant Adoption of Rust accDescr: Mapping of Patrick McKenzie's big-tech acronym to public Rust adoption across major companies. A["ABAMAGUBOXOFT Ecosystem"] --> B["Apple"] A --> C["Amazon"] A --> D["Google"] A --> E["Facebook"] A --> F["Microsoft"]
B -.->|"No public Rust; uses Swift"| G["Swift cross-pollination"] C -->|"Built with Rust"| H["Firecracker microVM"] D -->|"Rust components"| I["Fuchsia OS"] E -->|"Rust backend"| J["Mononoke Mercurial Server"] F -->|"Edge analytics"| K["Azure IoT Edge Platform"] ```
---
[40:20](https://www.youtube.com/watch?v=A3AdN7U24iU&t=2420s) Open Governance, RFCs, and Community Trust
The fifth major reason Nichols believes Rust is equipped to endure for decades is its project governance model. Rather than relying on technical merit alone or following the whims of a single figurehead, the project intentionally distributed control: “We don't have a BDFL, a benevolent dictator for life; there's not just one person making final decisions on Rust.” Development is overseen by specialized teams and working groups consisting of contributors from wide-ranging backgrounds: programming language theory PhDs, enterprise developers building commercial products, hobbyists, low-level systems specialists transitioning from C and C++, functional programmers from Haskell, and high-level developers from languages like Ruby and Python (which survey data shows is consistently the number-one feeder language into Rust).
Architectural decisions are vetted publicly using the Request for Comments (RFC) system. Working groups publish their rationale in the open on these RFCs, allowing the community to track every trade-off. Nichols stresses the psychological and operational necessity of this structure: “While we might not make a decision on something in the exact way you might want, our hope is that you'll at least understand why we're making those decisions and feel like we have heard your point of view.”
Nichols contrasts this with closed corporate stewardship, emphasizing that Rust's trajectory will never be steered in secret or hijacked without transparent public notice. Furthermore, Nichols underscores that Rust established a formal Code of Conduct from the very day it was open-sourced, removing endless meta-debates about establishing professional conduct standards and cementing a welcoming, professional baseline for contributors.
---
[43:26](https://www.youtube.com/watch?v=A3AdN7U24iU&t=2606s) Lessons from the Railroad Industry: The Software Arrogance Trap
Nichols shifts to an analogy between software engineering and the historic rail transportation industry, starting with a critique of tech hubris. Nichols recounts several public missteps where Silicon Valley attempted to bypass established problem domains: Juicero attempting to engineer high-tech juice presses that performed no better than squeezing packets by hand; Lyft marketing shared commute vans that essentially reinvented the city bus; and Elon Musk attempting to intervene in the Tham Luang cave rescue with a miniature submarine instead of deferring to veteran cave rescue divers.
Nichols stresses that if software engineers claim they can solve society's problems through code, they must actually prove it. However, the path to systemic safety in software diverges sharply from physical industries: - In rail travel, physical hazards are visceral: anyone can see that riding on top of a railcar in winter is dangerous or that failing train brakes kill passengers. - Memory unsafety in software is invisible, making it difficult for the public and policymakers to grasp. Nichols jokes about the absurdity of congressional hearings: “I'm trying to imagine the the Senate transcripts from reading that in the future from now of software people trying to explain memory unsafety to senators and it's terrible it's I don't see this going well.”
Because binding external government safety mandates are improbable, the burden falls directly onto software professionals to become informed, demanding consumers who refuse to integrate unsafe, unvetted dependencies. Nichols presents a chronological timeline of railroad safety adoption:
| Milestone / Technology | Year | Elapsed Time | Significance | |:--- |:--- |:--- |:--- | | **Railroad Industry Genesis** | 1830 | — | Early commercial operation without standardized failsafes | | **Westinghouse Air Brake Invented** | 1869 | ~40 years | Technical solution to catastrophic braking failures | | **Universal Air Brake Adoption** | 1900 | ~30 years | Broad operational adoption across commercial fleets | | **Rust 1.0 Stabilization** | 2015 | — | Production-ready alternative offering compile-time memory safety |
Nichols asks whether the software industry can beat the railroad sector’s 30-year adoption curve, emphasizing: “I don't know how long it's gonna take us to adopt something that's memory safe. Can we do better than the railroad industry? I don't know. I want us to be better. I'm not sure if we are better. I hope that we're better.”
---
[46:55](https://www.youtube.com/watch?v=A3AdN7U24iU&t=2815s) Conclusion: "Let's Make Some New Mistakes"
Concluding the core presentation, Nichols delivers an open, pragmatic invitation. She welcomes skepticism, stating that her loyalty lies not with language dogmatism, but with eliminating systemic memory safety vulnerabilities: “I am willing for Rust not to be the solution as long as we do something; let's just do something to fix these memory safety problems that keep happening over and over and over again.”
Whether the replacement turns out to be Rust, Go, or a diverse spectrum of purpose-built languages fitting specific operational niches, Nichols encourages the audience to move beyond recurring security blunders: “You don't have to choose Rust. I just I just want us to stop making the same mistakes over and over again. Let's make some new mistakes.”
Nichols presents her slides, contact handles (`@carols10cents`), a 40% discount code for Manning publications, and credits her test audience—her daughter Vivian and her cat Baby—before opening the floor to audience Q&A.
---
[49:05](https://www.youtube.com/watch?v=A3AdN7U24iU&t=2945s) Q&A: Origins of the Name "Rust" and Rust vs. Go
Nichols reviews submitted audience questions and fields two primary topics:
**The Etymology of "Rust":** - Nichols shares multiple origins: early founders were avid bicycle riders who frequently had to deal with rusted bike parts, which inspired the gear-shaped Rust project logo. - Others cite the biological rust fungus that attacks wheat crops as a conceptual root. - Nichols personally associates the name with COR-TEN weathering steel, such as that used in the U.S. Steel Tower in Pittsburgh, which develops an intentional layer of surface rust to protect the underlying structure from deep corrosion without requiring exterior paint.
**Comparing Rust and Go:** When asked why someone should choose Rust over Go, Nichols points out that while they are frequently lumped together because they emerged around the same era as modernized alternatives to C and C++, they target different system trade-offs: - **Runtime Performance & Garbage Collection**: Go uses an automatic garbage collector, which can introduce runtime overhead or latency spikes that disqualify it for hard real-time systems, low-level embedded devices, or tight resource constraints. Rust requires zero runtime garbage collection. - **Ecosystem Fit**: If a team builds tooling that interfaces deeply with Google products or standard microservices, Go offers an integrated, highly streamlined experience. - Rather than declaring a unilateral winner, Nichols advises developers to experiment with introductory programming in both languages to discover which mental model best aligns with their technical requirements.
[51:47](https://www.youtube.com/watch?v=A3AdN7U24iU&t=3107s) Rust IDE Integration and the Language Server Protocol
Carol Nichols addresses an audience question regarding whether Rust currently possesses solid IDE integration. Her honest response is that the team is actively working on it, acknowledging it as an area where the ecosystem recognizes an urgent need for improvement. To bridge this gap, the community relies heavily on the Language Server Protocol (LSP), an industry effort designed to standardize communication between programming languages and various IDEs. Rust's LSP implementation already powers core editing features such as code completion, inline error diagnostics, and jumping directly to definitions. Currently, Visual Studio Code boasts the best-maintained plugin leveraging this protocol, while IntelliJ also provides a strong, dedicated Rust implementation.
```mermaid flowchart LR accTitle: Rust IDE Integration Flow accDescr: Shows how Rust language tools communicate through LSP or direct plugins into IDEs. subgraph Language ["Language Engine"] RLS["Rust Language Server / Analysis"] end subgraph Protocol ["Interface"] LSP["Language Server Protocol (LSP)"] end subgraph Editors ["Editor Environments"] VS["VS Code (Plugin)"] IJ["IntelliJ Rust (Direct Support)"] end RLS --> LSP LSP --> VS RLS -.-> IJ ```
Nichols reflects on her background prior to working with Rust, drawing a comparison to her time writing Ruby. She references Michael Feathers' seminal book, *Working Effectively with Legacy Code*, which emphasizes heavily leaning on editor tools, IDE integrations, and automated refactoring routines. In dynamic languages like Ruby, heavy metaprogramming makes automated tooling notoriously difficult; taking arbitrary strings and executing them as method calls prevents tools from guaranteeing that every call site has been caught. While that dynamic nature left her with what she describes as persistent IDE jealousy, Rust's strict static types make deep tooling fundamentally achievable. As Carol Nichols puts it: “I had a lot of jealousy for IDE tools while I was writing Ruby and I'm looking forward to the days that we have those tools for Rust, they're not there yet but they're more possible to make than they are in Ruby.”
- Features currently functional in Rust's Language Server Protocol implementation: - Code completion - Inline error highlighting - Jump-to-definition navigation - Leading environments for Rust tooling: - Visual Studio Code (utilizing the community's primary LSP plugin) - JetBrains IntelliJ (via its dedicated Rust plugin)
---
[53:45](https://www.youtube.com/watch?v=A3AdN7U24iU&t=3225s) The Status of Async/Await Across Rust Editions
Looking through the submitted questions, Nichols selects an inquiry regarding asynchronous programming: given that async functionality was discussed in the context of the 2018 Edition, is async syntax also available in the 2015 Edition? She clarifies a common misconception, revealing that fully fledged async support is actually not complete in either edition yet. When Rust 2018 was released, the team took the necessary preparatory step of reserving `async` as a language keyword so that future syntax changes would not cause breaking conflicts. While the initial goal had been to ship complete async support simultaneously with the 2018 Edition release, the underlying implementation and ergonomics required significantly more design work.
Active community discussions and RFCs continue to hammer out the exact syntax and execution semantics. Once async stabilizes, developers across both editions should theoretically have access to the functionality, but with an important syntactic trade-off. Because the 2015 Edition cannot reserve new keywords without breaking legacy codebases, any async features backported to 2015 will rely on alternative, less ergonomic constructs. Carol Nichols explains: “Once it is done it will probably be available in both, it's just that the syntax in Rust 2015 is not going to use a keyword so it's not going to be as nice as syntax as it will be in Rust 2018.” Handing out the final book token to the attendee who submitted the question, Nichols notes that her time has expired and wraps up the presentation to audience applause.
## Notable quotes > [19:39](https://www.youtube.com/watch?v=A3AdN7U24iU&t=1179s) There's someone who's really good at keeping track of tedious things and making sure that they're right every single time: it's our computers. — Carol Nichols
> [12:35](https://www.youtube.com/watch?v=A3AdN7U24iU&t=755s) It's not a matter of being more careful. It's the experience in past 40 years has shown we're not capable of being careful enough. — Carol Nichols
> [46:55](https://www.youtube.com/watch?v=A3AdN7U24iU&t=2815s) I am willing for Rust not to be the solution as long as we do something; let's just do something to fix these memory safety problems that keep happening over and over and over again. — Carol Nichols
> [25:54](https://www.youtube.com/watch?v=A3AdN7U24iU&t=1554s) We have the goal of having zero cost abstractions which means that the abstractions you use are compiled down to code that you could not write better by hand. — Carol Nichols
## Mentioned Carol Nichols, Integer 32, The Rust Programming Language, Rust in Motion, No Starch Press, Manning, George Westinghouse, Lorenzo Coffin, Cornelius Vanderbilt, Railroad Safety Appliance Act, Valgrind, AddressSanitizer, UndefinedBehaviorSanitizer, MISRA C, IKOS, NASA, Jessica Kerr, The Rustonomicon, LLVM, Zopfli, Mozilla, Firefox Quantum, Stylo, Patrick McKenzie, Apple, Amazon, Firecracker, Google, Fuchsia, Facebook, Mononoke, Microsoft, Azure IoT Edge, Juicero, Lyft, Elon Musk, Michael Feathers, Working Effectively with Legacy Code, Language Server Protocol, Visual Studio Code, IntelliJ
## Video description Learn what makes the programming language Rust a unique technology, such as the memory safety guarantees that enable more people to write performant systems-level code. Hear about how Rust Editions evolve the language and the compiler without breaking existing code. See who’s trusting Rust for critical products today. Join us on Rust’s journey to the future.
Philly ETE 2019 Playlist: https://www.youtube.com/playlist?list=PL9oQ7yETvN10Lopbg81O_bwElm9grUkDB On the Chariot Solutions site: http://chariotsolutions.com/screencasts/
[Source](https://www.youtube.com/watch?v=A3AdN7U24iU)