Rust SIG Meeting - 2026-07-07

[PLeVasseur]

Hey folks 👋 welcome to our 13th meeting of 2026.

Rust SIG Meeting 2026-07-07

Agenda

1. Solicitation of notetaker
   • Pete LeVasseur
2. Rust Watercooler Chat Topic: Dust DDS: A native Rust implementation of the DDS middleware; Joao Rebelo / S2E Systems
3. Review GitHub repo content and discuss how to enrich it (Pete)
   1. Issues
   2. Discussions are now active. The SIG previously agreed to take meeting notes there.
4. Office hours: Rust + Automotive questions — come chat (All)
5. Discuss upcoming events / news related to Rust & Automotive (All)
6. Meeting close

Check-in area

We had roughly 12 people present at peak attendance, including those listed below.

• @PLeVasseur
• xx

Housekeeping

• Document space: https://drive.google.com/drive/folders/1Ub0qTLKvTFilPC9TFVEdTyWn_9qJ-vYD?usp=drive_link
• GitHub repo: https://github.com/rust-sig/rust-sig
• Eclipse SDV Slack channel: #rust-sig

Tasks / action items

• No explicit action items were captured in the source notes.

Meeting Minutes

Dust DDS: A native Rust implementation of the DDS middleware; Joao Rebelo / S2E Systems

DDS backstory:

• started in military, for ships
• allow for configurability
• made its way to ROS, ROS2
• used in medical and robotics
• came across this personally at European Space Agency

Dust DDS, open source Rust native DDS implementation

DDS intro:

• Data Writers and Data Readers
• Write and read to topics; neither side has to know explicitly about the other

DDS definitions

• three specs from Object Management Group are core
• DDS for the API and Quality-of-Service (QoS) semantics
• DDSI-RTPS for the interoperable wire format
• DDS-XTypes for type compatibility and information exchange

Getting started with DDS

1. Define the data exchange types
2. Decide on the Quality-of-Service settings
3. Implement the publishers and subscribers

Defining DDS types

• Typically done using DDS Interface Definition Language (IDL)
• A special feature of DDS is that types have a concept of key (like a database)

Deciding on the QoS settings

• Some representative ones follow
• Reliability QoS policy (reliable or best-effort)
• History QoS policy (how many samples to keep? last 5? 10?)
• Durability of QoS policy (should samples be available for late joiners?)

DDS - blocking vs non-blocking data handling

• Have WaitSets for blocking actions
• Listeners for non-blocking / call-back style

Question: Why start new Rust DDS implementation?

• Open sourced Dust DDS a little later after they had
• But already had started ahead of time
• Feels there's some choices made with the other implementation that seem a little odd if you've come from DDS background

Question: Distinct differences between the two implementations?

• Thinks that Dust DDS has kept it a bit simpler on the APIs
• Other one was a bit more generic, little harder to read and reason about
• Other one used classical Arc<Mutex> approach
• Other one did not have Listeners in the past, this put a lot of pressure on Dust DDS and shaped architecture / APIs

Question: Performance differences?

• Performance is pretty much limited by network stack; try to be as transparent as possible
• In flame graph most time is spent in UDP send/receive

Question: Several DDS standards; one more -- integration of DDS and time-sensitive networking ethernet (TSN). Thoughts on its adoption to industry? Integration into Dust DDS needed?

• TSN part came in through DDSI-RTPS standard
• Then basically have timing and priorities
• Would have to modify the transport part of Dust DDS, then map QoS settings to TSN
  • QoS supports exposing priorities for messages and such that would impact

Dust DDS

• Let's look at sample code
  • Actually, in Rust we don't need IDL. Derive macros do the job.
  • Data-centric is nice; can have type safety for Readers and Writers

Differences with Rust DDS -- don't use Serde. Use own derive macro.

• Removes some dependencies
• Like most Rust projects started with Serde, but moved away from it

Typical usage for publisher:

• Use derive macro for type
• Create participant
• Create topic
• Create publisher on participant
• Create data writer which publishes; publisher is a group of them
• Wait on until Reader is ready
• Write to Writer
• Wait to hear back the ack

Dust DDS - explicit choice of small dependencies

