In this talk, we will share the insights we gained while building Myrmic, our open-source Rust middleware for distributed systems, with a particular focus on our microcontroller firmware that enables running WebAssembly on resource-constrained targets such as Nordic and ESP devices. Our entire stack is Rust-based—from Embassy firmware and the embedded HAL to the Wasm toolchain and the runtimes themselves. We will outline the requirements that running Wasm in no_std environments imposes on runtimes, particularly in the context of distributed systems with constrained devices. We will then share our experience with Rust-native runtimes such as wasmtime, wasmi, and tinywasm and with embedding WAMR into Rust firmware, focusing on how each runtime aligned with these requirements and the modifications or integration work needed to support our use case. We will also discuss how we structure and compile our Wasm modules, and the trade-offs we make between developer ergonomics, code portability, and the memory footprint of the resulting binaries. The goal of this talk is to provide practical lessons for Rust developers, highlight gaps in today’s embedded-Wasm tooling, and point out opportunities for new open-source contributions.
Links to relevant projets: - wasmtime (https://github.com/bytecodealliance/wasmtime) - wamr (https://github.com/bytecodealliance/wasm-micro-runtime) - wasmi (https://github.com/wasmi-labs/wasmi) - tinywasm (https://github.com/explodingcamera/tinywasm) - A link to Myrmic is not yet available since it will be open-sourced early 2026
With the Rust embedded-hal v1.0 now released almost two years ago, Rust is really ready for bare metal embedded deployments. This talk will look at cheap RISC-V MCUs like the CH32V003 featuring (RPi Pico or Teensy style for less than EUR 1.30) and show you hands-on how you may develop your embedded system using bare metal Rust. From zero to main, using probe-rs for flashing and debugging, IDE integration thereof and some tricks like successfully using no-std for the tiniest footprint possible.
Tired of the endless “search, copy, paste, test” routine, last year’s FOSDEM helped me break out of that loop thanks to two unexpected sparks: Rust and retrogaming. In this talk, I’ll share how discovering Rust and the Game Boy homebrew scene rekindled my passion for creating software bare metal, bringing back the artistic and playful side of programming. We’ll explore the current state of the Rust ecosystem for GB, GBC, and GBA development — from compilers and minimalist engines to demo ROMs and the ongoing work bridging these two worlds.
Links https://github.com/ffex/rust-boy
Godot 4’s built-in async support for GDScript has long been a powerful feature - but what about Rust? In February 2025, I implemented async support for Godot’s Rust bindings (godot-rust), enabling Rust developers to write async code without introducing external runtimes.
In this talk, I’ll walk you through the architecture: how we adapted Godot’s async execution (already designed for GDScript) to work with Rust’s Future and async abstractions, and how we minimized cost by reusing the engine’s existing event loop and task scheduler. We’ll dive into the implementation details - including how Godot-specific futures are constructed, polled, and scheduled - and discuss the challenges we faced when implementing async while interacting with the engine's C++ code over FFI on potentially multiple threads.
This talk will be especially valuable for developers interested in embedding async logic godot and other game engines or understanding how async can be made “engine-native” rather than externally bolted on.
The Common Expression Language (CEL) is an expression language that’s fast, portable, and safe to execute in performance-critical applications. The CEL crate provides a parser and interpreter for the language that emerged from Google, but never provided an implementation for Rust. Given its traits, CEL is the perfect match for any Rust project that requires some sort of expression evaluation. We'll cover why that is the case and where these needs emerged from, then dive into the state of the Rust port of the interpreter, covering some of the challenges met along the way, like reviving the Rust runtime for antlr4.
Roto is a statically-typed and compiled scripting language for Rust applications that integrates very tightly with Rust. To achieve that integration, it needs to interface directly with Rust types and functions. Implementing that boundary turned out to be quite tricky! We had many obstacles to overcome, such as Rust providing very few mechanisms for reflection and not providing a stable ABI by default. This talk will explain how Rust-Roto boundary works and the tricks we have to pull along the way. You can expect lots of unsafe code, deep dives into the Rust Reference and coercions from slices to function pointers.
Full rewrite from C++ to Rust or gradual integration with Rust libraries? For a large C++ codebase, only the latter works, but even then, there are many complications and rough edges. In my presentation, I will describe our experience integrating Rust and C++ code and some weird and unusual problems we had to overcome.
This talk introduces Parca, a general-purpose CPU, GPU and memory profiler for Linux. The main unique feature of Parca is the fact that unwinding happens in an eBPF program, and so is low-overhead enough to be constantly running in production: it doesn't require building with frame pointers or copying large sections of the stack between memory spaces. The primary mode of visualization in the Parca UI is the flame graph.
Rust-specific features in Parca include:
(1) For those projects that use jemalloc, memory profiling via rust-jemalloc-pprof (2) "Custom labels" feature for associating arbitrary application-relevant tags with stack traces (for example: allowing the user to filter profiles by trace ID or any other value they choose to instrument).
Python dominates web development, but they often comes with performance and
scaling issues. Recently, the Python ecosystem has seen massive performance gains
from projects written in Rust, such as uv and ruff. But what other projects
are out there to help Python scale thanks to Rust? At Cloudsmith, we achieved 2x
throughput on our 8-year-old Django monolith by integrating Rust-based tools and
contributed features back upstream
We'll look at a number of projects that helped us start bringing Rust into our stack. We'll go over our methodology: establishing performance baselines through load testing, identifying bottlenecks, and scaling issues. We integrated existing Rust-based tools with minimal code changes and tuned application server configuration for maximum throughput, consolidating infrastructure and reducing operational complexity.
We'll also share our experience contributing observability features upstream to Granian, ensuring production-ready monitoring that benefits the entire community.
You'll leave with actionable strategies for modernising legacy services using existing Rust tools, understanding when this approach makes sense, and maintaining production reliability throughout the transition.
Projects we used:
Ty is a fast Python type checker and language server. Ty is built with Rust, and there are a lot of interesting technical challenges involved in making it a useful tool.
Building a Python type checker is a hard task; however, the design of Ty provides a joyful developer experience for contributors. In this talk, we will look at how the Ty codebase is structured to make development simple, and what design choices make it pleasant to work on.
We will cover: - How Ty goes from a Python program to a diagnostic, and what parts are most important if you want to contribute. - Data layout and ownership model of structs in Rust. - Salsa solves challenge of incremental type checking across many files. - Tooling for tests, snapshot testing during development and type checking open source projects in CI.
From its timid introduction to the Mercurial Version Control System back in 2017 to its more than 50k lines of code today, Rust has enabled a wide range of improvements, some of which we wager would have been impossible if not for Rust.
This talk shows how we reach far beyond the obvious point of "Rust runs faster than Python". It discusses aspects like maintainability, dependency management, API re-designs, opportunities for more advanced algorithms, on disk data-structures, safe parallelism, etc.
We present our rare perspective of working on a 20 year-old codebase with half-a-million lines of Python code, in a software niche with quite extreme goals. Mercurial aims to provide instant-feeling commands with short lived processes for a local database of tens of millions of revisions for millions of files with fully distributed replication.
Git's internal design is both elegant and notoriously complex. Building reliable tooling on top of it means dealing with purpose-built data structures, performance trade-offs, and years of historical quirks.
In this talk, we’ll explore how Rust, together with Gitoxide[0], makes it possible to create fast, correct, and ergonomic version-control tooling. We’ll look at how Rust’s ownership model and type system help avoid whole classes of errors, and how Gitoxide exposes a safe and composable interface to the raw Git data structures.
Using some real-world examples, we’ll walk through: - How Git stores its data and why interacting with it is non-trivial - How the Gitoxide APIs to make this tractable - Patterns for building high-level Git workflows - A short demo of how these pieces come together in the GitButler CLI
Attendees will come away with a deeper understanding of Git’s inner workings, practical insights into using Gitoxide, and perhaps ideas for creating next-gen developer tooling using Rust.
[0] https://github.com/GitoxideLabs/gitoxide
Ubuntu’s plan to “carefully but purposefully oxidise” the distro has given us the perfect playground to see what really happens when you swap decades-old GNU coreutils for their shiny Rust equivalents. Spoiler: everything relies on way more weird flags than you think — and significantly more than the internet’s finest armchair kernel engineers believe.
In this talk, I’ll share the fun, the sharp edges, and the truly unexpected lessons from bringing Rust Coreutils (https://github.com/uutils/coreutils ) into Ubuntu: which obscure behaviours scripts secretly depend on, how packaging Essential tools can turn one missing corner-case into a boot failure, what benchmarks actually taught us (as opposed to what Reddit said they would), and how tools like oxidizr (https://github.com/jnsgruk/oxidizr ) let us safely flip between GNU and Rust without breaking the universe.
Along the way, we’ll look at some of the best online troll predictions — the “Rust will destroy Linux”, “this is rewriting for the sake of CVs”, and “it will be 100× slower forever” genre — and compare them with what happened in the real world. Some were wrong, some were surprisingly insightful, and some were… educational, in their own way.
If you’re curious about modernizing the Linux system, if you enjoy data-driven myth-busting, or if you simply want field notes from the frontier of “C → Rust” rewrites, this session is for you. Links:
Ubuntu “oxidising” initiative: https://discourse.ubuntu.com/t/carefully-but-purposefully-oxidising-ubuntu/56995
uutils/coreutils: https://github.com/uutils/coreutils
Modern networking software often forces developers to choose between rigid, off-the-shelf frameworks and the painstaking effort of building everything from scratch. Rama takes a different path. It’s a modular Rust framework that lets you move and transform packets across the network stack, without giving up control, safety, or composability.
In this talk, I’ll explore together with the audience how Rama’s philosophy of layers, services, and extensions turns network programming into a flexible and enjoyable experience. You’ll see how its building blocks span multiple layers of abstraction. From transport and TLS up to HTTP, and a lot more in between. All while you can still easily plug in your own logic or replace existing components. It also shows how you can build network stacks that aren't possible anywhere else, and all without a sweat. For example socks5 over TLS. Why not.
Through practical examples, we’ll look at how Rama empowers developers to build everything from proxies and servers to custom network tools, while still benefiting from Rust’s performance and safety guarantees. Whether you’re curious about programmable networking, Rust’s async ecosystem, or just want to build things your own way, this talk will show you how Rama helps you do it, all with elegance and confidence.
More information about rama itself can be found at https://ramaproxy.org/, which is developed and maintained by https://plabayo.tech/, a FOSS, consulting and commercial technology (small family) company from Ghent.
https://github.com/plabayo/rama
Deterministic simulation testing (DST) is a method that explores as many random execution paths of a system as possible, injects random failures, and lets developers reproduce the exact same execution path on failure given an initial random seed. This testing approach shakes out many difficult to find bugs before they reach production and greatly increases developer confidence in system correctness when making new changes.
DST was first popularized by the FoundationDB team, and is slowly finding its way into the testing arsenal of many products like TigerBeetle, Resonate, and more recently, Turso’s rewrite of SQLLite in Rust. This talk will cover how we implemented DST of our distributed storage system at Polar Signals by modelling our core components as state machines and why this was the right choice for us over other approaches that use deterministic async runtimes (e.g. https://github.com/madsim-rs/madsim).
Come learn more about DST and how it can help you write better and more resilient software!
Syd (sydbox-3) is an application kernel written in Rust. This talk is a tour of its runtime architecture and the Rust that makes it portable. We’ll walk through the threads and their roles: syd_main (startup, namespaces, policy load, lock), syd_mon (lifecycle, seccomp-notify plumbing), a CPU-sized pool of syd_emu workers (syscall brokering), syd_ipc (UNIX-socket control when lock:ipc is enabled), syd_int (timers/alarms), and syd_aes (AF_ALG crypto for Crypt sandboxing, plus helpers syd-pty and syd-tor. Implementation highlights: minimal unsafe at the syscall edge; per-thread isolation with unshare(CLONE_FS|CLONE_FILES) and per-thread seccomp(2); syscall-argument cookies; forced O_CLOEXEC and randomized FDs; deterministic "last-match-wins" policy; and mseal(2) sealing on lock:on. Portability is first-class: one codebase for Linux ≥ 5.19 with proper multi-arch support (x86-64/x86/x32, arm64/armv7, ppc64{b,l}e, riscv64, s390x, loongarch64), ILP32/LP64 awareness, and MSRV 1.83+. You’ll leave with concrete patterns for building a thread-isolated, multi-arch syscall broker in Rust.