Inject dependencies via constructor parameters - this is best practice in any language. Unit testing you can just... pass in the values you want.

You can, of course, always do Pure/Poor man's DI [1].

[1] http://blog.ploeh.dk/2012/11/06/WhentouseaDIContainer/

You can still do dependency injection in Rust..? There even exists a create for it: https://github.com/Nercury/di-rs. There's also some further discussion here: https://users.rust-lang.org/t/how-do-you-implement-dependenc...

I saw that but it seems really complicated for something that should be straightforward. Or it just looks so? (coming from c#)

If I understand it right, Rust has "zero-cost abstractions" meaning that they don't exist at run-time, just when compiling. e.g. http://blog.rust-lang.org/2015/05/11/traits.html

This is the right choice if you want the language to be "a better C" but it means that there is none of the Run-Time Type Information that we are used to in C# (or java).

The RTTI plays a small but key role in e.g. how a DI container works: The container works out what parameters a constructor needs at runtime and instantiates those recursively; and in how a mocking framework works: Generating a class on the fly with the right interface declaration. Even XUnit/NUnit work by using RTTI: The testing framework looks for all classes/methods with the right attribute metadata, and runs them.

It's easily fast enough for how we use C# and Java, but it's not zero-cost.

There are unit testing tools in Rust, but they cannot work the same way - IIRC, there is compiler support for them. So, While Rust as a good chance at being "A better C", don't expect it to do all the things that C# does involving types at runtime. A different goal meant a different language design.

There are other interesting things in Rust like the Macro system that might help do similar things, but it's really not going to work like in C#

Dependency injection as a concept is not tied to a framework. Just inject your dependencies into constructors.

I occasionally do this even in languages with good DI frameworks like Java when I don't want to pull in a Guice or Spring dependency. Even "manual" DI like this is so much better than not doing DI at all.