• See DDS as building block; don't want to assume you want all those deps
• Doesn't have any tokio, serde
• Uses embassy-sync, regex, critical-section: keeps slim

Question: Users mostly std no-std?

• Mostly std, haven't heard many users for no-std

Question: Bring Dust DDS to Eclipse S-CORE?

• Would be happy to talk about it and consider bringing
• Exchanging tokio with kyron

DDS multi-platform support

• Dust DDS runs on Linux, Mac, Android
• Runs on bare-metal, using embassy
• Have abstracted runtime to allow for plugging this in (StdRuntime)

Dust DDS keeps it simple with its StdRuntime

• Timer, ability to have executor

DDS with other vendors

• Generally RTPS (UDP) as the agreed interoperability standard to allow multiple vendors to communicate
• Could communicate e.g. using iceoryx2 for shared memory or MQTT for other publisher-subscriber methods or any other data exchange mechanism

Transport trait

• Implement this, then you can put anything you want over the wire
• Have to be able to create participant
• Have to be able to send and receive bytes
• Must be byte-based communication mechanism

Question: Usually performance as a decision criteria. Some opt for DDS for throughput.

• Yes, if you pick MQTT that's TCP and you'd see a penalty from that
• But if you had some setup that already had MQTT broker, then could do this
• If looking for throughput then go for UDP, maybe even bring own runtime

DDS/RTPS discovery

• RTPS discovery is zero configuration
• Each participant announces itself regularly on multicast through a standardized address
• Based on this participant announcement data, readers and writers discover each other
• Matched readers and writers get configured between matching topics and QoS
  • Request and negotiation, where according to an algorithm there's a match found or not
• Application data only flows when discovery succeeds
• Exchanging the transport: end up with different discovery mechanism that have to handle yourself, possibly

Dust DDS IDL generator

• Dust DDS also provides an IDLgen to allow easier interoperability with other vendors and languages
• IDLgen is implemented with the PEST crate; used to create the parser from the defined grammar
• Input foo.idl to IDLgen and get out foo.rs

Dust DDS language bindings

• Bindings available for Python, e.g. can simply pip install or uv install
• API of DDS is quite standardized with the list of functions
  • Method: duplicate set of APIs for Python to bind against to make nicer for Python and not pollute the Rust-native APIs
  • Quite verbose, but also straight forward and gives what a Python user would expect
  • Also have Listeners for callbacks in Python

Question: How do you check that the binding is correct? Fuzzing?

• Use docs created on Python bindings
• Each has a match directly
• Build failure if something in bindings not in underlying Rust

Demo shown of working with publisher on computer and subscriber on phone

Interoperability with other vendors

• Has full interoperability matrix showing with other vendors, e.g. FastDDS, Conext DDS, and so on

Dust DDS Sync/Async API

• Dust DDSis build using an actor system architecture behind the scenes
• This sort of means we have an Async first API due to the way channels work
• Sync API is a sort of binding around the Async API by calling block_on
• Avoids Arc<Mutex> party; instead built on message passing
• Send, then wait on one shot reply
• Keeping sync API, as it's useful and planned main way exposed from C binding

Dust DDS Performance

• Runs Criterion performance benchmarks in CI, with stats and plots
• Non-blocking part of CI
• Available in the open on their Circle CI instance
• Could do sample batching to improve performance and get ~10 samples at once, but then have to wait on them

If there's a real business case for safety certifying Dust DDS, then could really consider it. Has stuck close to standard so documentation and traceability are solid. Footwork of documentation and traceability has not been done, but could imagine this as some effort.

Question: Is it good to assume that there are implementations safety-certified to certain levels?

• Connext, FastDDS are
• There's a couple of C implementations that can be safety-certified

Question: What does a typical architecture look like? Server and clients?

• Fully distributed
• All connected to network to avoid single point of failure
• Could have persistence storage as well as QoS

Recent events / things coming up for Rust

xx

Requested topics

xx

Material

xx

[adrianaioanei]

@adrianaioanei

[arvindr19]

@arvindr19

[tshepang]

@tshepang

[charcoalfrostmetallic]

@perrymcmanis144

[terechko]

@terechko

[kangwonlee]

@kangwonlee checking in