Rust

6046 readers

20 users here now

Welcome to the Rust community! This is a place to discuss about the Rust programming language.

Wormhole

[email protected]

Credits

The icon is a modified version of the official rust logo (changing the colors to a gradient and black background)

founded 1 year ago

MODERATORS

[email protected]

Strategy Pattern in Rust (programming.dev)

submitted 3 months ago* (last edited 3 months ago) by [email protected] to c/[email protected]

19 comments fedilink hide all child comments

Hey there, I'm currently learning Rust (coming from object-oriented and also to some degree functional languages like Kotlin) and have some trouble how to design my software in a Rust-like way. I'm hoping someone could help me out with an explanation here :-)

I just started reading the book in order to get an overview of the language as well.

In OOP languages, I frequently use design patterns such as the Strategy pattern to model interchangeable pieces of logic.

How do I model this in Rust?

My current approach would be to define a trait and write different implementations of it. I would then pass around a boxed trait object (Box<dyn MyTrait>). I often find myself trying to combine this with some poor man's manual dependency injection.

This approach feels very object oriented and not native to the language. Would this be the recommended way of doing things or is there a better approach to take in Rust?

Thanks in advance!

you are viewing a single comment's thread
view the rest of the comments

[–] [email protected] 2 points 3 months ago (1 children)

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).

[–] [email protected] 3 points 3 months ago (1 children)

Truth has been spoken.

Except that Kotlin is functional (just like Rust, C++, Visual Basic, JavaScript,...). It is, however, not Pure Functional (like Haskell or Lean4 would be - if you haven't checked out Lean4, I can recommend it, great fun).

(Sauce: https://en.wikipedia.org/wiki/List_of_programming_languages_by_type#Functional_languages)

[–] [email protected] 4 points 3 months ago (1 children)

That list also counts Java and C# as "functional languages". I wouldn't take it too seriously. Ocaml, Scala, F#, etc. are impure functional languages. Kotlin absolutely is not. Having a couple of features you might find in functional languages does not make a language functional. Kotlin is still very much an OOP-based language. It's basically a somewhat nicer Java.

[–] [email protected] 3 points 3 months ago (1 children)

I know, from a mathematics standpoint it does not make sense, but from how the term is used nowadays in programming it does: Those languages allow to compose functions, pass functions as parameters, return functions, etc.

[–] [email protected] 3 points 3 months ago (1 children)

A language is not functional just because it supports higher order functions. Technically C even supports them (even though the ergonomics and safety of them are terrible). Would you call C a functional programming language? Obviously not. Rust is also not a functional language, even though it comes closer than most OO/imperative languages.

Kotlin and plenty of other OO languages have borrowed some ideas from functional languages in recent years because those ideas are useful. That doesn't make them functional languages. If Kotlin were a functional language, then it wouldn't need libraries like arrow to try to make doing FP in Kotlin even (kind of) possible.

Hallmarks of FP (beyond higher-order functions), in no particular order:

Organization around functions as the fundamental unit of code
Code primarily defined in terms of expressions and data transformations rather than statements manipulating object state (so languages that have big blocks of imperative statements like Kotlin don't count)
A general orientation around pure functions, even if they vary on the degree to which they enforce purity
Explicit parameter passing being the standard and preferred way of providing data to functions, rather than methods operating on implicit state
First class support for function composition (method chaining doesn't count)
Pattern matching and destructuring as a first-class and ubiquitous concept (what Kotlin does have is a joke comparatively and no one would actually call it that)
For statically-typed functional languages, first class support for algebraic data types (Kotlin has sealed classes which can kind of be used to try to emulate it, but it's pretty awkward in comparison and requires you to write very OO-ish code to use)

There are some minor exceptions, such as Clojure lacking pattern matching, but on the whole functional languages generally fit these descriptions.

[–] [email protected] 2 points 3 months ago

Points that I would gladly agree upon - but it seems the Wikipedia authors don't.

I am not knowledgeable enough to draw a definite line what counts as functional and what doesn't - so I chose to go with whatever Wikipedia says... Even though I dislike it.