Rust and Robotics?

Hi everyone!

In our last Weekly Robotics meetup with Tangram Vision we briefly started discussing using Rust in robotics development. It seemed that lots of people were interested in the and we thought it might be a good idea to have a meetup where people could discuss their experience using Rust.

Anyone would have any experiences they would like to share? Let me know and I will try to come up with some idea on running this session.

If anyone from the Rust WG would be interested in presenting too that would be amazing!


Currently there are two projects exploring the use of Rust with ROS:

In addition, I do believe there is a monthly working group that meets about getting Rust working with ROS. @esteve and @ruffsl would know more about this working group.


We at Chalmers University of Technology are working quite a lot with rust and ros2, and have developed r2r. We are mainly working with various automation projects using automated planning and ros2. Most of our work is located under the Sequence Planner · GitHub organisation. We started working with rust, 2-3 years ago and really like it. Especially writing async rust when writing our ros nodes is great.

We are fully booked this year, but maybe we can share something related to r2r next year.


At the moment, we’re at more of an “as-needed” meeting schedule, though I just floated the idea of meeting a bit more regularly. If you would like to listen in or join in our discussions, you’re always welcome to join our matrix channel!

At the moment, our big focus area (apart from the client library linked by @zmk5) is getting Rust build support integrated with cargo via the colcon-cargo plugin.


Now three!

This is still a work-in-progress, but feedback is welcome.


Hi everyone!

Are there any conceptual big differences between these 3 client libraries? I am asking because I see that if there is so much people wanting to write the client libraries, then seems like a lot of people want to write ROS applications in Rust :smile: .
Are there any plans on consolidating the efforts on one particular library?

I wish to be part of rust working group, because it really looks like this language is perfect fit for robotics, but seems like I can not join matrix group (@jhdcs) with element web ui, is there any direct invitation required?


Hi @alexkaravaev !

Good question! Disclaimer: I’m the original author of ros2-rust and was a member of the ROS2 core team, but I’ll try to be as unbiased as possible.

All three projects have their merits and different goals:

  • ros2-rust has a strong emphasis on being integrated into the ROS2 ecosystem (that includes the build system, message generation, etc.) with the eventual goal of being part of the standard ROS distribution. Hence it leverages the ROS2 infrastructure (e.g. the message generation pipeline, integration of Cargo as a build system into ROS via ament, allowing it to be built via colcon, etc.).

  • r2r is a crate that uses rcl as the common layer for integrating with ROS, but foregoes some of the ROS infrastructure. For example, it does not do message generation in the traditional ROS way, but leverages bindgen to generate bindings for messages at compile time. This has the advantage that it’s not so tied to ROS and can implement features without certain constraints.

  • ROS2-client bypasses the ROS infrastructure entirely and uses RustDDS directly as a transport layer, it doesn’t do any message generation, but uses the DDS API to send messages. This has the advantage that you can write an application that only uses Rust and no external libraries. The drawback is that you’re tied to DDS as your transport layer (e.g. if you want to use zenoh or any other alternative RMW implementation, you can’t)

Hope this helped to clarify the differences between the three projects

I believe @jhdcs has sent you an invite to the channel, hope to see you there!


If you haven’t received Jacob’s message, I think you (and everyone else) can join via the following link:

1 Like

Thank you @esteve !

Now the whole situation is clear to me.

1 Like

Hi, it looks like the ros/rust community is working well towards putting ros as a standard programming language. Why did you all choose to work toward using rust instead of using golang ? I felt like these two languages were pretty similar, while go is easier to learn hence would attract more people towards shifting to this language.

Programming language preferences are almost always going to be a highly subjective matter, with a particularly strong bias towards familiarity. The idea that Golang is easier to learn than Rust may be heavily influence by a person’s past experiences, learning styles, and the environment that they work in.

I’ve found the official free online Rust documentation to be extremely easy to follow, and the Rust compiler gives amazingly helpful error messages often with enough guidance to fix the problem without needing to do any research. I haven’t tried Go myself, but even if it’s “easier” to learn than Rust, that wouldn’t be a factor for me since Rust has been easy enough to learn that the learning curve has never been a blocker for me.

At a glance from looking at Go, the most obvious advantage that Rust has over Go is that Rust does not do runtime garbage collection, meaning the performance of Rust-compiled code should be closer to C++ while the performance of Go-compiled code should be closer to Java. There may be many applications where that doesn’t matter, but robotics is often striving to have deterministic performance in resource constrained environments, so that immediately makes Rust more appealing than Go.

I’ll reiterate that I’ve never used Go, so I don’t know if I’m making a fair comparison, but some other things I really like about Rust is the way variants are first-class citizens of the language and pattern matching is built into the language syntax in an amazingly ergonomic way. It doesn’t look to me like Go offers that convenience. Variants and pattern matching are extremely helpful for defining state machines, and state machines are a mainstay of robotic systems programming.