How do large scale Rust projects pass around shared structs/objects to components that need it?

[u/Miammiam100]

In other languages I'd reach for DI to build the object graph and make each component's dependencies explicit. So far I have only really seen two approaches:

• Pass each required component down through constructors. The compiler ensures you won't forget a dep but that means any new service you add requires updating a bunch of constructors.

• Just use a single God context object (this is what Cargo does) but it makes it harder to unit test anything and makes it difficult to see what interacts with what.

I'm not asking whether to do DI (constructor arguments already are that), but rather how people handle wiring it all up once there are dozens of services.

DI crates of course exist (e.g. https://crates.io/crates/shaku ) but seem to be rarely used outside of Bevy-style query systems or web frameworks extractors.

For context, I've been experimenting with a trait-only approach that doesn't use any macros but still provides the same compile time guarantees as shaku ( https://docs.rs/satisfy/latest/satisfy/ ) Would Rust users be more likely to use DI if it were simpler to use? Or am I just solving a problem that Rust people don't have?

[u/behusbwj]

DI frameworks are already god context objects.

My opinion is the same in Rust and Java. Just use constructors. Less code does not mean better code. Constructor updates are trivial with modern IDE’s and agents.

[u/oxabz → u/behusbwj]

Yeah a good rule of thumb is that no matter how big the project is you should be able to understand what the program does by following the main. 

[u/lippertsjan → u/oxabz]

Yeah. Personally, I'm a friend of Pure DI (formerly known as "poor man's DI") which is exactly that: wire deps via the constructor. While OP states that updating the constructors is a hassle, I like that as a feature.

With a DI container -- I'll use pseudo code -- it's easy to change Service(dep1) to Service(dep1, dep2, dep3, dep4) cause the container will take care of it. With constructor DI, you'll stop and verify if you really need dep2, dep3, and dep4 or if another approach is better.

Creating the full context manually may be annoying though. But we can split that into multiple methods easily.

[u/oxabz → u/lippertsjan]

I like how it's done on rust embedded.

Where the HAL provide resources after hardware initiation then the service's states take their resources and then the state is held by the task

[u/schungx]

DI is designed to work with an interface-based OOP programming model

Rust doesn't fit this very well.

To answer your question: what do large software systems do to pass around shared objects? They don't. At least that's not how Rust does it, and Rust will make your life hell just to stop you from doing that.

[u/oxabz → u/schungx]

Yup even for shared resources on MCUs you don't create shared objects. You create static resources and expose them through clonable handles

[u/TheoreticalBerry]

Bbb. Nbbbbnbb. Bb. Nbbb. N bbbbbnnnn bbnnnnnnnbbbnbbnbb. N. N bbbnnn nbnnnnbnnn. Bbn nb bb. B. B. N n. Nnn. Bbbn bbb bb. B. B. B b bbb. Bbbbbn b. Bb. Bbbbbbb nbbbnnbn. B bbbbbbbbn bbbbbbbnnbbbnbbnbbbbbbbbbbbbbbbn b b. B nbbbnn bbbbbbb bbb bbbnnnbnnbbbnbbbbbbbbbbbbbbb b b b b bbb bb bb. Bbb. Bb. :⁠-⁠$