Why Rust Is Different, With Alice Ryhl - CourtneyR.dev's 2nd Brain

Why Rust Is Different, With Alice Ryhl ![rw-book-cover](https://img.youtube.com/vi/q9xD36NCtZ8/maxresdefault.jpg) 🔗 **Source:** [Why Rust Is Different, With Alice Ryhl](https://www.youtube.com/watch?v=q9xD36NCtZ8) > [!note]+ Document Notes > tags: [rust-language, memory-safety, programming-languages, ownership-model, type-systems, developer-tools] > author: [MISSING] > source: [MISSING] > reference: [https://www.youtube.com/watch?v=q9xD36NCtZ8] > date created: {{date:YYYY-MM-DD}} {{time:HH:mm}} > > # 🏷️ Title: Why Rust is different, with Alice Ryhl >  ## 🧭 Table of Contents - [📝 Summary](#-summary) - [📖 Main Content](#-main-content) - [🗒️ Notes](#️-notes) - [📚 References](#-references) - [🗣️ Paraphrase](#️-paraphrase) - [📰 Newsletter](#-newsletter) - [✅ Action Items](#-action-items) - [🧪 Hypotheses](#-hypotheses) - [📊 Methodology](#-methodology) - [❓ Questions](#-questions) - [🔮 Future Research](#-future-research) - [💡 Implications](#-implications) - [🧠 Learning Styles Assessment](#-learning-styles-assessment) - [📊 Accessibility Assessment](#-accessibility-assessment) - [🌍 DEIB Assessment](#-deib-assessment) - [✅ Logical Validity](#-logical-validity) - [🛡️ DARVO Analysis](#-darvo-analysis) - [🎯 Conclusion](#-conclusion) ## 📝 Summary - **What happened**: Interview with Alice Ryhl, Google Android Rust team engineer and Tokyo maintainer, discussing Rust's unique features and growing adoption. - **Why it matters**: Rust is rapidly gaining popularity, overtaking PHP and Go on the TIOBE index, offering memory safety without garbage collection overhead. - **Key stakeholders**: Developers transitioning from TypeScript/Java (backend reliability), C++ developers (security vulnerabilities), systems programmers, open source maintainers. - **Risks and tradeoffs**: Steep learning curve around ownership model and data structures; fighting the borrow checker; limited front-end ecosystem maturity. - **Bottom line**: Rust provides "when it compiles, it works" reliability through compile-time safety guarantees, making it ideal for systems programming and backend services. ## 📖 Main Content Rust distinguishes itself through a combination of memory safety, performance, and reliability features that eliminate entire classes of bugs at compile time. Unlike languages with garbage collectors (Java, C#), Rust manages memory through an ownership model without runtime overhead, making it suitable for both low-level systems programming and high-performance backends. ### Key Rust Advantages **Memory Safety**: Eliminates security vulnerabilities common in C++ where simple mistakes (array bounds errors, use-after-free) become exploitable. The ownership model ensures objects have single owners, preventing double-free errors and data races. **Type System Reliability**: - No null pointer exceptions (uses Option enum) - Explicit error handling with Result enum and `?` operator - Exhaustive pattern matching prevents missed cases - Documentation examples become tests, preventing outdated docs **Performance**: No garbage collector means predictable latency and lower resource usage, crucial for embedded systems and latency-sensitive applications. ### Learning Challenges The primary difficulty newcomers face involves data structure design. Unlike TypeScript where cyclic references (book ↔ page) work naturally, Rust requires tree-like structures or explicit reference counting (Arc) for shared ownership. The solution is often changing data structure design rather than fighting compiler errors. The borrow checker enforces that references don't outlive their underlying data and prevents simultaneous mutable/immutable access, ensuring thread safety at compile time. ### Governance and Evolution Rust operates without a "benevolent dictator for life" unlike Python or Linux. Teams (language, library, compiler) make decisions through RFC (Request for Comments) processes and Final Comment Period (FCP) voting. Major changes require RFC documentation including motivation, guide-level explanation, and rationale for design choices. Editions (2015, 2018, 2021, 2024) enable breaking changes while maintaining backward compatibility - different crates can use different editions within the same project. ## 🗒️ Notes #### ⏱️ [00:00:00](https://www.youtube.com/watch?v=q9xD36NCtZ8?t=0) Introduction and Background - Alice started programming through Minecraft modding in Java - Became active on Rust users forum with ~10,000 posts - Tokyo maintainer - async runtime for Rust ("standard library for async") #### ⏱️ [00:05:30](https://www.youtube.com/watch?v=q9xD36NCtZ8?t=330) Rust's "When it compiles, it works" Philosophy - Strong type system eliminates many runtime errors - Better than Java's null pointer issues - uses Option enum instead - Exhaustive pattern matching prevents missing cases in switch statements - Documentation examples become automated tests #### ⏱️ [00:12:00](https://www.youtube.com/watch?v=q9xD36NCtZ8?t=720) Memory Safety Pitch - C++ mistakes become security vulnerabilities (buffer overflows, use-after-free) - Rust prevents entire class of memory safety bugs at compile time - Classic kernel exploit: overwriting task struct user_id field to become root - Memory safety without garbage collection overhead #### ⏱️ [00:18:45](https://www.youtube.com/watch?v=q9xD36NCtZ8?t=1125) Learning Curve and Data Structures - Biggest challenge: designing non-cyclic data structures - TypeScript allows book ↔ page references; Rust requires tree structures - Solution often involves changing struct design, not fighting compiler - Reference counting (Arc) enables shared ownership when needed #### ⏱️ [00:25:15](https://www.youtube.com/watch?v=q9xD36NCtZ8?t=1515) Ownership Model and Borrow Checker - Ownership: each value has single owner, moves transfer ownership - References ("borrowing") allow temporary access without ownership transfer - Borrow checker ensures references don't outlive underlying data - Prevents simultaneous mutable/immutable access for thread safety #### ⏱️ [00:32:00](https://www.youtube.com/watch?v=q9xD36NCtZ8?t=1920) Unsafe Keyword - Escape hatch for operations compiler can't verify as safe - Used to build safe abstractions (like implementing Vector) - Enables calling C libraries with safety wrappers - Not used in typical backend applications #### ⏱️ [00:38:30](https://www.youtube.com/watch?v=q9xD36NCtZ8?t=2310) Cargo Package Manager - All-in-one tool: dependency management, building, testing, documentation - Local dependencies (not globally installed like pip) - Linus Torvalds dislikes cargo downloading from internet vs distro packages - Similar security concerns to npm regarding malicious packages #### ⏱️ [00:45:00](https://www.youtube.com/watch?v=q9xD36NCtZ8?t=2700) Ecosystem Maturity - Most mature: backend services, command-line tools, embedded systems - Least mature: frontend (WebAssembly approach not recommended) - Growing adoption in existing C codebases (Git, CPython considering Rust) #### ⏱️ [00:50:20](https://www.youtube.com/watch?v=q9xD36NCtZ8?t=3020) Governance Without BDFL - Team-based decision making (language, library, compiler teams) - RFC process for major changes with motivation and design rationale - Final Comment Period (FCP) voting requires all but 2 team members - Smaller changes use API Change Proposals (ACP) or Major Change Proposals (MCP) #### ⏱️ [00:58:45](https://www.youtube.com/watch?v=q9xD36NCtZ8?t=3525) Editions and Backward Compatibility - Editions enable breaking changes while maintaining compatibility - Different crates can use different editions in same project - Six-week release cycle with feature flags for experimental features - Strong backward compatibility guarantee for existing code ## 📚 References - [Tokyo async runtime](https://tokio.rs) - [Rust RFC process](https://github.com/rust-lang/rfcs) - [TIOBE Programming Community Index](https://www.tiobe.com/tiobe-index/) - [Rust Foundation](https://foundation.rust-lang.org) ## 🗣️ Paraphrase Alice Ryhl explains why Rust has gained significant traction by solving fundamental problems in systems programming. Unlike garbage-collected languages, Rust provides memory safety through compile-time checks using an ownership model where each value has a single owner and borrowing rules prevent data races. This eliminates security vulnerabilities common in C++ while maintaining performance. The language prioritizes reliability through exhaustive pattern matching, explicit error handling, and a type system that catches errors at compile time. While the learning curve around data structure design can be steep, the governance model using RFCs and team consensus has enabled steady evolution without a single decision-maker. ## 📰 Newsletter **Rust Rising: Why This Systems Language is Catching Fire 🦀** If you haven't heard the buzz about Rust lately, you're missing out on one of tech's most exciting developments. Alice Ryhl from Google's Android team just dropped some serious knowledge about why Rust is quickly becoming the go-to language for reliable, high-performance applications. **The "It Just Works" Factor**: Rust's compiler is like having a really smart friend who catches your mistakes before they become production disasters. No more null pointer exceptions, no more buffer overflows that turn into security nightmares. When your Rust code compiles, it genuinely tends to work. **Perfect for Backend**: While you might stick with TypeScript for frontend work, Rust shines for backend APIs and services where reliability matters. Think of it as insurance against those 3 AM wake-up calls from production issues. **Learning Resources**: Yes, there's a learning curve around the ownership model and borrow checker, but the payoff is huge. Start with the official Rust Book and try some command-line tools before diving into web services. **Community Win**: The governance model is fascinating - no single dictator, just teams making decisions through RFCs. It's open source collaboration at its finest. Ready to rust-ify your next project? The ecosystem is maturing fast, especially for backend and CLI tools. 🚀 ## ✅ Action Items #### DevRel - Create Rust learning path for backend developers transitioning from TypeScript/Java - Develop workshops on ownership model and borrow checker concepts with hands-on exercises - Build comparison guides: "Rust vs X" for popular backend languages - Establish Rust office hours for developers struggling with data structure design patterns #### Community - Organize Rust study groups focusing on practical backend applications - Create mentorship program pairing experienced Rustaceans with newcomers - Develop "first good Rust issue" rotation for open source projects - Host cross-project discussions on async runtime patterns and best practices #### WordPress - Evaluate Rust for performance-critical WordPress Core components - Research Rust-based CLI tools for WordPress development workflow - Explore Rust for WordPress.com infrastructure reliability improvements - Investigate Rust for Core Performance team profiling and optimization tools ## 🧪 Hypotheses - Rust adoption will accelerate in backend services as teams prioritize reliability over development speed - The ownership model learning curve creates a natural filter ensuring committed developers join the ecosystem - Memory safety guarantees will drive enterprise adoption for security-critical applications - The RFC governance model will enable faster evolution than BDFL-led languages in contested decisions - Compile-time error prevention reduces debugging time sufficiently to offset initial learning investment ### 📊 Methodology - Survey developers on time spent debugging memory-related issues in C++ vs Rust projects - Measure security vulnerability rates in comparable codebases across languages - Track enterprise adoption patterns and decision factors through case studies - Analyze RFC process efficiency vs traditional BDFL decision-making speed - Monitor learning curve data through developer bootcamp completion rates and retention ### ❓ Questions - How does Rust's compile time compare to equivalent TypeScript/Java projects at scale? - What percentage of C++ security vulnerabilities would Rust's memory safety prevent? - How do teams handle the cultural shift from "move fast and break things" to "make it compile correctly first"? - What patterns emerge for gradually introducing Rust into existing codebases? - How does async performance in Tokyo compare to Node.js event loop implementations? ### 🔮 Future Research - Integration patterns for Rust microservices in polyglot architectures - Developer productivity metrics comparing Rust vs traditional backend languages - Security audit effectiveness in memory-safe vs traditional languages - Training program optimization for accelerating Rust adoption in existing teams - Economic analysis of bug prevention vs development velocity tradeoffs ### 💡 Implications - **Practice**: Backend teams may need to restructure data models around ownership rather than object-oriented patterns - **Policy**: Security-critical applications may mandate memory-safe languages, accelerating Rust adoption - **Education**: Computer science curricula should include ownership model concepts alongside traditional OOP - **Funding**: Investment in Rust tooling and ecosystem development likely to increase with enterprise adoption ### 🧠 Learning Styles Assessment Reading level estimate: **Grade 12-14** using Flesch-Kincaid (technical terminology, complex concepts) #### 👀 Visual learners - **Present**: Code examples, ownership diagrams, memory layout illustrations - **Improve**: Interactive ownership transfer visualizations, borrow checker decision trees, async runtime architecture diagrams #### 🔊 Aural learners - **Present**: Video interview format, spoken explanations of concepts - **Improve**: Rust concept podcast series, audio-guided coding exercises, pronunciation guide for Rust terminology #### 🗣️ Verbal learners - **Present**: Clear analogies (ownership like exclusive car keys), defined technical terms - **Improve**: Glossary of Rust vs familiar language mappings, story-driven examples of bug prevention #### 🧩 Kinesthetic learners - **Present**: Code examples to try, hands-on ownership experiments - **Improve**: Interactive ownership simulator, step-by-step borrow checker challenges, build-your-own-vector exercise #### 🧠 Logical learners - **Present**: Systematic comparison tables, RFC process flowcharts, type system rules - **Improve**: Formal verification examples, performance benchmarks, security vulnerability prevention matrices #### 🧑‍🤝‍🧑 Social learners - **Present**: Community discussion of governance model, team decision-making processes - **Improve**: Rust study group guides, pair programming exercises, community mentorship matching #### 🧘‍♀️ Solitary learners - **Present**: Self-contained code examples, individual concept exploration - **Improve**: Progressive challenge sets, self-assessment quizzes, reflection prompts on ownership design #### 🌿 Naturalistic learners - **Present**: Ecosystem metaphors, organic growth of Rust community - **Improve**: Language evolution timeline, ecological thinking about memory management, sustainability of software practices ### 📊 Accessibility Assessment #### Screen reader semantics - **Present**: Clear heading hierarchy, descriptive link text for references - **Improve**: Code block descriptions, technical diagram alt text, timestamp navigation labels #### Keyboard navigation - **Present**: Standard text content accessible via keyboard - **Improve**: Skip links for video segments, keyboard shortcuts for code examples #### Contrast and readability - **Present**: Standard text meets contrast requirements - **Improve**: Code syntax highlighting accessibility, technical term highlighting #### Text resizing and reflow - **Present**: Text content scales appropriately - **Improve**: Code block responsive design, diagram scaling #### Media and captions - **Present**: Video transcript provided - **Improve**: Timestamp synchronization, technical term spelling in captions, audio descriptions #### Forms and interactions - **Present**: No complex interactions in content - **Improve**: Interactive code examples need accessibility testing ### 🌍 DEIB Assessment #### Cultural breadth - **Present**: Technical focus without cultural assumptions - **Improve**: Global perspective on programming language adoption, international community examples #### Inclusive language - **Present**: Gender-neutral technical language, avoided idioms - **Improve**: Plain language summaries for complex concepts, expanded technical glossary #### Neurodiversity support - **Present**: Clear structure, logical progression - **Improve**: Concept chunking with breaks, consistent terminology, predictable format #### Representation - **Present**: Female engineer perspective in male-dominated field - **Improve**: Diverse pathway examples into systems programming, varied career backgrounds #### Psychological safety - **Present**: Acknowledges learning difficulties without judgment - **Improve**: Normalize struggling with ownership concepts, emphasize growth mindset ### ✅ Logical Validity #### Strong reasoning - **Memory safety argument**: Deductive reasoning from language design to security outcomes, supported by concrete examples of kernel exploits - **Compilation success correlation**: Inductive reasoning from developer experience reports, though acknowledges limitations ("in quotes") - **Performance comparison**: Causal reasoning about garbage collection overhead with specific latency examples #### Fallacies - **Appeal to popularity**: "Rust has overtaken PHP and Go" - popularity doesn't prove technical superiority, though used appropriately as adoption indicator - **Hasty generalization**: "When it compiles, it works" - acknowledged as imperfect but captures meaningful pattern in developer experience #### Tone of voice Professional yet conversational, educational without condescension, acknowledges complexity while maintaining enthusiasm for the technology. ### 🛡️ DARVO Analysis No DARVO patterns detected. Content focuses on technical explanation and comparison rather than defensive posturing. Alice acknowledges limitations (steep learning curve, ecosystem immaturity) rather than deflecting criticism. ## 🎯 Conclusion Rust represents a significant evolution in systems programming by solving fundamental reliability and security problems through compile-time guarantees. While the ownership model creates a learning curve, the payoff includes memory safety without garbage collection overhead and the "when it compiles, it works" developer experience. For teams prioritizing reliability over rapid prototyping, especially in backend services and systems programming, Rust offers compelling advantages. The mature governance model and growing ecosystem suggest continued adoption across industries requiring both performance and safety. ## 🧱 Refactor Appendix ### 📚 Literature Split Pad ### Rust eliminates null pointer exceptions through enum types > [!quote] [Why Rust is different, with Alice Ryhl](https://www.youtube.com/watch?v=q9xD36NCtZ8) by [[Alice Ryhl]] via [[YouTube]]. Published [MISSING]. Accessed {{date:YYYY-MM-DD}}. > "There's no null checking and this is done through you know it has this enum type which I mean I think Typescript can do something similar." Rust uses Option enum instead of nullable references, forcing explicit null checking at compile time unlike Java's runtime null pointer exceptions. [view highlight](https://www.youtube.com/watch?v=q9xD36NCtZ8) #xref #articleseed ID:rw_null_safety ### Memory safety bugs in C++ become security vulnerabilities > [!quote] [Why Rust is different, with Alice Ryhl](https://www.youtube.com/watch?v=q9xD36NCtZ8) by [[Alice Ryhl]] via [[YouTube]]. Published [MISSING]. Accessed {{date:YYYY-MM-DD}}. > "If you make a mistake, in C++ when you make a mistake there, now it's actually a security vulnerability most of the time." Simple programming errors like buffer overflows or use-after-free in C++ can be exploited by attackers, while Rust prevents these at compile time. [view highlight](https://www.youtube.com/watch?v=q9xD36NCtZ8) #xref #articleseed ID:rw_memory_security ### Documentation examples become automated tests in Rust > [!quote] [Why Rust is different, with Alice Ryhl](https://www.youtube.com/watch?v=q9xD36NCtZ8) by [[Alice Ryhl]] via [[YouTube]]. Published [MISSING]. Accessed {{date:YYYY-MM-DD}}. > "Rust makes all examples into tests. This means that if you change the underlying code now your test fails." Rust automatically tests code examples in documentation comments, ensuring examples stay current with API changes and preventing outdated documentation. [view highlight](https://www.youtube.com/watch?v=q9xD36NCtZ8) #xref ID:rw_doc_testing --- ### 🔖 Atomic Split Pad (Zettel Candidates) #### Ownership model prevents double-free memory errors - Single owner per value eliminates cleanup coordination problems - Moving ownership transfers responsibility, making original variable unusable - Links: [[Memory Safety]] [[Garbage Collection Alternatives]] #### Borrow checker enforces reference lifetime safety - References cannot outlive their underlying data - Prevents simultaneous mutable and immutable access - Links: [[Thread Safety]] [[Compile Time Verification]] #### RFC process enables consensus-driven language evolution - Teams make decisions through documented proposals and Final Comment Period voting - No benevolent dictator for life unlike Python or Linux - Links: [[Open Source Governance]] [[Technical Decision Making]] --- ### ✏️ Fleeting Queue (Extract by Selection) - Investigate Tokyo async runtime performance vs Node.js event loop — context/https://www.youtube.com/watch?v=q9xD36NCtZ8 #fleeting #inbox - Research Rust Foundation grant programs for student contributors — context/https://www.youtube.com/watch?v=q9xD36NCtZ8 #fleeting #inbox - Compare RFC process efficiency to other open source governance models — context/https://www.youtube.com/watch?v=q9xD36NCtZ8 #fleeting #inbox --- ## Full Transcript [00:00] What would your pitch be on why it's [00:02] worth checking out Rust or working with [00:04] Rust? You need a language that's [00:06] reliable that's going to have as few [00:08] bugs as possible. That's the idea of [00:10] Rust. What is the ownership model? [00:11] >> The idea that if you have a variable [00:13] containing some object, then the object [00:15] is only there. So, it's kind of [00:17] exclusive. We talked about memory [00:18] safety, but there is a keyword in Rust [00:20] called unsafe. Generally, when unsafe is [00:23] used, it's to add a new features to the [00:25] language. As long as you design your API [00:27] right, you can add new language features [00:29] by using unsafe. What are additions? [00:32] Additions are basically the way that [00:34] Rust makes breaking changes without [00:36] breaking people because they might [00:38] change the syntax of the language. Do [00:41] you use any of the AI tools for your [00:43] day-to-day work contributing to Rust [00:45] projects? So, I have been trying to use [00:48] them. Honestly, [00:53] Rust is quietly spreading as a language [00:55] of choice to build reliable and [00:56] performant applications. But what makes [00:58] it different? Ellis Real is a software [01:00] engineer working on Google's Android [01:02] Rust team, a core maintainer of Tokyo, [01:04] the de facto async runtime for Rust, and [01:07] is a Rust language team adviser. In [01:08] today's conversation, we cover the pitch [01:11] on why Rust is worth to consider whether [01:13] you're using TypeScript or C++ today. [01:15] how concepts like ownership, the borrow [01:17] checker, and the unsafe keyword work, [01:19] and what are things that trip up [01:21] newcomers to Rust, how the language is [01:23] governed without a benevolent dictator, [01:25] and how RFC's and additions work, and [01:27] many more. If you want to understand [01:29] what makes Rust different and why so [01:31] many engineers say once it compiles, it [01:33] works, this episode is for you. This [01:35] episode is presented by Antithesis. [01:38] Verify your systems correctness without [01:39] human review or traditional integration [01:41] test and avoid bugs or outages. This [01:44] episode is brought to you by Sentry. [01:46] Centry is application monitoring [01:48] software built by developers for [01:50] developers. The first time I used Sentry [01:52] was 10 years ago back at Uber where [01:54] Sentry helped keep us honest on when and [01:56] where our services were breaking. I also [01:58] use Sentry today to help me understand [02:00] if the services and APIs I built for the [02:02] pragmatic engineer are healthy or not. [02:04] Sentry shows you the full context on [02:06] issues, stack traces, user actions, [02:08] environment details, and even the exact [02:10] line of code that caused the issue. It [02:13] supports pretty much every modern tech [02:14] stack. TypeScript, JavaScript, Python, [02:16] Go, and others. It works on back and [02:18] front and mobile, you name it. One new [02:20] feature Sentry launch is Seir, their AI [02:22] debugging agent. Let me show you. I open [02:24] the Seir agent and ask about what are [02:26] some repeated errors happening on my [02:28] back end. Seir figures out that a [02:30] repeated issue is a network call [02:32] failure. I can then ask for more details [02:34] and debug more efficiently with this AI [02:36] agent integrated neatly in this entry. [02:38] Sierra is a neat tool to fix the hard [02:40] issues, the ones that are just hard to [02:42] debug. Check out Sentry at [02:44] centry.io/pragmatic [02:45] and start monitoring today. Alice, [02:48] welcome to the podcast. [02:49] >> Thank you for having me. [02:50] >> It It's really nice to have you here. [02:52] How did you get into software [02:53] engineering? [02:54] >> It actually all started with Minecraft. [02:56] >> No way. [02:57] >> I wanted to write my own mod for [03:00] Minecraft, so I learned Java. I didn't [03:02] get very far with the Minecraft modding, [03:04] but that's where it started. [03:06] >> How did you continue? Did you go to [03:07] university? This was just before I [03:09] started in high school. And then after [03:11] high school, I had a year where I worked [03:14] uh full-time as a software engineer. And [03:17] then I moved on to starting my bachelor. [03:19] Did that for 3 years and then I did a [03:21] masters for 2 years. [03:22] >> How did you end up at Google? Was that [03:24] straight out of university? [03:26] >> Actually started part-time at the same [03:29] time as when I started my masters and [03:30] then I switched to full-time after I [03:32] finished. [03:33] >> How did you get involved with the Rust [03:34] community? Was was it at Google? Was it [03:36] before Google? [03:37] >> Oh, way before. [03:38] >> Way before. [03:39] >> I've been doing Rust for a long time. [03:41] When I was in school, I spent a lot of [03:43] time on the what's called the Rust users [03:46] forum. Well, I was answering questions [03:47] really. I have maybe 10,000 posts on [03:49] there or something. At some point, I [03:51] also started being active in some chat [03:54] servers, the Discord server for [03:56] something called Tokyo. I kept doing [03:58] that, answering questions. When I saw [04:01] common questions, I would uh fix the [04:03] documentation. That's how I got into [04:05] Tokyo, which I'm now one of the [04:07] maintainers of. [04:08] >> And then for those of us not as familiar [04:11] with Rust and and Tokyo, uh what is [04:13] Tokyo inside of Rust and why is it [04:15] important? [04:16] >> So Tokyo is well, it's an asynchronous [04:19] runtime for Rust. You can think of it as [04:22] the standard library for Rust when [04:24] you're using async. I mean, if you [04:25] compare with something like JavaScript [04:28] in the browser, you might compare Tokyo [04:31] with the browser itself. For example, in [04:33] JavaScript, you have this loop, this [04:35] event loop which has all the tasks that [04:38] are able to run and then they get [04:40] executed one after the other. And [04:43] especially if you use the await stuff, [04:46] then you can have tasks pause and then [04:48] another task start running on the same [04:50] thread. And Tokyo does something [04:51] similar. It has a queue of things that [04:56] are able to run and then it will run [04:58] them. So unlike JavaScript, Tokyo can be [05:01] multi-threaded. So you can have multiple [05:03] cues running in parallel. [05:05] >> This seems like a pretty core part of of [05:07] Rust as a language, as a as a ecosystem. [05:11] How did you gravitate towards this? Cuz [05:12] it sounded like you were, if I [05:14] understand, you were lurking on the Rust [05:16] forums. You were helping out here and [05:18] there. What drew you to this part of the [05:21] language or or the e ecosystem, should I [05:24] say? I think part of what I liked about [05:27] Rust is this feeling that as you write [05:31] the code when it compiles it works. I [05:34] mean this has to be in quotes right [05:35] because obviously it's possible that [05:38] there are bugs but this is something a [05:40] lot of people say about Rust and there's [05:42] a reason people say it even though it's [05:44] not necessarily literally true. [05:45] >> How do some other languages compare [05:48] >> to begin with? I think to have a [05:50] language that feels this way you have to [05:51] have a type system. That's where it all [05:53] starts. Yeah, I do think that even [05:56] compared to other languages with type [05:58] systems, I think Rust does a better job [06:01] than many languages, even others with [06:04] type systems. I mean, the the classic [06:07] example is Java's null. It was Tony hair [06:11] who invented uh the null and he called [06:14] it his billiond dollar mistake because [06:17] it's so easy to have I mean every time [06:20] you call a function you might have a [06:21] crash in your program [06:22] >> and in Rust I think they're really good [06:24] at making sure that when you call a [06:26] function there's no chance that it might [06:28] be null right that problem just doesn't [06:30] exist so you can't have that kind of [06:32] crash [06:33] >> and so you have to explicitly say this [06:36] object might be null and then the [06:39] compiler will force you to check for [06:40] null before you use it. So you can't [06:43] forget like you can in Java. [06:45] >> Can we talk about Rust as a whole? This [06:47] was a language that was created in in 20 [06:49] years ago in 2006 and it feels like it's [06:54] become a lot more popular over time. Do [06:57] you know of like the scale that Rust is [07:00] at in terms of usage or popularity or or [07:03] things that among the Rust Rust [07:04] community numbers that are known there? [07:06] One thing I found kind of funny, I I [07:08] checked here all the day and uh we have [07:10] actually overtaken PHP and Go on the [07:13] Tyobi index. [07:15] >> Oh, this that that index tried to [07:17] estimate the the usage of languages, [07:20] right? Usage or popularity or something [07:22] like that. [07:23] >> Wow. Cuz the feeling I have again in [07:25] general is that Rust is popping up in [07:26] more and more places. More companies are [07:28] building on Rust. Oxide is a good [07:30] example. they decided to go all in on [07:32] Rust and like there's a sense of of Rust [07:35] is is becoming a popular place to build [07:39] I guess high performance applications [07:41] even increasingly contributing to to the [07:44] kernel as an engineer who you know might [07:46] know other languages from like [07:48] Typescript Java etc. What would your [07:51] pitch be on why it's worth checking out [07:55] Rust or working with Rust? [07:56] >> That depends a lot on which language [07:58] you're coming from. Oh, let's come from [08:00] Typescript. It's it's one of the most [08:02] popular languages right now. The pit [08:04] from TypeScript would be a lot different [08:06] than the pit from C++. But okay, so to [08:10] begin with, I think when it comes to [08:12] TypeScript, Rust fits in as the backend [08:15] language. That's where I would put it. I [08:17] wouldn't use it in the front end. I [08:19] think it's a pretty good fit for [08:21] backends, API servers. One way to put it [08:24] is [08:26] you don't want to be waking off at night [08:28] because there are problems with your web [08:30] server. You need a language that's [08:32] reliable, [08:34] that's going to have as few bucks as [08:36] possible. I mean, obviously, it would be [08:38] nice if it had zero bucks, but you know, [08:39] it's going to be hard to get there, but [08:41] as few bucks as possible. That's the [08:43] idea of Rust. I mean, I already [08:45] mentioned null, but it does a lot of [08:47] stuff like that. So there's no null [08:49] checking and and this is done through [08:51] you know it has this enum type which I [08:54] mean I think Typescript can do something [08:56] similar. TypeScript is actually kind of [08:58] good on that front but but okay the [09:00] other thing I think is quite good is uh [09:03] error handling. So on one hand Russ [09:05] doesn't really use exceptions. So it [09:08] actually returns the error as a value. [09:11] So you return a value that's either [09:13] using an enum either the result or the [09:17] error. And the way this is done is that [09:19] there's an operator question mark which [09:23] says so you write my function and then [09:26] question mark at the end. And this means [09:28] if this function fails return the error. [09:32] So it's really easy to handle errors but [09:34] it's not zero characters like like it is [09:36] with exceptions right? So it's explicit [09:38] on the other hand and if you forget to [09:41] put the question mark that's a [09:42] combination error. [09:43] >> Wonderful. [09:44] >> So you have to check it. [09:45] >> Yeah. [09:45] >> Right. And of course you can also handle [09:46] that manually. But but the point is it's [09:49] this idea of there are these things [09:51] where you write some code and there's [09:53] some implicit error condition you didn't [09:55] think of [09:57] and now you just you know took down your [10:00] server or something. Another thing I [10:02] would I quite like is how it handles [10:05] documentation. How does it for one when [10:09] you have a comment you make it into a [10:11] documentation comment by having three [10:12] slashes instead of two. Now the thing is [10:15] you can of course write examples in your [10:17] documentation and Rust makes all [10:21] examples into tests. [10:24] This means that if you change the [10:26] underlying code now your test fails. And [10:30] so this means that you can't even you [10:33] can't forget to update your examples in [10:34] your documentation. Yeah. And I guess [10:36] there's also things like you can you [10:40] forget to initialize a variable in Rust? [10:42] >> I mean, no, [10:44] >> it doesn't allow you, right? The [10:45] >> comp you have to set a value before you [10:47] use it for the first time. [10:48] >> Yeah. And I guess the things with uh [10:49] checking the format of incoming JSON, it [10:52] also forces you to do that. [10:53] >> Yeah. So there's a pretty cool library [10:55] called Surya in Rust where you you have [10:58] your strct so your type you know with [11:00] fields and then you can say I want to be [11:03] able to pass this from for example JSON [11:06] and then SA will it's a macro it will [11:10] generate code which checks the JSON that [11:13] it's in the same format it has all the [11:14] fields you need and they have the right [11:16] types and it generates native code [11:18] that's specific to that particular shape [11:21] of JSON. So the charge are really [11:22] efficient [11:22] >> and again yeah so it helps you avoid [11:25] errors and there's this thing which [11:27] again I I learned just very recently [11:29] thanks to thanks to you as we're talking [11:32] ahead of this is the switch statement [11:34] right so in almost every language you [11:36] have a you have a switch for an enum and [11:38] you handle cases and then you might have [11:40] a default or you know everything else [11:42] and sometimes you forget one of them [11:44] it's not a big deal or maybe it's a big [11:46] deal but in Rust you cannot do that [11:47] either right [11:48] >> that's right so in rust it's not called [11:51] pitch it's called match but it's the [11:53] same idea you can match on your enum and [11:55] then you can have a branch for each [11:58] possibility at rank B and if you are [12:00] missing one that's a compiler error of [12:02] course you can have a catch all case if [12:04] you want to but most of the time you [12:07] would just list all the cases and then [12:09] in the future when you add a new variant [12:11] the compiler will tell you oh you need [12:13] to update your code here here and here [12:15] and I think this is kind of leads to [12:18] another way that Rust really helps [12:21] with reliability, which is that if [12:23] you're refactoring, [12:25] I think Rust is really good at telling [12:27] you all the places you need to update. [12:30] I've done this sometimes where I would [12:32] refactor something. I change the code. I [12:34] change the return type or whatever it [12:36] is, and then I just fix the compiler [12:39] errors and until the compiler stops [12:42] shouting. And then once I've done that, [12:44] I've updated every place I need to [12:46] update. I I get a sense that the [12:48] language designers have thought really [12:51] hard of what are ways that typically go [12:54] wrong in a lot of other programming [12:57] languages and they just try to fix it [12:59] through the compiler. Like the [13:00] documentation example is is the one [13:02] where I'm still like wow like it happens [13:05] all the time like you you have a comment [13:07] example or not and then it gets out of [13:09] sync and we always complain about this [13:10] and we don't know how to fix it. I think [13:12] we've been I I know I've been [13:13] complaining or like for you know like a [13:15] decade plus this dross is the first [13:17] language where I hear a like an actual [13:20] solution even if it's not a perfect one [13:22] and I really think this pattern just [13:24] every where you look you have this kind [13:27] of thing again and again that oh if you [13:31] messed up they you know either it won't [13:35] compile or at the very least there's a [13:38] lint for it they just catch a lot of [13:40] cases at compile Now, we've had the [13:42] pitch from Typescript [13:44] or similar languages. What about the [13:47] pitch from C++? So, here I actually [13:50] think it's even stronger. The thing with [13:53] C++ is that if you make a mistake, [13:57] right, in in JavaScript, maybe you take [13:59] down your server, which is already bad [14:01] enough, but in C++ when you make a [14:03] mistake there, now it's actually a [14:06] security vulnerability most of the time. [14:08] >> Mhm. If you do something as trivial as [14:10] you did an off by one in your IRA or [14:12] whatever it might be, that's a security [14:14] vulnerability and that this just keeps [14:17] happening. [14:18] >> Small mistakes become security [14:19] vulnerabilities. And in Rust, so Rust is [14:22] memory safe, right? I mean, we talked a [14:24] bunch about different ways that Rust is [14:27] more reliable. And we didn't even touch [14:28] memory safety. [14:29] >> Let's talk about memory safety. Memory [14:31] safety is this idea that no matter how [14:34] stupid the code you write is, it's not [14:37] going to have a certain class of bugs. [14:40] And this is the, you know, the kind of [14:42] bug that usually leads into security [14:45] vulnerabilities. You know, the kind of [14:46] thing where you read past the array and [14:49] you just look at random memory or you [14:53] destroyed an object and then you used it [14:55] afterwards. So now you actually touched [14:57] the memory of some other random object. [14:59] >> Yep. And then attacker who figures this [15:03] out could populate something there [15:06] eventually get that code somehow [15:08] executed or configuration read and then [15:10] boom like the classic example in the [15:12] kernel is let's say you have some object [15:15] and you manage to make it so that the [15:17] object that's actually there right [15:19] because the original object is gone so [15:22] the memory got reused and now it has a [15:25] task strct it's called and that's [15:27] basically your process [15:29] and it has a field called user ID. And [15:33] it's pretty common for code to write [15:35] zero zeros to memory. But if you write a [15:38] zero to the user ID, [15:40] >> now you're root. [15:41] >> That's a root user. [15:42] >> Yeah, that that's a really classic way [15:46] of exploiting this kind of [15:47] vulnerability. [15:48] >> And then once an attacker manages to do [15:49] that, they can take over the [15:53] whatever your server or whatever is [15:55] running. And then of course from there [15:56] on it can just spiral out of control, [15:58] right? Once you're rooe, you're lost. [16:00] >> Yeah. [16:00] >> Do I understand that a very strong pitch [16:02] of rust, especially coming from C++, is [16:05] memory safety eliminates this whole [16:08] class of bugs, which which are which can [16:10] turn into security vulnerabilities, [16:11] which are one of the most serious [16:13] threats any any software can have. [16:16] >> Lost all of the reliability ones I [16:18] mentioned in the beginning. [16:19] >> That that is a pretty good pitch. We [16:21] just talked about how Rust offers [16:22] several safety features like memory [16:24] safety, error handling, and a type [16:25] system. This is because reliable is not [16:28] about one thing but several things at [16:31] once. This is where I need to mention [16:33] our presenting sponsor antithesis. Like [16:35] the designers of Rust, antithesis also [16:38] believes there's no one silver bullets [16:40] for reliability. You need many different [16:41] tools and approaches. This is why [16:44] they've released Hegel Rust, a free [16:46] open- source property based testing [16:47] library for Rust built by the team [16:49] behind Hypothesis. Rust compiler is [16:52] brilliant at catching whole categories [16:54] of bugs at compile time, but at the edge [16:56] cases, the weird input combinations, the [16:59] assumptions that turn out not to hold, [17:01] those runtime bugs need a different [17:03] tool. Hegel provides powerful ergonomic [17:06] property based testing for fast local [17:08] development. It'll check edge cases you [17:10] never thought of and catch unknown [17:12] unknowns before they bring down [17:13] production. And if you try Hegel and [17:15] like it, your Hegel test will run an [17:16] antithesis as written, so you can easily [17:19] add determinism and the world's most [17:21] thorough runtime verification to your [17:23] reliability arsenal. Go to hegel.dev to [17:25] learn more. I'd also like to mention two [17:27] conferences this year where I'll be [17:29] talking and where we can also meet. On [17:32] the 4th of June, I'll be doing a keynote [17:34] at craft conference in Budapest, [17:35] Hungary. This conference is one of the [17:37] very best ones in Europe focused on [17:39] software craftsmanship and one where I'm [17:41] a returning speaker. For more details, [17:43] check out craft--comf.com. [17:46] And on the 15th and 16th of September, [17:48] I'll be doing a keynote at ldx3 in New [17:51] York. This is the festival for modern [17:53] engineering leadership. Last year, I was [17:55] at LDX3 in London. And so, I'm excited [17:57] to be back this time in New York. For [17:59] more details about this conference, head [18:01] to leadub.com. [18:03] If you'll be at either of them, I'll see [18:04] you there. And with this, let's get back [18:07] to Rust and to Alice. I wanted to ask [18:10] why Rust is getting so popular, but I [18:13] think we're starting to answer this [18:14] question, right? [18:15] >> I think where Rust is really unique is [18:19] in the combination of things. So on one [18:22] hand, it it doesn't have a garbage [18:24] collector and it it's usable in [18:26] low-level context like the Linux kernel [18:29] or firmware or whatever. [18:30] >> Why is it a good or a bad thing to have [18:32] a garbage collector? Java has a garbage [18:34] collector. C# has a garbage collector. [18:36] So, a garbage collector says once you've [18:39] done using your objects, there's going [18:41] to be a little piece of code that checks [18:44] all of your co your objects and says [18:46] this is not used anymore and then it [18:47] cleans it up. Whereas in languages like [18:50] Rust or C++, [18:52] the variable is cleaned up at the end of [18:53] the scope when it goes out of scope. And [18:55] in the other one, they have to detect [18:57] afterwards. And this kind of little [18:59] piece of code that runs every so often [19:01] to check all your objects. For embedded [19:04] use cases, this might simply be not [19:06] possible or unacceptable. [19:08] >> The the performance overhead the the [19:10] fact that you cannot you will not be [19:11] able to control the memory as much. [19:12] >> Even for back end, it can be a problem [19:15] because if you have a request incoming [19:17] right when it checks all of your objects [19:19] like you have some sort of latency spike [19:21] where you it takes much longer to to [19:23] reply. So that's one of the reasons it [19:26] can be helpful in in back end as well. [19:27] >> For someone who has not yet seen Rust [19:30] code, how would you describe it? how it [19:32] compares to for example TypeScript. [19:34] >> I mean in many cases Rust code is [19:37] similar to many of the other languages. [19:39] It has braces. It's not like Python [19:42] where you know you use indentation. It [19:44] has braces. It has semicolons and so on. [19:46] So so it's pretty easy to read even if [19:48] you don't if if if you know some similar [19:50] languages you can look at it and you can [19:52] get a rough idea. [19:53] >> Yeah, I think I think you'll figure it [19:55] out. It's not that it's not that [19:56] foreign. Rust has a a learning curve on [19:59] the side of the more difficult languages [20:01] to learn. What do you see devs typically [20:03] struggle with who are new to Rust and [20:06] and what are the things that just makes [20:07] it click for them? I think the most [20:10] tricky thing people run into is how [20:13] should you put together your data [20:15] structures? I mean for your code you can [20:17] mostly do the same things as you can in [20:20] other languages. I mean that's not [20:21] entirely true but the big thing is [20:24] really the data structures. So if you [20:26] have I don't know what would be a good [20:28] example let's say some sort okay let's [20:30] just say you have a object for a book [20:33] and it has an array of pages and then [20:35] you have an object for each page if I [20:38] was writing typescript I would probably [20:40] have a book field in the page that [20:42] references the book and then the book of [20:44] course also references the page right so [20:46] it's cyclic so the book goes to the page [20:49] goes back to the book and in Rust you [20:51] usually have to design your objects so [20:54] that they're not cyclic. It has to be a [20:57] tree or a deck if you know what that [21:00] mean. [21:00] >> Yeah. Yeah. The di as graph. So if you [21:03] go out and actually start to use [21:05] reference counting, it becomes possible [21:07] to have cyclic objects with some cabbage [21:10] like you mentioned. But what people end [21:13] up doing when they're langu learning the [21:15] language is that they try to make cyclic [21:18] objects without anything like that. and [21:22] then it just doesn't work and they're [21:24] going to run into all sorts of problems [21:26] in their code while they're [21:27] constructing. They're maybe creating [21:29] their thing and then they get a compiler [21:32] error and then they try to change the [21:34] code and they get a compiler error [21:35] again. But the the thing that a lot of [21:37] people struggle with is that they keep [21:39] trying to change the code when the [21:41] solution is to change the strct. [21:43] >> I can see how that's uh frustrating. [21:46] Rust has another [21:48] model that might be new for especially [21:51] for for people coming from language [21:52] types is Rust's ownership model. What [21:55] what is the ownership model? The [21:57] ownership is just the idea that if you [21:59] have a variable [22:01] containing some object then the object [22:04] is only there. It's kind of exclusive. [22:06] So for example, if you have a variable [22:10] let A equals your string or whatever and [22:13] then you do let B equal to A, then this [22:16] is a move. And so this means that using [22:18] A afterwards is now a compiler error [22:21] because its contents have been moved [22:23] away. And of course this is important [22:25] when we don't have a garbage collector [22:27] because then when B goes out of scope, [22:30] it has to clean up the string. Now if A [22:32] was also valid then when they both went [22:35] out of scope it would clean up the [22:37] string twice which is not legal. In most [22:40] other languages the garbage collector [22:41] takes care of this. A and B just go out [22:43] of scope do nothing and then later it [22:45] cleans up the string. But here we [22:48] actually have to do it when we go out of [22:49] scope. And the ownership model allows [22:52] you to move from A to B and then A [22:55] becomes inactive or unusable and does [22:58] not get cleaned up because it doesn't [22:59] have a value to clean up anymore. [23:01] >> And how does reference counting relate [23:03] to all all of this? [23:04] >> In Rust, we have a bunch of different [23:07] types which are essentially different [23:09] kind of pointers. And one of the [23:11] pointers is it's called arc. It's and [23:14] it's reference counter. And so the idea [23:16] is you have some object somewhere and [23:18] then you have an arc to the object and [23:22] what you can do is you can call clone on [23:23] the arc and this increments a counter [23:26] and now you have two arcs to the same [23:28] underlying memory. So the object might [23:30] be really big but you have two arcs that [23:33] share the same memory and when they go [23:35] out of scope the counter is just [23:37] decremented and when the counter reaches [23:40] zero the object is cleaned up. So this [23:42] is a way of saying this object actually [23:45] needs to be in multiple places. There's [23:46] no one place that owns it. And so this [23:50] way you can use a counter to know how [23:51] many owners are there. And then when the [23:54] last owner goes away, it gets cleaned [23:55] up. [23:56] >> And on Rust also is another thing that [23:58] was new to me, the borrow checker. [24:00] >> So another pointer type we have in Rust [24:02] is called the reference. And a reference [24:05] is basically all it is is that it it's a [24:09] pointer to the object [24:11] and that's it. So we do no checking at [24:14] runtime. So of course this means at [24:16] compile time we have to make sure that [24:19] the last use of the reference has to be [24:21] before the object goes out of scope. And [24:24] creating a reference is called [24:25] borrowing. Right? The owner owns the [24:28] value. And now we have a borrow of the [24:31] value. the the reference and the borrow [24:34] checkout checks that the reference is [24:38] like the last use of the reference is [24:40] before the object goes out of scope. So [24:43] if you have say a let's say you have an [24:45] immutable reference you're reading then [24:48] if you change the object let's say it's [24:51] in vector. So I have a mut an immutable [24:54] reference I'm reading element five and [24:57] then I change the vector I call clear. [25:00] Then the borrow checker also ensures [25:02] that you can't use the reference to [25:05] object five afterwards. [25:06] >> Yes. Because now it has been as soon as [25:09] you change it it it went out of scope. [25:11] It's it's now cleared. Right. Yeah, the [25:13] the the way it works is that if there [25:16] are mutable borrows, it ensures that the [25:19] mutable borrow [25:21] uh ends or starts before or after the [25:25] previous borrows have ended basically. [25:28] So they don't overlap. So you can only [25:30] have one writer at a time or you can [25:33] have any number of readers. It checks [25:35] that on the scope like in a function. [25:37] >> This concept is is is new to me as [25:39] someone who's not used ROS for sure. [25:41] It's very interesting. One thing I've [25:42] read is on forums people complaining [25:45] about fighting so-called fighting the [25:47] borrow checker. What can make it [25:49] challenging? When you write a some code [25:52] that uses the object in a way that [25:54] doesn't follow the rules I mentioned, [25:56] that's a compiler error. And fighting [25:58] the borrow checker is when you, you [26:00] know, can't get out of those compiler [26:03] errors. I guess I think a lot of the [26:06] time this has to do with the strruct. [26:08] One common mistake I see is that if you [26:11] have a strct with a reference in it, [26:14] Rust kind of assumes that it can check [26:17] the scope of that reference like by just [26:20] looking at a single function. But if you [26:22] have your strct and you're passing it [26:23] over functions that it might not be [26:25] possible to make that analysis and so [26:27] you just get a compiler error. And so in [26:29] this case the solution is maybe to use a [26:32] different pointer type. For example, the [26:35] reference counterp pointer type often [26:36] solves this kind of bug, right? So the [26:39] solution is again to change the data [26:40] structure. [26:41] >> Yeah, I'm I'm starting to understand why [26:43] you mentioned that data structures were [26:45] a a a place of learning coming from [26:48] other languages. [26:49] Often times the solution seems to be [26:51] just think about your data structures, [26:53] understand them and do it in in the Rust [26:54] way, right? We talked about memory [26:56] safety, but there is a keyword in in [26:58] Rust called unsafe. What does this do [27:00] and in what cases do people typically [27:03] use? When does it make sense to to to [27:05] use and why does it even exist? That's [27:07] just a naive question from me. [27:09] >> So let let me begin with the what and [27:11] let's take the why afterwards. So the [27:13] what is unsafe is the escape hatch [27:17] essentially. So I explained before how [27:19] there are certain bugs where if your [27:21] program has one of those bugs that's [27:23] usually a security vulnerability. What [27:25] Rust ensures is that if you have no use [27:28] of unsafe, then no matter how stupid [27:32] your code is, you will never have one of [27:34] those bugs. Now, if you do use unsafe, [27:37] then there are still some guarantees, [27:40] but it's a bit weaker because each [27:42] unsafe operation that you can perform [27:45] has a list of rules. And if you violate [27:48] these rules, then you might end up with [27:51] one of these bad bugs. But of course, if [27:53] you don't, then you it's okay. And it's [27:56] interesting to point out here that [27:57] unsafe does not disable the borrow [28:00] checker or anything like that. It just [28:02] gives you a few more operations you can [28:04] perform that are not safe in general. [28:08] And so you have to check yourself. Yeah, [28:11] this is actually okay in this particular [28:13] case to I mean let's take the vector [28:16] example again. Normally when you index [28:19] index five it will say oh let me check [28:22] the length. So if the length is at least [28:25] six [28:25] >> yeah because it starts zero [28:28] >> then it's okay otherwise you get a crash [28:31] but maybe you're writing some super high [28:33] performance code and you want to avoid [28:35] this if you want to avoid this check or [28:38] if you're in a loop every time. So so un [28:41] unsafe will just avoid checks. uh may [28:45] may that be is it runtime or compile [28:46] time checks or both? [28:48] >> What I would say here is that vector has [28:51] two different ways of getting a value. [28:54] There's the you know normal bracket [28:55] operator we'll use for other languages [28:58] which will do the check and crash your [29:00] program if you get it wrong. But there's [29:02] another function called get unchecked. [29:05] And so if you do write veget get [29:06] unchecked five then it will give you [29:10] element five without checking the [29:11] length. And this function like in the [29:15] function signature it says unsafe fn. [29:17] That's the function signature. [29:19] >> And so you can only call this function [29:21] from an unsafe block. [29:22] >> Got it. [29:23] >> And so all that the unsafe block let you [29:25] do is call functions marked unsafe. [29:28] >> And then in practice for sensible use [29:31] cases of unsafe is it usually to do with [29:34] high performance code typically or have [29:36] you se like what what cases have you [29:38] seen which are like legitimate? This is [29:40] a great use case for for unsafe. [29:42] >> So usually it will never show up in say [29:45] a backend server. You would have zero [29:47] uses of unsafe there. Generally when [29:50] unsafe is used, it's to add a new [29:53] feature to the language. Let's say the [29:55] language didn't have a vector. The [29:57] language still has a function to [29:59] allocate memory, a function to free [30:02] memory, a function to [30:05] read at this pointer address. Then you [30:08] could write strct ve the pointer is here [30:12] and this is a raw pointer so it's unsafe [30:14] to use. The length is this. The capacity [30:17] is this. So I might and then you can [30:20] write your little API. Of course the [30:22] fields are private so you can't access [30:24] them from outside the module. I mean if [30:26] I could do ve.length equal 20 just [30:29] access the field that would be pretty [30:30] bad. And so you can write your own [30:35] vector API and using field privacy and [30:38] good API design, you can add a vector to [30:41] the language if it doesn't already [30:42] exist. and unsafe if encapsulated [30:46] properly in this kind of API that [30:49] doesn't permit you to mess it up. Then [30:51] you can have a safe vector that you can [30:53] use from safe code and no matter how [30:56] stupid the thing you do with that vector [30:58] is it's not going to do something bad. [31:00] It's just going to crash or whatever [31:02] check the length properly. As long as [31:03] you design your API right, you can add [31:07] new language features by using unsafe. [31:09] The other classic example would be to [31:10] call into a C library. You can write a [31:12] library that calls into C and you can [31:14] even have an safe API and then you can [31:17] enforce that you only call the C API in [31:19] the right way. [31:20] >> Can we talk about the the Rust [31:21] ecosystem, the broader ecosystem and [31:24] when it comes to this the first thing [31:25] that people come across include myself [31:27] is the crate uh ecosystem. Rust is [31:30] package man manager. What is crate and h [31:33] how does it compare to other package [31:35] managers in like places like npm or or [31:38] pip and in python? So create is just the [31:40] Rust word for a package. So it's just a [31:43] package right of of your code. [31:46] >> So the way it works is that Rust has a [31:48] tool called cargo and cargo is kind of [31:50] um it does a lot of stuff. It's it's [31:52] actually pretty neat tool that's kind of [31:54] all in one. So it will do it's both what [31:57] you use to run your code. You do cargo [31:59] run and it will compile your code. You [32:01] have this thing called cargo tunnel [32:03] where you specify your dependencies and [32:05] other information about your crate. And [32:08] when you do cargo run, it will download [32:10] the dependencies to something called a [32:12] registry, which is basically just a [32:15] directory with all the crates you've [32:16] ever downloaded. [32:17] >> Yeah. [32:18] >> And you can also do cargo test. It will [32:20] run all your tests. Cargo doc, it will [32:22] generate your doc. Cargo test will also [32:25] run your doc tests. There's even [32:27] benchmarks and examples. So, so it's it [32:29] it it does all the whole suite, so to [32:32] say. So you don't need different tools [32:34] to fetch dependencies and run your code [32:37] and generate docs. I think the biggest [32:40] difference from something like pip would [32:42] be that they're not installed to your [32:44] machine, right? [32:46] >> With pip you either install things [32:48] globally or you have these virtual [32:50] environments. So so with cargo it's all [32:53] local. You just run cargo run and it's [32:56] only local to this. The only thing [32:57] that's shared is this registry which is [33:00] just to avoid downloading the same thing [33:02] twice. You told me a funny anecdote [33:05] about Linux tour worlds and his his [33:07] reaction or what he told you about Rust [33:10] and car and cargo [33:11] >> the first time I was at the Linux [33:14] plumbers conference at the very end. So [33:16] Linux wasn't anywhere to to be seen [33:18] throughout the entire conference but the [33:20] at the very end of the social event he [33:22] showed up and I went over to say hi. I [33:25] mentioned I worked on Rust and [33:27] immediately he started telling me about [33:29] how he didn't like cargo and so the [33:32] reason for that is that cargo downloads [33:34] code from the internet and runs it like [33:37] any package manager. [33:38] >> Yep. [33:38] >> And he doesn't want any any code on his [33:41] computer to do that other than his uh [33:44] distributions package manager. He [33:46] doesn't trust anybody else to do that. [33:47] In the node world, we're seeing more [33:50] problems with vulnerabilities being [33:53] injected into packages. Um, just a bad [33:56] actor overtaking packages, you know, [33:57] that they they put in whatever code [33:59] might be from crypto, which is I guess [34:01] the better part to security [34:03] vulnerabilities. [34:05] Does Cargo have this problem as well? [34:08] Just like any package manager that is on [34:10] the internet? [34:12] >> I mean, in principle, yeah. I mean, [34:14] ultimately, if you somehow got a hold [34:18] of, you know, my keys to upload new [34:20] Tokyo versions, you could upload a [34:22] malicious one. I don't think we've had [34:25] much problems with it compared to [34:27] something like npm, but I don't really [34:29] know if we I mean, it's a hard problem, [34:32] right? [34:33] >> It's a hard problem. somebody can [34:35] impersonate the maintainer of a library [34:37] then I mean I think they do do stuff [34:39] like delete uh people scratting [34:42] malicious crates and stuff like that. [34:43] >> Yeah. Where where do you see the Rust [34:45] ecosystem being the most mature and the [34:48] less m and the least mature right now? [34:50] >> My opinion is that the least mature area [34:53] is front end. [34:55] There have been some attempts to compile [34:59] Rust to Web Assembly [35:02] and then run it on the web as a front [35:05] end as a replacement for TypeScript. But [35:08] if I was writing a web server, I would [35:10] totally use Rust for the back end and [35:12] TypeScript for the front end. I would [35:15] not really go the web assembly route. On [35:17] the other hand, [35:19] for for back end, I actually think it's [35:21] a pretty great fit. And there's also [35:24] stuff like command line tools. I think [35:27] it's really really great fit for that. [35:29] And then of course we have we are [35:31] expanding into Linux and we are also [35:34] expanding into a lot of embedded [35:36] projects and there are even projects [35:38] that are like C code bases that are [35:41] starting to say hey it's went into Linux [35:44] maybe we should start using it too. [35:46] Maybe we should have a memory sake [35:48] language too. I know that git is talking [35:50] about it. I know that CPython is talking [35:52] about it. There are probably others. Qo [35:54] maybe. [35:55] >> Can we talk about how the language is is [35:57] built? Who builds Rust? What the process [36:01] for for for doing it? How does it [36:02] compare to a project like Linux? I know [36:04] it's not a language, but but it's still [36:06] a large open source project. I mean, [36:08] it's really an open source project. I [36:10] mean, you may know that MOS that it [36:12] originally originates from Masilla, but [36:14] it's not a Masilla project anymore at [36:16] all. So today there's the rust project [36:21] which has a bunch of different teams. [36:24] There's the language team there's the [36:26] which you know deals with the language. [36:28] There's the library API team which deals [36:30] which decides on the API of the standard [36:33] library. And these teams kind of govern [36:36] it. So it's the people who are these [36:39] teams that run the language. And one [36:41] interesting difference compared to some [36:43] other popular languages like like Python [36:45] or projects like like Linux is they have [36:48] a benevolent dictator for life and Rust [36:51] does not. How is this working and and [36:54] how are decisions made when especially [36:56] when they're contagious or when it could [36:57] help for you know some just someone to [36:59] just make a decision? Honestly, if the [37:01] team doesn't sign off on it, it doesn't [37:03] happen. I mean if something is really [37:05] contentious contentious or really big it [37:08] will probably end up being discussed at [37:11] a conference for example. So there's a [37:14] conference called Rust week where they [37:15] have an event called the Rust all hands [37:17] where they're basically taking all of [37:20] the Rust developers and putting them in [37:22] one place. So if there was a problem [37:25] like that they would probably discuss it [37:27] there. [37:27] >> And how are these teams structured? So [37:29] like you said there's a compiler [37:31] language library and and dev tools at at [37:35] the very least. How do they define the [37:37] boundaries? Is it just a team kind of [37:38] roughly defining them and then you just [37:40] kind of agree? Because as I'm thinking [37:43] at a corporate level like as as a [37:46] company would run there's typically [37:47] teams are are founded often top down [37:49] leadership doesn't mandate this will be [37:51] this team that team there's bottoms up [37:53] happening but often times it's top down [37:55] just because it's easier but here as I [37:57] understand there is no top down it's [37:58] it's people self-organizing yeah really [38:02] when it comes to the design of the [38:04] language the teams are really that's [38:06] really it teams have been pretty good as [38:09] far as I've seen at delegating So I've [38:12] seen them sometimes say we think this is [38:14] a lips API decision and we will go with [38:16] whatever lips API decides. [38:18] >> One thing that is interesting to talk [38:20] about is the RFC process. So there's [38:22] requests for for process. RFC request [38:24] for comment is [38:26] the way the ROS project makes big [38:29] decisions but you know big ones is [38:32] important to say. Basically the way it [38:34] works is let's say you have a language [38:38] feature that's kind of big. For example, [38:40] I had one called derive smart pointer [38:43] which [38:45] basically makes some types in the [38:46] standard library less special. So I mean [38:48] sometimes people begin implementation [38:50] already but the idea is that you write [38:53] the RFC first. [38:54] >> By the way that that's no different [38:55] inside of like at U we had RFC process [38:58] and same thing usually you follow it but [39:00] sometimes you kind of start to build it [39:01] and then just [39:02] >> the idea is you write the the RC first. [39:05] Yeah, I I know. It's just funny how it [39:08] happens everywhere where there's [39:09] engineers. I think it's is to build. [39:11] >> You write this doc and it has a template [39:13] and I think it's actually a pretty good [39:15] template. The idea is the first section [39:18] is I think motivation. Well, the first [39:21] one is summary, but the first important [39:22] one is motivation. So, you explain why [39:25] this feature and then I think they have [39:27] two really interesting sections. They [39:29] have the guide level explanation and the [39:31] reference level explanation. And what [39:34] this is is that in the guide level [39:36] explanation, you explain your feature as [39:40] if you were writing a guide as if the [39:43] feature already existed. And in the [39:45] reference level explanation, you explain [39:46] your feature again as if it already [39:48] existed, but as if it would be in the [39:50] language reference instead of a [39:52] tutorial. This is really interesting. [39:54] You know, Amazon does [39:57] just related to this. When they ask [39:59] people to build a feature, they have a [40:01] press release. like imagine if you [40:03] announced this. I just love how like [40:05] both this and and what you're saying it [40:07] forces you to just think from a very [40:09] different perspective right from from [40:11] how people will use this feature and [40:13] then and then other sections there's uh [40:15] I think you mentioned uh rationale [40:17] alternatives prior art future [40:19] possibilities [40:21] >> yeah so that you know you get to explain [40:23] so rational and alternatives I think is [40:25] a pretty important section because you [40:27] get to answer all of the questions [40:29] before they get asked and you get to [40:31] explain why did you pick this design and [40:34] then some other design and I think [40:36] that's usually a pretty big part of an [40:38] IFC and then of course it's good to look [40:41] at what did C++ do and what can we do in [40:44] the future as well [40:45] >> and once you have the RFC you send it [40:47] out what happens then [40:48] >> well somehow people you get people to [40:51] look at it there is an RFC's repository [40:54] and you can open a pull request there [40:56] with your markdown document with RFC and [40:58] people can discuss it you might also [41:01] write up your doc somewhere else then we [41:03] call it a prefc if it's not in the IFC [41:06] directory but it's kind of the same [41:08] thing. Let's say that the language team [41:11] like it's a language team IFC and [41:13] they're happy with it. So I said the IFC [41:15] was how the language makes big decisions [41:17] but then they actually use a process [41:20] that comes up for all decisions [41:21] essentially called the final comment [41:24] period. And so the idea is they tell the [41:28] bot to please start the approval process [41:31] and then it will create a comment on [41:34] GitHub with a checkbox for every team [41:37] member. And then team members check [41:40] their own checkbox. And once everybody [41:43] from the team except for at most two [41:46] have checked their checkbox then the [41:49] final comment period will begin which is [41:51] 2 weeks. [41:52] >> Oh. So when it's only two check boxes [41:57] left then two weeks starts. What what's [42:00] the rational for this? This is very [42:01] interesting. It is a historic fact more [42:03] more like [42:04] >> I mean you know let's say that everybody [42:07] checks that box immediately and then the [42:10] two other people didn't get to a chance [42:12] to look yet. So it's to make sure that [42:14] everybody has a chance to see it. [42:15] >> Yes, I understand. And also to keep [42:17] things moving at a sensible pace. So [42:19] there's another part of the process [42:21] which is concerns. Team members can file [42:23] a concern which basically pauses the [42:26] process until it's resolved and then [42:28] once the two weeks pass it's accepted. [42:32] So that's essentially how the team makes [42:34] decision and this is not just IFC's. If [42:37] you have I don't know a pull request [42:39] changing something in the reference then [42:42] the language team might say oh we need [42:43] to make sure that everybody is on board [42:45] with this change. they'll tell the bot [42:47] to start an FCP on this random PR or [42:50] some random issue or what wherever it [42:52] might be. The same process applies [42:55] >> and then once let's say it says lang [42:57] language feature okay the RFC is [42:59] accepted we know what we're going to [43:01] build then the feature is just built you [43:03] start to open your pull requests and get [43:05] into a language pretty much but you you [43:09] put the feature behind a feature flag in [43:13] Rust we have this thing called nightly [43:15] features which basically means that you [43:18] can't use it normally but if you use the [43:21] nightly build of the compiler You can [43:23] once you have your you know your feature [43:26] I mean you might begin but you know once [43:29] you have your accepted RFC you start [43:31] submitting pull requests uh you [43:33] implement your feature it gets merged [43:36] and people start using it experimentally [43:39] >> on a nightly build. Yeah. And then at [43:41] some point you might say okay I think [43:44] this feature is ready and this is kind [43:46] of a recent invention but we have come [43:48] up with this idea of a stabilization [43:49] report in the pull request that change [43:52] that removes the feature flag. We write [43:55] up a little report saying for example [43:58] how it's been used and explaining like [44:00] oh here are the [44:02] dangerous edge cases here are the tests [44:06] for each of the dangerous ed. So that [44:07] kind of stuff and then they use the FCP [44:10] process again to agree to stabilize it [44:13] and then it's merged and so now you have [44:16] a feature without a feature flag. [44:18] >> Yeah. [44:18] >> In the main branch. [44:20] >> Yes. [44:21] >> Between 0 days and 6 weeks from that [44:24] there will be a beta release of the [44:25] compiler and it will be [44:27] >> and it will be in it. [44:28] >> Yeah. It will be in it and then 6 weeks [44:30] later the beta release becomes the next [44:33] stable release. [44:35] >> Okay. So, so like Rust has a strict six [44:37] week release cycle unlike with Linux. [44:40] Well, Linux also has a a rough emo, but [44:43] here you just take the state stable [44:45] bash. You're not doing any special. [44:46] >> Yeah. And so we don't really have a [44:48] concept of beta features that are only [44:50] available a available on beta. [44:52] >> You you have the nightly pretty much [44:53] nightly or people can get on to the [44:56] latest branch which is not yet cut. [44:58] >> Yeah. The main purpose of beta is to [45:01] test like you get six week to test the [45:04] stable release. So hopefully if there's [45:06] any problems we can fix them before it [45:08] goes out into a stable release. [45:09] >> And you mentioned that RFC's are only [45:11] for large decisions that need to be made [45:14] and you've you haven't written that many [45:17] either just because they're large. What [45:18] about smaller decisions that you also [45:20] want to get consensus on? So here there [45:23] are a few different ways to do it. So [45:25] let's say you want to add a new function [45:26] in the standard library or a new type. [45:29] Then the library team actually has this [45:31] thing called an ACP an API change [45:34] proposal [45:35] which is basically just an issue on [45:37] GitHub. So you open your issue, you [45:39] describe your API, describe what the [45:42] interface is and explain why you should [45:43] have it. uh and it's much smaller than [45:47] an RFC would be and then the library [45:48] team can say this is okay with us and [45:51] then you can implement it on unstable or [45:54] nightly and then later you can then [45:56] stabilize it and similarly the compiler [45:58] team has it's kind of what major change [46:01] proposals [46:02] >> you you need you need to say how how [46:04] it's called [46:05] >> MCPs [46:06] >> what is going to confuse a lot of people [46:08] outside of we're not inside of Rust yeah [46:11] it is what it is [46:12] >> which for the small smaller features [46:14] Yeah, even though it's called major, [46:15] right? It's it's big enough that they [46:17] need you to put up an issue, but not big [46:19] enough to need an RFC. And for the [46:22] compiler team, the classic example would [46:24] be a new compiler flag. Now, Rust has [46:28] new new builds every 6 weeks, right? But [46:32] it also has additions. There's one in [46:34] 2015, 2018, 2021, 2024. [46:38] What are additions? So the thing about [46:41] additions that is different from [46:43] versions is that if you're using version [46:46] 1.90 of the compiler, everything is [46:49] using that version. But different crates [46:52] can use different editions. And so I [46:55] might have a crate using the 2025 [46:58] edition of the language and I can keep [47:01] using that forever because Rust has a [47:04] really really high backwards [47:06] compatibility guarantee. So you write [47:09] all of your code and the guarantee is [47:12] that it's going to keep working forever. [47:14] That's the idea anyway. Additions are [47:17] basically the way that Rust makes [47:19] breaking changes without breaking people [47:23] because they might change the syntax of [47:26] the language. For example, async a [47:29] weight was added in addition and so code [47:32] using the old addition can't use async [47:35] await there. You could have a variable [47:36] called async if you want. lead as evil 5 [47:40] and then in the new edition you can't [47:42] but you can still mix and match code [47:44] written in different editions so they [47:45] work together. [47:46] >> Oh interesting. [47:47] >> So I might have a library written in the [47:49] 2021 edition and you can write your [47:52] library in 2024 edition or your binary [47:55] project and then you can still use my [47:58] library. Why do you think Russ decided [48:02] on additions which feels a bit more [48:04] confusing to me as a developer as [48:06] opposed to versions? Like when I look at [48:08] Java's versions or PHP's versions or [48:10] even Ruby on Rails versions, you know, [48:12] there's always a m there's a major [48:14] number. And I might be wrong, but it [48:16] sounds to me that an addition is almost [48:18] an equivalent of a of a major version at [48:22] other languages. Is that putting it [48:24] correctly or am I missing some details [48:25] here? Really the big idea is to say we [48:29] want the old code to continue working [48:31] but we still want to change the [48:32] language. And so the the difference from [48:35] other kinds of versions of languages I [48:38] mean Python 2 version Python 3 comes to [48:41] mind is that you can totally mix and [48:43] match in any way you want. [48:45] >> You are a language team adviser uh or [48:48] you recently became one. What is a [48:50] language team adviser and and what do [48:52] you do as part of this role? We have of [48:54] course the language team which you know [48:56] they meet they have meetings every week [48:59] and they do a lot of stuff and so on and [49:02] so forth. The language team advisor role [49:05] is a way to be part of the language team [49:09] light in some sense. So you're someone [49:12] that they've said, "Okay, we trust this [49:14] person's opinion, [49:16] but you don't necessarily go to every [49:18] single meeting." Like there's no [49:19] checkbox for you on an FCP, though you [49:22] can still file a concern. So yeah, it's [49:25] really a way to participate in or help [49:27] the language team without full [49:30] membership. And full membership might [49:32] entail a lot of things, right? For [49:34] example, for me, it would entail going [49:36] to meetings every Wednesday evening [49:40] instead of like when I would normally [49:42] have dinner. from your observation [49:46] how what is the corporate influence like [49:48] on on Rust in the sense that when I talk [49:50] with with Greg KH he was telling me that [49:52] in practice about 80% of the frequent [49:57] Linux contributors are typically [49:58] employed by a company which sees value [50:01] in um adding their their features or or [50:04] maintaining their features in in Linux [50:06] which which turns out to be like a nice [50:08] kind of I guess symbiosis in some ways [50:11] for for Rust the the people working on [50:13] it? Are they usually paid by their [50:15] employers like you are? I I'm I'm sure [50:17] there's people who are just every now [50:19] and then contributing, but people who [50:20] are spending more time on this. Do you [50:21] see a pattern of corporations actually [50:24] supporting this or is there a foundation [50:26] that also supports people to work on [50:28] this full-time or close to full-time? I [50:30] would say here that the Linux kernel is [50:32] truly unique in this particular aspect [50:35] in that they have thousands of [50:37] contributors [50:39] doing it on work time. I actually think [50:42] that the Rust project is doing pretty [50:45] well at having people do it and get paid [50:48] for it like by their employer, but it's [50:51] nowhere near the to the same extent as [50:53] as the Linux kernel. The Rust project [50:55] also has a few other interesting things. [50:58] So the Rust Foundation have some grants [51:02] that allow [51:04] I mean for example if you're a student [51:05] and you want to work on something you [51:07] might be able to get a a grant some [51:10] money from the Rust Foundation. I think [51:12] that's a super cool [51:14] >> thing that the foundation is doing [51:17] >> especially I think getting people [51:18] involved students involved or or you [51:20] know the people who would find it harder [51:23] or more daunting to to get involved in a [51:25] project like this. Speaking of which, [51:27] for a software engineer who would be [51:29] interested to contribute to the Rust [51:31] ecosystem, what would your suggestion be [51:32] in terms of both resources or or ways to [51:35] get started? I mean, obviously you can [51:38] go to the issue tracker and look for [51:40] issues that interest you. I think that [51:43] often it's I mean, the best way to [51:46] contribute something is if you have [51:48] something you want to change about it. I [51:52] think that's often a pretty good [51:53] starting point. So if you wanted to [51:55] contribute to the Rust language itself, [51:57] Rust does a lot of its stuff on uh [52:00] something called Sulip which is a chat [52:03] server where people talk and you you [52:05] could go there and talk to people. So [52:07] the Rust for Linux project has a pretty [52:10] nice contributing page. [52:12] So, rustforlin.com [52:14] and there's a contributing page there [52:16] with for one some of there are a few [52:19] different um drivers you might be able [52:21] to contribute to and they have links to [52:23] the issue tracker there. Another thing [52:26] that's really cool is you can contribute [52:29] to the Linux kernel without contributing [52:32] to the Linux kernel, right? because you [52:35] might take a Rust language feature we [52:37] need and implement it and now you've [52:41] contributed to the Linux kernel [52:42] indirectly [52:44] or maybe you want to work on the Rust in [52:48] GCC project and help move that forward [52:51] and so I think there are a lot of [52:52] different projects other than the Linux [52:55] kernel that would help Rust in the Linux [52:58] kernel a lot to contribute there. Can we [53:00] talk a little bit about Rust in the [53:02] Linux kernel on on how that has evolved? [53:05] How you got involved in in writing Rust [53:09] in in the Linux kernel? And have you [53:10] seen the approach of of especially Linux [53:13] kernel devs uh change or soften towards [53:16] Rust? Because I I know it was a very [53:18] heated topic earlier on. Linux has this [53:21] conference called Linux plumbers which [53:24] you know as part of my work on rest for [53:27] the Linux kernel I've been going to for [53:29] the past few years and one thing I think [53:31] has been really obvious is every time [53:34] I've gone you can say things have [53:37] totally changed since last year. I've [53:39] experienced this like four times in a [53:41] row. [53:41] >> That's kind of pretty cool. [53:43] >> Yeah. I think there's really a lot of [53:46] stuff that's happening. I mean, one year [53:48] I might go and people think, "Oh, that's [53:50] some nice little thing you have there, [53:52] right?" And then the next year [53:55] now they have Rust code in their [53:56] subsystem. It it kind of keeps going. [53:58] The the the most recent Linux plumbers [54:01] from December 2025 was there. The big [54:05] news were that at the Linux kernel [54:08] maintainer summit, we agreed that Rust [54:12] is no longer experimental in the kernel. [54:14] That was really big for us compared to [54:17] the previous year. [54:18] >> Yeah. So, so now that means that it's [54:21] official like like Rust has the same [54:23] status as C, which is the lang the [54:26] language that the kernel is written in, [54:27] right? [54:28] >> I guess. Well, not the same status, but [54:31] but not not being experimental. It it [54:34] clearly marks that it's more stable. [54:35] Experimental sounds like it's it's not [54:37] as stable. Basically, we've proved this [54:39] is going to work. I mean based on what [54:41] you've laid out with just with memory [54:43] safety and of course being able to use [54:46] unsafe when you need to that already [54:50] like shows a lot of I guess promise plus [54:54] there's there's some regulation as well [54:56] right there's I think the US Department [54:58] of Defense passed some regulations [55:02] saying that they will not allow their [55:04] agencies to use non-memory safe [55:06] languages for the concern of security [55:09] vulnerability. ilities and you know this [55:11] would practically mean that Rust and [55:13] other memory safe languages could be [55:14] used but C, C++ or maybe one day systems [55:18] that are built in this one might see [55:20] larger scrutiny. Yeah, there have been [55:23] different stuff like that from multiple [55:25] different governments, right? [55:27] These governments are saying, "You guys [55:29] are using C or C++ in this project and [55:33] it's causing an unacceptable amount of [55:35] memory safety vulnerabilities that [55:38] simply don't happen if you just don't. [55:40] So what if you didn't do that?" in in [55:44] this conversation, we managed to go for [55:46] a very long time without even mentioning [55:48] AI once, which uh given where the world [55:52] right now is and and how these tools are [55:54] are spreading. That that that's pretty [55:55] impressive. [55:57] I I was interested, do you use any of [56:00] the AI tools for your day-to-day work [56:02] building Tokyo, uh contribute [56:05] contributing to Rust projects? Have you [56:07] found a need for them at all? So, I have [56:10] uh been trying to use them. Honestly, [56:13] I'm still learning how to use these [56:16] tools, but I have used them. I I quite [56:19] like the Gemini command line interface. [56:22] I think it's uh pretty neat. These tools [56:25] are pretty proficient at outputting code [56:28] or, you know, giving a prompt and it it [56:30] putting out code. But in your day-to-day [56:32] work, how how much code do you actually [56:34] type as opposed to reviewing code, [56:38] thinking about what to do, making a [56:40] plan? Does it sound like as we're [56:42] talking about the RFC, for example, the [56:44] RFC process, my sense was most of that [56:46] was thinking about what to build, [56:47] getting a consensus, making sure it's [56:50] right, and it almost sounded like the [56:52] actual code itself would be the I don't [56:55] know, lesser. Of course, you know, [56:56] there's a lot of work involved, but you [56:57] see what I mean. the the actual time [56:59] spent will probably be less than [57:01] everything else around it. [57:02] >> I think it's still an important part of [57:04] the the process. I mean, a lot of people [57:08] talk that about that when you use AI, [57:10] it's really important to write tests and [57:13] that kind of thing because then the AI [57:15] is actually able to tell if it did it [57:17] right. I explained this story from [57:19] before about how I was refactoring [57:21] something. I just told did what the [57:23] compiler told me. I think the same kind [57:26] of principle applies with agents in that [57:30] they can talk to the compiler. It will [57:32] tell them what to fix. So I guess this [57:35] could be a case. We we'll see. But Rust [57:37] could be a pretty promising candidate [57:39] for to use for agents because they can [57:42] get more feedback and it's just hard [57:44] it's harder to to ship certain type of [57:46] bugs or maybe impossible to have certain [57:48] type of bugs. Yeah, I think there is a [57:50] aspect of that [57:51] >> for places like the Linux kernel where I [57:54] mean correctness is extremely important, [57:57] reliability is very important. There's [57:58] already multiple layers of human review [58:01] which which is is in place. Do you see [58:03] potential for AI generated code to prove [58:07] helpful somewhere like actually truly [58:10] helpful like again assuming that these [58:11] things can generate you know as per [58:13] specification or as per what what you [58:15] need or or could could this be a place [58:18] where it might be one of the places [58:20] where we might not need that much [58:22] because it it already feels a kernel to [58:24] me it feels like a place where there's a [58:25] lot of people coming in contributing and [58:27] and there's there's a reason that change [58:30] can propagate slower [58:32] >> when When I was at the Linux kernel [58:34] maintainer summit, one of the topics [58:35] that came up was using AI for code [58:38] review and there were some people there [58:42] who had for example set up bots that [58:44] would say when you send an email to the [58:46] mailing list, it would feed it into an [58:48] AI agent which would leave a review. [58:50] That kind of stuff. And for example, [58:53] Linos and others were talking about how [58:56] these reviews were actually really [58:59] impressive for kernel code. At least [59:02] what's being discussed in the kernel [59:04] community, that kind of use case seems [59:08] like something people are excited about. [59:11] And it sounds like this would not be a [59:13] replacement obviously, but just one more [59:16] way to get feedback, maybe doing it [59:18] quicker and and just an additional [59:20] safety net, if you will, right? I mean, [59:22] that's the thing with memory safety, [59:23] right? You make some sort of trivial [59:26] mistake. It it's not some complex thing. [59:29] It's just you make some trivial mistake [59:32] and there's a bajillion places you could [59:34] make it. So even if even if you're a [59:38] really good programmer and only make [59:39] it.1% of the time or whatever, it's [59:41] still going to happen, right? [59:43] >> And so if the AI can catch a lot of [59:45] those, then you know that's pretty good. [59:47] >> Well, and I guess some creative use [59:49] cases could be for example there tests [59:52] are are a big thing, but AI might be [59:54] able to help figure out if there's edge [59:56] cases missing again if if the language [59:58] itself does not support it. There could [60:00] be what I understand and there's there [60:02] could be a lot of potential to add more [60:03] safety nets that do not exist today. [60:06] >> I think that's right. I like this [60:07] approach. So this is this is one of the [60:09] first conversations I'm having where [60:10] we're talking about AI where we're [60:12] talking about how to increase quality wi [60:14] with AI because in again in startups or [60:17] whoever is building there's a lot of [60:18] talk about how it can make it faster [60:20] faster restoration and there's usually a [60:22] quality trade-off that we usually do not [60:24] talk about but I I love that we're [60:26] actually talking about the things that [60:27] can increase quality or or at least keep [60:30] it at the same level. [60:31] >> I mean I have actually written a few [60:33] patches with AI myself. It worked okay [60:36] some I mean it definitely required my [60:38] review before sending it out to the [60:40] list. really did sometimes. But you [60:43] know, another place I remember using it [60:45] was I had this commit that ma made [60:49] binder faster in some way and one of the [60:52] review comments I had received was, [60:54] "Hey, can you run a benchmark?" I said, [60:56] "Oh my god, now I have to write a [60:58] benchmark." But then I got the AI to [61:00] benchmark it for me. And what it did, [61:02] what it actually went and found an [61:04] existing benchmark and modified it a [61:06] little bit in a quite clever way. and [61:08] then it ran it for me and then it wrote [61:11] a Python script to analyze the text file [61:14] with the numbers and presented it in a [61:16] nice table. [61:17] >> So it sounds like this was toil work [61:18] that you could have done but [61:20] >> yeah of course [61:21] >> you might have not done as good of a [61:22] work because you might have not found [61:24] that utility you might not not figure [61:26] out to do that. [61:27] >> I mean at least in that instance it [61:28] saved me time if nothing else. for a [61:30] senior engineer who would like to learn [61:33] Rust or you know just build with it what [61:35] would your suggestion to be to get [61:37] started of of course for AI might be one [61:39] of the things which makes it a lot [61:41] easier just to to get started but if if [61:43] you would like to learn what do you [61:45] recommend for for people who actually [61:47] want to become proficient at the [61:48] language. So for one, I would say that [61:50] the Rust book which is so it's on the [61:54] official Rust website is actually really [61:56] good, right? And you don't have to it's [61:59] freely available online. Rust has this [62:01] idea of calling tutorials for books for [62:03] some even though they're online which is [62:05] kind of funny. But anyways, I think the [62:07] Rust book is really good. Other than [62:09] that, I think honestly the way you learn [62:12] a language is you have you have a [62:14] project. You you implement some sort of [62:16] project with it. I mean [62:19] maybe some sort of web server or [62:20] something. [62:21] >> And one more thing on AI. So it's easy [62:24] to get started with languages these days [62:26] because you can just prompt the AI to [62:27] like write this or that. In the case of [62:30] Rust, do you think that could create a [62:32] false sense of understanding especially [62:34] we talked about the importance of [62:36] understanding structures of [62:38] understanding compiler issues which are [62:39] there for a reason. You know tools could [62:41] just like generate through this and [62:43] create code that that runs. Yeah, it [62:46] it's totally a danger. I recently tried [62:48] using it for something where I guess I [62:50] was not writing Rust code. I was writing [62:52] make files. I wanted to add some support [62:54] in the Linux kernel build system for for [62:55] some feature and it went into the make [62:59] file and added the Rust flags necessary [63:02] to do it. But then I looked at the code [63:04] and it was it had added the necessary [63:06] build flags but to the C side it was [63:08] passing a few more flags which were not [63:11] required per se but they were there for [63:13] a reason and it had just ignored them. [63:15] Any human looking at this would be like [63:17] why did you add Rust versions of all the [63:20] flags? What is your favorite Rust [63:23] feature if there is one? I'm currently [63:25] working on a new feature which I think [63:28] is really exciting. It's something that [63:30] that we ran into in the Linux kernel [63:33] where we needed in place initialization, [63:36] the ability to construct values while [63:38] knowing where they're being constructed [63:40] so they don't get moved afterwards. I'm [63:43] pretty excited about our work to put [63:45] that into the language, but it's very [63:48] much ongoing. I I think that's pretty [63:51] cool stuff. And as as closing, what are [63:54] what are books you would recommend that [63:56] you've enjoyed and and why? I already [63:59] mentioned the [64:01] the official Rust book. I also think [64:03] that so John Ganget has another book [64:06] that I think is really good and this [64:08] book is kind of aimed at the [64:11] intermediate Rust developer. The the [64:12] Rust developer who has gotten some Rust [64:15] experience but wants to go further. I [64:18] think that's also a pretty good book for [64:20] for that audience. Some other resources [64:22] which are not books but which I think [64:24] are also really good is there's this [64:26] thing called rustlings and the idea is [64:28] that they give you some unfinished rust [64:30] code and your task is to finish it. [64:32] >> Oh, nice. [64:33] >> And I think that's a pretty cool way to [64:35] learn the language as well. [64:37] >> Awesome, Alice. Thank you. Thank you. [64:39] Thank you so much for this. This was [64:42] really interesting and I've learned a [64:44] bunch. [64:44] >> Thank you for having me on. I hope you [64:46] enjoyed getting into the details about [64:48] Russ as much as I did. One thing I [64:50] appreciated talking about is how [64:51] deliberately Rust seems to have been [64:53] designed around the question, what [64:54] mistakes do programmers actually keep [64:56] making and how do we eliminate those [64:58] mistakes. A few examples include memory [65:00] safety, not having a null, and the [65:02] errors being values that you cannot [65:04] ignore. The documentation example is [65:06] also an interesting one. Documentation [65:08] tests or doc tests are automatically run [65:10] as tests. If your example breaks, then [65:12] your build breaks. This is the first [65:14] time I've heard this clever idea [65:15] implemented in a way that's easy to use [65:17] in a language. Finally, the question on [65:19] why Rust is becoming so popular might be [65:22] because it's in a category that did not [65:24] exist before, a language that's reliable [65:26] and also performant at the same time. [65:28] This makes it usable for high [65:29] performance computing cases like kernel [65:31] work while also being a good alternative [65:32] for higher level back-end languages. Do [65:34] check out the show notes for related the [65:36] pragmatic engineer deep dives that go [65:38] even deeper into back-end topics and [65:40] stories of building languages like [65:41] Cotlin and Swift. If you've enjoyed this [65:43] podcast, please do subscribe on your [65:45] favorite podcast platform and on [65:46] YouTube. A special thank you if you also [65:48] leave a rating on the show.  📄 **Full text:** ![[Full Document Contents/Articles/Why Rust Is Different, With Alice Ryhl.md|Why Rust Is Different, With Alice Ryhl by YouTube]] ## Highlights - What would your pitch be on why it's worth checking out Rust or working with Rust? You need a language that's reliable that's going to have as few bugs as possible. That's the idea of Rust. What is the ownership model? >> The idea that if you have a variable containing some object, then the object is only there. So, it's kind of exclusive. We talked about memory safety, but there is a keyword in Rust called unsafe. Generally, when unsafe is used, it's to add a new features to the language. As long as you design your API right, you can add new language features by using unsafe. What are additions? ([View Highlight](https://read.readwise.io/read/01ks5dm4gaby8es7x1a48yba36)) - Note: Ownership model prevents double-free memory errors - Tags: atom/zettel/z1 - server. You need a language that's reliable, that's going to have as few bucks as possible. I mean, obviously, it would be nice if it had zero bucks, but you know, it's going to be hard to get there, but as few bucks as possible. That's the idea of Rust. I mean, I already mentioned null, but it does a lot of stuff like that. So there's no null checking and and this is done through you know it has this enum type which I mean I think Typescript can do something similar. TypeScript is actually kind of good on that front but but okay the ([View Highlight](https://read.readwise.io/read/01ks5dke8vwetrh62fgmh8hz2q)) - Note: Rust eliminates null pointer exceptions through enum types - Tags: atom/literature/h1 - server or something. Another thing I would I quite like is how it handles documentation. How does it for one when you have a comment you make it into a documentation comment by having three slashes instead of two. Now the thing is you can of course write examples in your documentation and Rust makes all examples into tests. This means that if you change the underlying code now your test fails. And so this means that you can't even you ([View Highlight](https://read.readwise.io/read/01ks5dkvvgg13j6za0esad79j5)) - Note: Documentation examples become automated tests in Rust - Tags: atom/literature/h3 - enough, but in C++ when you make a mistake there, now it's actually a security vulnerability most of the time. >> Mhm. If you do something as trivial as you did an off by one in your IRA or whatever it might be, that's a security vulnerability and that this just keeps happening. >> Small mistakes become security vulnerabilities. And in Rust, so Rust is memory safe, right? I mean, we talked a bunch about different ways that Rust is more reliable. And we didn't even touch memory safety. >> Let's talk about memory safety. Memory ([View Highlight](https://read.readwise.io/read/01ks5dkn89gjqqmwrmz7g3vb5h)) - Note: Memory safety bugs in C++ become security vulnerabilities - Tags: atom/literature/h2 - value. the the reference and the borrow checkout checks that the reference is like the last use of the reference is before the object goes out of scope. So if you have say a let's say you have an immutable reference you're reading then if you change the object let's say it's in vector. So I have a mut an immutable reference I'm reading element five and then I change the vector I call clear. Then the borrow checker also ensures ([View Highlight](https://read.readwise.io/read/01ks5dmakag38e8xraerpbfsgb)) - Note: Borrow checker enforces reference lifetime safety - Tags: atom/zettel/z2 - when it comes to the design of the language the teams are really that's really it teams have been pretty good as far as I've seen at delegating So I've seen them sometimes say we think this is a lips API decision and we will go with whatever lips API decides. >> One thing that is interesting to talk about is the RFC process. So there's requests for for process. RFC request for comment is the way the ROS project makes big decisions but you know big ones is ([View Highlight](https://read.readwise.io/read/01ks5dmjztv6kphy3x9tp2sv77)) - Note: RFC process enables consensus-driven language evolution - Tags: atom/zettel/z3