Knock, knock. Race condition! Who's there? — A Refactoring Story by Stefan Baumgartner.
Concurrency in Rust can be hard, especially when the language throws other obstacles in your way. Like with this request that found me one day. What started as a humble ask to remove some indentation and nesting turned into a crime scene of concurrency gone wrong. Innocent memory being shared across tasks. A supervision task that made everything worse. A race condition waiting to strike. In this talk, we wil
Player unavailable or embedding blocked? Use the YouTube link above.
Stefan Baumgartner -- We refactor a Rust program that has just left the prototyping stage into code that is a delight to read and follow, easy to use, easy to maintain, and that plays along nicely with the ecosystem, all by learning Rust-specific refactoring techniques.
Most people don't see the work that goes into maintaining open source software. It's not just about writing code — it's also about reviewing PRs, helping new contributors, answering questions, fixing bugs, and writing documentation. In this talk, you will hear stories that explore the invisible work of open source software maintenance and discuss the challenges and rewards of this important work.
Reasoning through concurrent systems has always been a challenging task. Poor code can be riddled with race conditions, non-terminating cases and other complex concurrency bugs; and even well-written code can be hard to understand. Async programming is an innovative concurrent programming model that rises to this challenge. In this talk, we'll explore reasoning with async Rust. We'll be introduced to its fundamental building blocks, such as `async`, `await`, `join` and `Pin`, and learn how to predict the behavior of code written with them. We'll build on these to simplify more complex concurrency puzzlers. Finally, we'll explore other models of concurrent programming to see how async Rust compares.
What's the deal with unsafe? The word alone seems to scare the living hell out of every Rust developer, at the same time it's heavily misunderstood even by the best of us. No more trust issues. Let's analyze what unsafe is (surprisingly little), and what harm you can cause by using it (less than you think but still enough to wreak havoc). In the end, we will see if we have practical use for unsafe in our own, real-world software, or if we should consider everything not safe for work. LEVEL: Advanced