"Are we desktop yet?" by Victoria Brekenfeld

This talk was by an engineer working at System 76. I bought my first System 76 laptop in 2021, the reason being that I wanted to use a different OS than Mac and Windows. This year however, I went back to Apple and bought a Macbook air. But only because I miss a top quality hardware experience for example the track pad 😒. I already gave this unsolicited feedback to the speaker of this talk. System 76 focusses more on the Software side of things as I am assuming it might be difficult to compete with a company like Apple in terms of hardware design.

So the speaker has been working on Cosmic OS, a Rust desktop environment. Cosmic is a desktop environment for Linux, it has a tiling system, it is open-source and is cross-platform. What I took away from her talk is that 3 years ago, the Rust landscape for building GUI was less mature than today. At the time, there were native Rust toolkits like EGUI, Slint and Iced, at Cosmic they decided to go with Iced rather relying on GUI wrappers like (GTK, Qt, Flutter, etc). The main reason being that making use of wrappers did not match the fast-paced development of Cosmic as PRs were taking a long time to get merged.

They used Iced because it was highly modular, it is a reactive toolkit, it is async-first, completely Rust-native and is cross-platform. This however resulted in some challenges like the fact that Rust is not widely used yet and so there was limited number of widgets. They therefore had to create things like libcosmic and cosmic-text for text rendering.

"Exemplery by design" by Jacob Pratt

I accidentally missed the begining of this talk even though I was looking forward to it.

The speaker is an experienced crate developer that gave valuable insights on best practices for writing idiomatic Rust code. His talk was divided into sections and here is what I took away from each.

Style and design

• use #[cfg_attr] or the cfg_select! macro to make Rust portable and configurable
• if you have multiple crates => use workspaces (they allow faster compilation and you can view a crate graph)
• use rust-analyzer with your editor
• set up VSCode-specific configuration for Rust files
• use clippy for linting
• use enum within struct (he regrets not using this more often)
• use the #[non_exhaustive] attribute which indicates that more fields may be added in the future
• use a builder method/builder pattern. He mentioned that there is a new feature atm in the nightly version of Rust that allows setting default values to fields in a struct
• learn the difference between operations like +, format!, push_str and println! for string types

Error handling

• use the thiserror library for error handeling
• implement From for error conversions with ?

Testing

• integration tests usually sit in a separate folder than the code you are testing (unlike unit tests)
• use the quickcheck crate for property testing
• catch undefined behaviour using the miri crate
• implement code coverage using cargo-llvm-cov

Maintenance

• to keep dependencies up-to-date you can use cargo update and upgrade, but know that upgrade might include breaking changes
• Rust has rich documentation, make use of it
• make use of changelogs
• in your CI pipeline, make use of clippy and rust-format

Licencing

• check out those 2 crates: cargo-deny and cargo-semver-checks for semantic versioning
• for benchmarking and performace use the criterion and flamegraph crates

"From any to thiserror" by Leo Kettmeir

In this talk, the speaker shared some wisdom from his time working at Deno. Initially the code base he was working on was full of handwritten errors using a catchall style. That however was not practical and needed improvement. He then rewrote everything within half a year to use a more concrete error type with the thiserror crate.

"Rust meets Solana" workshop led by Jonas Hahn

It is always nice to see a Solana booth at Rust conferences. There was one at RustConf 2024 in Montréal and there was one this year at EuroRust 2025. Interestingly, there was also a fish at the Solana booth this year.

The workshop lead mentioned some notable projects running on blockchain technology such as:

• Helium (telecom)
• Roam (telecom)
• NET (telecom)
• Hivemapper (maps)
• Geodnet (precise positoning)

During the workshop, we had to send a transaction to the Solana dev cluster to get the fish that was there to say something. This was hacked together by the workshop lead using a Raspberry pi and this GitHub repo.

"Humans in the Rust ecosystem" by Rohit Dandamudi

In this talk, the speaker went through analysis he had done on the Rust's corhort of contributors worldwide. He scraped Git commit history from 2022 to 2023 from the Rust, Rust Analyzer and Cargo Git repositories targeting commit authors and PR reviewers. He then removed and filtered out any noise such as bots and extracted locations from GitHub profiles. The speaker mentioned that this was less than ideal as location does not represent nationality. He then built a social graph from this data about the community structure and patterns.

Some results included:

• The Rust project is mostly being built in USA, Germany, France and UK
• Cargo is being built in USA and Taiwan
• The Rust analyzer is being built in Germany, Romani and Iran

He also mentioned that men are disproportionately building all 3 projects and that the most influential group of contributors belong to mostly 1 ethnicity and gender.

These findings are not surprising. Whilst I was at EuroRust this year, I think I saw 2 other women amongst over a 100 men. There was also a number of speakers from the trans community and they are part of the core team for the Rust compiler.

The Rust community is heavily skewed towards 1 demography but this is not only the case for Rust, it is also the case for the software development domain as a whole.

"Data engineering with Rust" by Michele Vigilante

