Draft: Migrate Transport to Rust

[Kaweees]

No description provided.

[chatgpt-codex-connector]

💡 Codex Review

Here are some automated review suggestions for this pull request.

ℹ️ About Codex in GitHub

Codex has been enabled to automatically review pull requests in this repo. Reviews are triggered when you

• Open a pull request for review
• Mark a draft as ready
• Comment "@codex review".

If Codex has suggestions, it will comment; otherwise it will react with 👍.

When you sign up for Codex through ChatGPT, Codex can also answer questions or update the PR, like "@codex address that feedback".

[paul-nechifor]

Why is there a uv.lock file here too?

[Kaweees]

Stash said we should track it during a call we had. I can remove it if you would like.

[paul-nechifor]

Ah no, I was asking if we need two of them. Should dimos_rs have its own requirements or be in the root? Just asking.

[paul-nechifor]

I don't think these are the values we're using. For example for line-length we have 100 in pyproject.toml

[Kaweees]

These are the common practice values for each of the respective file extensions, I can change them based on the project specific configurations.

[spomichter]

Yeah we use ruff may be overkill to use both ruff and this editorconfig

[paul-nechifor]

Ruff doesn't fix the non-python files. Also the pre-commit editorconfig checker is quite fast.

Many people have their editors set to automatically remove trailing whitespace. If we allow it we'll end up with many conflicts from future contributors.

[leshy]

Just missing the rationale on my end,

Pubsub is already a light adapter layer, expecting just publish() and subscribe() from implementations which can be in any language, CPP in case of LCM

What is the expected benefit of bumping an abstraction layer a notch higher to publish() and subscribe() being in rust? Is the idea to gain speed? which computations are you expecting to speed up?

[paul-nechifor]

Just missing the rationale on my end,

Pubsub is already a light adapter layer, expecting just publish() and subscribe() from implementations which can be in any language, CPP in case of LCM

What is the expected benefit of bumping an abstraction layer a notch higher to publish() and subscribe() being in rust? Is the idea to gain speed? which computations are you expecting to speed up?

I believe it started with this C++ rewrite bounty, which was changed to Rust, and the had its scope narrowed https://discord.com/channels/1341146487186391173/1341151189114556417/1436907807738953860

BTW, as a team, we could probably use a bit more formality. Like writing down GitHub issue or maybe liniar.app issues. And every once in a while closing issues/PRs which are unlikely to be done.

[leshy]

Just missing the rationale on my end,
Pubsub is already a light adapter layer, expecting just publish() and subscribe() from implementations which can be in any language, CPP in case of LCM
What is the expected benefit of bumping an abstraction layer a notch higher to publish() and subscribe() being in rust? Is the idea to gain speed? which computations are you expecting to speed up?

I believe it started with this C++ rewrite bounty, which was changed to Rust, and the had its scope narrowed https://discord.com/channels/1341146487186391173/1341151189114556417/1436907807738953860

I'd like to understand to what exactly was the scope narrowed and what's the rationale for above?

I'm asking becuase there is a good direction for exploration of faster language integrations but this doesn't seem to be it

Rust dimos modules could easily talk to py dimos using existing pubsub and would let us operate rust only given rust only modules are used for a particular robot. First candidate would be connection.py for go2, specifically lidar frame processing, idk why would anyone start rewriting python transport adapter layer to another language though

[paul-nechifor]

Just missing the rationale on my end,
Pubsub is already a light adapter layer, expecting just publish() and subscribe() from implementations which can be in any language, CPP in case of LCM
What is the expected benefit of bumping an abstraction layer a notch higher to publish() and subscribe() being in rust? Is the idea to gain speed? which computations are you expecting to speed up?

I believe it started with this C++ rewrite bounty, which was changed to Rust, and the had its scope narrowed https://discord.com/channels/1341146487186391173/1341151189114556417/1436907807738953860

I'd like to understand to what exactly was the scope narrowed and what's the rationale for above?

I'm asking becuase there is a good direction for exploration of faster language integrations but this doesn't seem to be it

Rust dimos modules could easily talk to py dimos using existing pubsub and would let us operate rust only given rust only modules are used for a particular robot. First candidate would be connection.py for go2, specifically lidar frame processing, idk why would anyone start rewriting python transport adapter layer to another language though

I guess this should be discussed on Discord?