There’s nothing wrong with using dyn if the problem calls for it. In most cases it’s more idiomatic to use an enum to represent something like a strategy, but if your strategies are complicated entities in themselves, a trait is probably the right approach.

For a direct replacement, you might want to consider enums, for something like

enum Strategy {
    Foo,
    Bar,
}

That’s going to be a lot more ergonomic than shuffling trait objects around, you can do stuff like:

fn execute(strategy: Strategy) {
    match strategy {
        Strategy::Foo => { ... }
        Strategy::Bar => { ... }
}

If you have known set of strategy that isn’t extensible, enums are good. If you want the ability for third party code to add new strategies, the boxed trait object approach works. Consider also the simplest approach of just having functions like this:

fn execute_foo() { ... }
fn execute_bar() { ... }

Sometimes, Rust encourages not trying to be too clever, like having get vs get_mut and not trying to abstract over the mutability.

Traits like std::io::Write are essentially Strategy pattern. Take a look at how that’s used. You’re doing it mostly how I would, except for the Box<dyn T>. Generally it’s preferred to use generic functions/types in Rust instead of dynamic dispatch, i.e. have a fn do_something<T: MyTrait>(imp: T) instead of a fn do_something(imp: &dyn MyTrait).

I agree with the other suggestions so far, to wit:

1.dyn is fine, when you need it. People will give you a lot of guff about performance but vtable lookup on a dyn is no less performant than the same thing in C++ (in higher level languages almost every call is dynamically dispatched and those are used for plenty of serious, performant work).

1. Use enums more.

2. Use traits and generic functions

And I would add a couple of other thoughts.

For some DI type work, you can use cargo’s Features to define custom build flags. You can then put variants on the same code (usually implementing a trait) in different modules and use conditional compilation on the Features to swap out which code is used. This is like a compile-time strategy pattern. I use it for testing, but also to swap out databases (using a local in-memory to test and a real one in prod) and to swap out graphical backends on my roguelike (compiles to OpenGL on windows but Metal on my Mac).

You’ll probably want to learn Rust’s macro system sooner than later as well. Sometimes a macro is better than a function when you need to generically operate over several types (function argument overloading, in other languages) or work on something in a general but well-structured way (tree walking for example).

I spent like a week on this last month. Usually you use enumeration, but I wanted to allow client code to define their own strategies. I tried the Box<dyn MyTrait> pattern because some of my strategies were composed of other strategies, and I wanted to clamp down on generic types. But I kept running into weirder and weirder compiler errors. Always asking for an additional restriction on the base trait. X, must be Copy, must be Send, must be Sized, must be 'static. On and on. My experience is if I’m getting a bunch of those then I’m off the Golden Path. So I just embraced the verbosity of using generics and its easy. Yes its more code but its better code.

Minor nit: Kotlin is decidedly not a functional language.

Design patterns in OOP exist purely to solve the problems created by OOP itself. If you have a language with proper ADTs and higher order functions, the need for traditional design patterns disappear since the problems they solve are first-class features baked into the language.

The first-class replacement for the Strategy pattern (and many other patterns such as the Visitor pattern) is sum types (called enums in Rust).