This talk was quite interesting because it challenges the dominance of languages like Python in the data analysis field. The speaker gave an example of a marketplace app that handles high volumes of users. The goal is to analyse the users' activity to gain insights. The talk goes through a possible tech stack using non-traditional tools for building a complex multistage data pipeline that is robust and performant.

The first twist is avoiding the use of databases to store data and to use Kafka instead. With this, overhead and latency introduced by database write operations can be avoided. In Rust's ecosystem, the rdkafka (a production-grade Kafka client) and axum (a web framework) crates can be used to capture events and push them to Kafka.

How do we store OLAP (Online Analytical Processing) data for later processing?

For this, the speaker suggested using Apache Parquet (Columnar) - a superior choice to CSV files. But why not a database? Well because this setup allows better portability and less cost than a typical Postgres RDS approach.

The data however needs to be loaded onto RAM to be processed. This is were Apache Arrow can be used together with the Apache Query engine to query this data. Other possible query engines include Polars, DuckDB and DuckLake.

But Parquet files are immutable and introduce some inefficiencies. Here you can make use of Lakehouse Table Formats which add a metadata layer on top of the Parquet files. Tool suggestions here include, Iceberg, Delta Lake and Ducklake. In this way, you can have a bunch of Parquet files in an S3 bucket which you can reach using the delta-rs crate which implements the Delta Lake protocol.

Once the data is ready, you can query it using the anaytical service you build. The analytical service itself can be a single binary file that lives on a Lambda function.

Finally the speaker closed with the following tips and tricks:

• think about partitioning from the start (finite datasets)
• use event-based triggers instead of scheduling
• batch processing is easier than streaming
• parallelise your IO as much as possible (load data first then process)
• split your pipelines up (check the Medallion architecture)

Panel discussion: "Rust adoption and safety critical systems"

The panel discussed complex code in the automotive industry and its ever-growing need. They mention the need for a powerful and performant language such as Rust. Rust has a more modern ecosystem when compared to the C languages.

The current landscape in automotive companies is in the form of a hybrid system which includes legacy C/C++ code along with more recent Rust code. A complete rewrite of the legacy code is not the goal and is not something that is achievable.

The panel emphasised Rust's Safety-Critical Consortium and the value it brings to promoting Rust in safety-critical systems and industries. One panelist mentioned that although open-source code is being used in the car-maker industry, the responsibility of clean-running code lies on the car-makers themselves not the open-source community. That is why more developers are being employed inhouse.

How do you then convince upper management at a company to use Rust?

You can start by mentioning that it is an efficient language that is memory-safe. Although it might entail upfront costs at the beginning, the long-term value is worth this cost. Moreover, traditional industries like the automotive industry must consider young talent and ways to attract them via making use of newer technologies like Rust.
A panelist mentioned that from experience, he was failing to convince the C-level at his company to adopt Rust until he adjusted and tweaked his lingo with them because addressing C-level is an art.

The future of Rust looks promising, it will not likely replace C languages in the next 10 years but will definitely be out there with them. That is because it is a sort of language that can be used from bare metal to tools to cloud.

Finally, a framework or guide on steps for adopting Rust or some sort of training path can prove to be highly valuable for the push to make Rust more widely used.

"Profiling Rust in action" workshop by Polar Signals

This workshop works best if you are on a Linux machine. The material is found on GitHub.

Here are the steps for performance optimisation:

• do the profiling
• do the benchmarking
• do the optimising

The speaker mentioned 2 ways to do profiling: 1) using Frame Pointers (if they are enabled on the OS) but if they are not then 2) .eh_frame which stands for exception handling frame.

The speaker then explained what eBPFs are - they allow the Linux kernel to be more dynamic by loading small programs or instructions. From there he introduced Parca Agent; the profiler, an eBPF program that will show the stack trace on the system and how often a program uses resources when running.

"How Rust compiles" by Noratrieb

The speaker of this talk is a core contributor to the Rust compiler. She started her talk by running 3 lines of code on Rust playground that crash. The error goes away when using inlining (spolier alert: because there is no LLVM IR). She was therefore "promoting" inlining.

I am not a SME about what goes on under the hood in the Rust compiler but here are some terms to look up:

• postmonomorphism
• monomorphisation
• LTO (link-time optimisation)
• LLVM is singlethreaded
• MIR
• codegen units
• inlining
• link-time optimisation (LTO)

The speaker mentions that one can try to optimise for compile time or program speed but not both at once. She encouraged using inlining to optimise compilation. This entails adding the #[inline] attribute on top of functions and then benchmarking. But with LTO, optimisation of all the code happens all at once at the end.

Some useful resource include: the Rust perf book and this blog article.

"Misusing Const for Fn and Profit" by Tristram Oaten

This was an entertaining talk and felt like theatre. The speaker; who has a Youtube channel, should consider doing theatre if he doesn't already in real life.

His slides were done using a Rust-powered presentation software called Presenterm.

Some "cool/funny" crates that he mentioned at the end of his talk include:

• SQLX
• CONST random
• comptime
• constime
• lazystatic
• compile-time-run
• crabtime
• inline_python
• edition
• whichever-compiles