Data ownership design patterns? Feasible or not?

community
21

There's no magic to how we solved the memory management issues.

  • clone() is your friend when conversing with the borrow checker.
  • Don't put references in your structs.
  • Don't share mutable data; use a channel to send changes to its owner.
  • Don't worry about performance until you have a performance problem.

You can probably infer the last one from the first three.

6 Likes
22

Gotcha

23

Anything like this? The Shadow Simulator

24

The same idea but with our own network topology and link protocols. The Shadow Simulator is far ahead of us in running real applications and performance modeling; we only have a distributed "Hello, world" running now.

I think this discussion is off topic for this forum. Contact me privately if you want more information.

25

TL;DR I think it would be great if anyone is up to writing a treatise on "patterns" in Rust that they present examples of those patterns, as named in the GoF book, in Rust.

I have to come clean and state up front that I have never read the famous GoF book. It came when Java was all the range. I have never been drawn to the OOP everything idea and Java was no use in my world of embedded systems that needed to be small, fast and portable. So GoF was not on my reading list. But ....

As far as I can tell GoF is not about object oriented programming. It's about design patterns. It is an exercise in shoehorning common, and not so common, programming techniques/strategies into the object oriented world. Thus making it possible for those in the "everything is a class" world get anything done.

I recently discovered this vague notion of mine is very clearly expressed by the work of Mario Fusco.
"From object oriented to functional domain modeling": https://www.youtube.com/watch?v=K6BmGBzIqW0
"g ∘ f patterns by Mario Fusco": https://www.youtube.com/watch?v=Rmer37g9AZM

He even demonstrates the point concretely, in a live coding session, by taking some examples of GoF patterns in the traditional OOP style and greatly shortening, simplifying and clarifying them by throwing away the classes and OOP junk and replacing them with a sprinkling of lambdas, options and matches. (Does that sound a bit Rusty already?).

An important thing that GoF did was to give names to those programming techniques so that programmers can understand each other when talking about what they do.

So, in short, I think it would be great if anyone is up to writing a treatise on "patterns" in Rust that they present examples of those patterns, as named in GoF, in Rust.

1 Like
26

This topic was automatically closed 90 days after the last reply. We invite you to open a new topic if you have further questions or comments.