# Better Rust Observability We would like to improve the state of inspecting Rust projects at runtime. Currently, this fields is fractured and logs coherence. This is preferably done by reusing existing methods and libraries, but also with some substantial own development. Observability describes the ability to gather data about the runtime from a program, often to monitor its current behaviour. It can also be used during development though, e.g. for debugging. Our thesis is: all tasks to gather runtime information about programs often boil down to a base number of techniques and could be improved if the whole stack cares about such tasks. ## What to observe at runtime? * Business events, such as a new client arriving * High-level events, such as a task resuming or yielding, descheduled, etc. * Similar, for threads * Low-level events, such as function calls * Timing in-between events * Other system metrics, such as memory consumption, Stack depth, etc. * Location of events in the original source (often called source-to-object traceability) At development time, there's other metricts that are useful: * Code Coverage ## Common approaches * Logging/tracing (e.g. the rust tracing) * Sampling (e.g. perf) In general, these may happen either: * Through source code annotations (essentially manually) * Through platform facilities, such as dtrace, systemtap or perf * A mix of both, often through language frontend hacks (e.g. dtrace uses a special macro that inserts "dead" regions into a program that can be activated) Some of them are intended for live operation, others to be used during development. In the case of managed languages like Java and such, they become features of the runtime, in the case of runtimeless(ish) languages such things have an unclear place. This leads to a diffusion of responsibilities and island solutions. ## Suggested solutions * Unification of a fractured toolspace around Rust, but also about C/C++. * Easy to deploy on common platforms to allow for spread. * Easy integration in tools like rust-analyzer, clangd (perhaps through an LSP)
Last changed by  
 
Florian Gilcher
47

Read more

Code examples

https://github.com/ferrous-systems/rust-exercises/ https://github.com/ferrous-systems/rust-training/ https://play.rust-lang.org https://manishearth.github.io/blog/2015/05/17/the-problem-with-shared-mutability/ https://ferrous-systems.com/blog/testing-proc-macros/

3/24/2025
The present and future of Rust in Safety

Rust is a new language - released in 2015, it has taken the software programming word surprisingly swiftly. Now, not even 10 years later, we have ongoing projects and initiatives in the Safety/SDV space. This talk provides an overview of currently ongoing initiatives, an assessment of challenges and an outlook into the future. Florian Gilcher is one of the Management Directors and Co-Founders of Ferrous Systems, the most experienced Rust services company. He's been around Rust for over a decade, including time on the Rust Core team and being a co-founder of the Rust Foundation. In this time, he's been observing trends and solutions in the space with a keen eye.

9/24/2024
tRust

View the slide with "Slide Mode".

6/27/2024
Confidentely using async/.await

Rust is great for writing async code. But what async code should you write? This workshop will take this question and introduce you to basic async patterns and how to apply them in Rust. It will guide you through async programming concepts and give you a glimpse into constructing larger, concurrent applications out of the basic elements. It will introduce you to tasks, how they apply to threads, evented IO and how Rust manages all the hard bits. Other topics include async testing and how to come up with new, high-level abstractions. Workshop contents: The basic model of async in Rust: Futures, Tasks, async/.await How this model applies to libraries like tokio How to use building blocks like tasks and channels to build reactive systems

3/13/2024
Read more from Florian Gilcher
Published on FerrousSystems