Doors Open & Breakfast

It's all in the delivery

There's a famous saying that goes "It's not what you say, but how you say it" that you'll often hear from someone who is likely about to offer you some constructive criticism on your communication. In this talk, I'll be offering you the same commentary, but on a form of communication that may be totally off of your radar: software distribution, "It's not the software you write, but how you deliver it."

Rust is well-known for its notoriously steep learning curve, but Rust's release and distribution strategies have eliminated whole portions of the "new language" learning process, a boon that we all implicitly enjoy but rarely note or reflect on. In this talk, I'll explore the history of Rust delivery and all the lessons it learned from projects that came before it. We'll talk about the current process and the effect it has on learning materials, the tooling ecosystem, and end-user adoption and provide concrete tips on how you can implement these strategies in your own projects and tools. We'll also explore future growth opportunities for both Rust and the ecosystem and how to get involved in these efforts. By the end of this talk, you'll have a greater appreciation for Rust and its infrastructure, and also have concrete ideas for how you can improve the developer experience of your own projects by focusing, not on your software itself, but on how you deliver it.

Ashley Williams

The road to compiling the standard library with gccrs

gccrs is an alternative compiler implementation of the Rust Programming Language, which aims at adding support for the language to the GNU Compiler Collection, GCC. For now, the project targets Rust version 1.49, and plans to catch up once that milestone is reached.

But what does “targeting a Rust version” mean? Our goal is for gccrs to eventually become an authentic Rust compiler, which passes the rustc testsuite and contains the same behavior, same bugs, and same language guarantees. But passing a testsuite is only half of the story, and the compiler needs to be useful for Rust users. This means compiling user crates and projects, which most often depend on one of the most complex pieces of Rust code available: the Rust standard library.

The standard library provides functions, types and traits that Rust programmers interface with on a daily basis. Think Option, Result, println!(), assert!(), unwrap(), clone()… It is made of multiple crates, of which the most crucial are core and alloc: core contains code usable even in the most restricted embedded contexts, while alloc offers types and abstractions relying on dynamic memory: Vec, Box, String… Some of these abstractions are implemented within the compiler (complex macros such as asm!(), some architecture-specific functions…), but most are written directly in Rust.

They are often made of very complex code, utilizing Rust’s powerful type system and macro expansion to avoid boilerplate and ensure soundness - but this weighs heavily on the compiler, which needs to understand and implement these constructs properly to handle this code!

This talk will dive into some of the work that was necessary for gccrs to understand and compile Rust’s 1.49 standard library: All of the interesting features, horrible hacks and lawless restrictions we have had to put in the compiler: All of the hurdles, horrors and hoops we’ve had to jump through, and all of the ugly code we’ve had to write!

We will focus this talk on the Rust side of things, and take a look at what is necessary for supporting some of the more complex parts of the standard library. We will dive into the rustc 1.49 implementation of the compiler, and compare it to gccrs, highlighting our shortcomings and the evolution of both compilers. You will learn a lot about the language, and discover just how complex the implementation of simple Rust types really is.

Arthur Cohen

Underrated gems of Rust & WebAssembly: Errors, Async, I/O

WebAssembly has revolutionised cross-platform development, enabling developers to compile their code just once, regardless of the runtime operating system or CPU architecture. While Rust boasts the best language support for WebAssembly through the wasm-bindgen tool, developers often encounter unexpected challenges and differences in execution models. Similarly to no_std, not every Rust code can be compiled to Wasm out of the box.

For example, in a Rust library compiled to Wasm, panics cannot be unwinded (and their stacktrace location is lost), and async functions à la tokio cannot be awaited. Moreover, no I/O operation can be performed in WebAssembly: that means no network connections nor file handles can be opened. The WASI specification partially overcomes this limitation, but that’s still unstable and doesn’t cover network sockets.

What if you wanted to write a production async Rust library that needs both robust error handling and I/O, and you needed to run it in JavaScript runtimes like Node.js?

In this talk, we will explore uncharted territories in Wasm land, where you’ll learn how to confidently integrate your familiar Rust patterns with powerful - but fragile - WebAssembly runtimes. As a motivating example, we will present a database query engine prototype written in Rust+Wasm that accepts a JSON query, parses it into an equivalent SQL query, runs such query asynchronously and returns the results to the caller.

Just like pirates in a sea of compilation errors, we will bend the rules to conquer new horizons in the realm of truly cross-platform Rust libraries!

Alberto Schiabel 🦀

Lunch

Reasoning about Rust: an introduction to Rustdoc's JSON format

Macros are the primary mechanism for metaprogramming in Rust, either to perform code generation or enforce constraints at compile-time that are not easily captured by the type system (e.g. sqlx).

Macros are also limited: their input is a stream of tokens, with no type-level information.

