We saw a wide range of talks, from Rust success stories to language improvement projects, to team dynamics / Rust org growing pains. I didn’t (couldn’t) attend all talks so I may have missed some really interesting stuff. This is just what I took away from what I went to.

Some highlights:

  • A data-driven approach to teaching Rust: The presenters added quizzes to the Rust Book, then gathered over a million responses and scored the book according to how well the quiz-takers did on each section. They then edited sections on topics showing most learning difficulty and made their edited version of the book available while continuing to quiz readers. They identified improvements in learning based on their changes between 8% to 50% better on specific topics, compared to readers who read the original book.
  • Learning Rust through playing Battlesnake, as a Ruby dev: The presenter took us through their first attempt that worked, through multiple iterations of optimization built on learning Rust concepts and tools, like profilers. They addressed some common experiences of Rust learners as they try to balance compute vs. memory efficiency and copy-by-value vs borrowing depending on design. The final version of their Battlesnake player got into the top ten. A fun talk that inspired me to think about how to build and profile a chess engine with Rust.
  • Rust in the genomics field: Using Rust in genomics / bio-informatics has proved very valuable for getting fast sequencing results. Python (Bio-Python) is particularly ill-suited to high performance and correctness on large data jobs but it’s what researchers know. Rust is changing rapidly but so is the bio-informatics field and it’s not so hard to introduce new tech when it proves so useful. The presenter hadn’t known Rust before but found it worth learning. They saw something like an eight-fold speed-up on their particular problem.
  • Rust saves electricity: A research project to detect subatomic particles needed to float in a balloon over Antarctica. The onboard software needed to not only gather data but run some transformations and filtering on the data. The solar array wouldn’t produce much power – the solar array can’t get much even in summer. The presenter profiled multiple languages with similar workloads to measure the power efficiency of each. Most would not conserve power well enough to be usable at all. Even Go took six times as much power as the Rust program. Additional to the power advantage the presenter found Rust to improve on the reliability of the software a lot. The experiment is set to fly in two years.
  • Multi-platform accessibility Improvements: The AccessKit (built in Rust) project aims to provide a bridge between UI library code and platform accessibility APIs. This way there is a common accessibility library GUI developers can include. AccessKit knows the details of Windows, Mac and Linux accessibility APIs, the GUI devs don’t need to. The “eGUI” library already has support for AccessKit. There are bindings for other languages too (eGUI is in Rust as well.) The speaker showed a Unity app that was accessible thanks to AccessKit and the C# bindings. The “push” vs “pull” model AccessKit takes was interesting – normally a screen reader will “pull” on an app to get information on its state; if the main app thread is busy or worse, hung, the screen reader won’t read anything and could get stuck waiting. Instead AccessKit would push info from the app to the accessibility layer so if the app gets stuck, the user can still review whatever was last sent and at the very least won’t have a stuck or sluggish screen reader. I look forward to building an app with eGUI and AccessKit.
  • Rust success creating an industrial control system at a recycling start-up: A team was tasked with writing a control system for an automated, robotic recycling center. They couldn’t use any existing software – this was to be a next-gen level of automation. The presenter considered C++ and Python. He knew from long experience C++ was a non-starter on a six months schedule. It couldn’t be finished anywhere close to the deadline. Their Python prototype couldn’t perform well on small test systems. Scaling would require a lot of concurrency which isn’t Python’s strength. They gambled on Rust and somehow with a small team and no previous Rust experience, managed to build a highly concurrent control system in under six months, which runs well. The speaker was very enthusiastic. They built this plant during the pandemic with broken supply chains. The servers they ordered arrived nine months after the six-month deadline for going live. They bought consumer gaming PCs from a retailer instead which went fine.
  • Effects system generics are coming: This is the keywords generics initiative. Programmers can be generics on types but not other things specified by keywords like ‘async’ or ‘const’. Currently with no way to generalize function types between async and sync, you end up duplicating a lot of implementations. There’s a set of async std lib functions for instance. Even worse the combinations of async and sync function arguments, function types and return types quickly gets out of hand. The initiative will also benefit other effects that cause messy duplication. Effects generics will make it possible for library authors to support both blocking and async use of their code. Currently the best approach to keeping async and blocking versions of an API in sync would be to use the “maybe_async” macro. It auto-generates two versions of functions. But there is a better way coming in 2024.
  • Rust’s ABI isn’t stable at all: If you wanted to make dynamically linkable libraries (for a plugin system perhaps) with Rust you’d run into a problem. The ABI changes often, so your libraries would soon stop loading. Another challenge is how to represent Rust sum types (enums) in a compact way. The “Stabby” library provides a stable and compact ABI for Rust. Even better than dynamic libraries for plugin services are IPC (inter-process communication) when possible. The services are independent so won’t bring down the whole system if one fails. And for scaling some can be converted to RPC connected services.
  • Fast Search at Github, replacing parts of the Ruby Rails app: They implemented a new code search engine in Rust but needed to connect it to existing Go services. They were able to use FFI and RPC approaches to do this. I don’t recall the details of how this was done. It’s interesting that this wasn’t the only team I heard about combining Rust and Go services. A good presentation.
  • Const is powerful: You can do const functions and expressions, but more than that you can make const type aliases. That was something I somehow didn’t know and could come in handy.
  • Rust development and distribution infrastructure: Rust is distributed for many platforms all of which need their own CI infrastructure. The cleanest way to ensure builds run and only fail for interesting reasons doesn’t easily scale with the number of users downloading the tools and the number of platforms. The CI has to build (if I recall correctly) 55 different builds in parallel. This isn’t the most efficient at scale but is the easiest way to ensure each platform build is reproducible. The number of Rust downloads is growing (actually, technically) exponentially at present. So though Github.com currently covers the cost of Rust project work that may not be sustainable, and if not the cost may suddenly become significant.
  • A tour of Asynchronous Message Passing (in Three Acts): A light hearted talk showing how an async streaming data, message passing and queuing system may function.
  • Keynote: A talk on difficulties in scaling open organizations: “Transparency” as a blanket solution doesn’t work / is insufficient / can be harmful to productivity. A pattern she has observed starts with a small group on a mission building software plus an org. With success many people are attracted but the original culture gets watered down and the new environment can get unpleasant. Maybe it’s just from a few bad actors or maybe because bad patterns from society get recapitulated unintentionally. In any case, the original contributors move out of sight to keep working in peace, or scatter altogether. An example was a company where small teams used whiteboards to communicate on their ongoing work and it was going great. Then the CEO heard and did a “white board” tour. Afterward the whiteboards drew a lot more scrutiny and couldn’t be used in the same way. The teams started “whiteboard planning” meetings to decide what could go on those whiteboards. Obviously there’s a lot to say on this subject. Some take-aways: This is just a natural growing pain; Teams of four to eight are most productive (partly due to the “transparency” effect on larger teams); Organizational collapse / tragedy of the commons isn’t inevitable; Preventing collapse requires intentional boundaries and grouping to balance welcoming newcomers while preserving structure.