Up until last year, you had to hook directly into the compiler internals to get a more featureful representation. This is no longer the case, thanks to Rustdoc's JSON format: an information-rich representation of your Rust API in a machine-parsable format (with a versioned schema!).

We will introduce the feature, look at the structure of the data and cover a few of the usecases where it shines. You will leave the talk with a basic understanding of the format and ideas on how you could leverage it to build tools that enhance your own Rust workflows.

Luca Palmieri

World in Vectors - Map rendering using WebGPU and WASM

Digital maps are ubiquitous tools in our everyday life. In the early 90s the idea of browsing the whole world and visiting any place was breathtaking. The first solution to this problem is called “TerraVision” and was groundbreaking. Today the idea of exploring your surroundings using digital maps has become normal.

What is the talk about?

But how do these maps work? In this talk I want to provide an overview of the foundations of digital mapping solutions. Differences between maps which use vector data and rasterized satellite imaginary will be outlined. These discussions will be accompanied by discussions about the Rust ecosystem and how it enables cross-platform rendering of geographic data on the GPU. A new and open-source map renderer will be presented, which is created using Rust and modern web technologies like WebAssembly and WebGPU.

I want to dive into the technical details of the WebGPU specification and how it was implemented by the known wgpu project. I will also present the state of GPU support in Rust in general.

Furthermore, I want to prove a good understanding of the WASM technology and why it is so interesting in the context of Rust and computer graphics.

How did this project came into existence?

Last year I had a lot of spare time and decided to kickstart a project which combines different areas of interest: Rust, 3D Rendering, Maps. The result is a cross-platform map renderer, nowadays officially supported by the MapLibre organization. The project showed me the complexity of mapping solutions. It takes a lot of steps until edits from OpenStreetMap contributors are finally rendered in consumer applications. With this task I want to take listeners on a journey from drawing changes in the OpenStreetMap editor all the way until vectors are uploaded to from memory to GPUs.

Max Ammann

Wrangling memory leaks where you thought they could never happen

You’ve just launched your Rust app and everything seems perfect, until you notice your application’s memory usage skyrocketing. With Rust’s scoping rules and GC-less memory model, memory leaks seem impossible. So what’s going on? The OOM killer is lurking around the corner, and it’s time to take action.

While Rust’s powerful safety features and RAII enforcement mitigate common memory leak sources found in other languages, memory allocation challenges can still arise from subtle interactions between programming patterns and an underlying memory allocator. Join us in uncovering patterns that can lead to heap fragmentation and memory leaks, and idiomatic techniques for mitigating these issues in your Rust applications. We’ll learn to evaluate different memory allocators and learn how to harness powerful profiling tools to understand and optimize your Rust apps, from simple command-line tools to high-performance async web servers.

Ayaz Hafiz

Snack Break

The Neotron Saga - throwing your project in the bin and starting again

Back in 2019 I had an fun embedded project, and it worked quite well. I even got a couple of talks out of it. But it was built as a series of tech demos, one feature piled on top of another. There were no sound software engineering principles behind it. And so I thought, now is the time to start over and Do It Right this time.

Jump forward four years, two job changes, one global pandemic and one new CPU, and here we are. I now have a one dead project and one gargantuan monster of a project I can never realistically complete or even keep control of. And the latter still isn’t as fully featured as the former even after so much effort. But it’s probably… better?

Here is a a tale of caution should you ever be tempted to do a “big bang” reboot. But it also has some discussion on Rust FFI, a bit of electronics design, some computer history and maybe a neat Embedded Rust demo.

This talk is laid out chronologically, starting an outline of my previous project with its conference runs in 2018/2019. I talk about the new project, and why I felt the need to start from scratch. I talk about its inspiration, looking at milestones in computer history. I talk about the big changes during the project (the RP2040 microcontroller came out, we had a pandemic, I changed jobs twice, I got some grant money, Twitter did the whole waves hands) and talk about where the new project is at right now. There are no hard and fast answers to “Should I start again on my project?” but we’ll hopefully finish with some neat demos of Rust running on embedded hardware paid for by the Rust Foundation.

Jonathan Pallant

Rust at Sentry: 7 Years Later

After 7 years of Rust at Sentry it's time to revisit our decisions. What would we do different? What worked well? How do you onboard engineers into a language that is not known for being easy to get started? How do you end up more productive? This talk also incorporates experience with some of the libraries and ecosystems we use.

Armin Ronacher

Communities, Organisations, Relationships, Conflict and Hope

The Rust environment has seen a lot of growth in all areas. It lead to visible friction and public conflict that may be hard to understand for people, particularly those that are new to Rust.

That begs a number of questions: Is this normal? Is this special to Rust? Just growth pain? Or something deeper? And whatever the answers are - to which level should individual community members care?

This talk sums up many discussions of worry and hope I had over the last months. It acts a both a summary of the past, but above all make you more competent for the conversations about the future of Rust that are ahead of us.

Florian Gilcher

Closing Party