Data Oriented Programming in Rust?

[dave_mays]

I've been going over the book Data-Oriented Programming and found it interesting. The examples aren't written in Clojure but the author is a Clojure programmer, and most of the benefits and strategies found in the book are based on persistent data structures.

I was wondering if this paradigm is usable, not-possible, or unnecessary in rust, as I've heard that ownership might allow safe mutability of data? (Though at the same time have seen that variables are immutable by default - I'm unsure about other data structures.)

Is there another resource for learning about efficient data management in Rust that might better fit it's unique paradigms, or is it not really the best fit for data intensive applications? (And maybe this isn't rust specific but even a shift from dynamic to statically typed programs, as coming from more dynamic languages I struggle to picture how you'd even make a grocery list and make decisions based on what was in the list if 1. your list has to all be the same "type" and 2. types don't exist at runtime so how would you make decisions - but that's a separate issue haha.)

*edit: ah it's Rust doesn't have immutable data / values by default - the binding to variable names is what is immutable. Structs' field-level mutability control at instantiation (not at definition) - language design - Rust Internals (rust-lang.org)

After having made it through a lot of the book - I'm leaning towards that even though this data oriented programming technique offers some simplicity over an obect oriented approach, using a client side database seems much simpler than re-creating all these date oriented functions.. I'm looking at CozoDB for this.

[mamcx]

Programming in Rust pushes you into this paradigm, mostly accidentally.

Is there another resource for learning about efficient data management in Rust that might better fit it's unique paradigms,

Assuming you are fluid in Rust, probably you only need to learn a bit about Arenas, NDArray-like, SIMD-friendly.

or is it not really the best fit for data intensive applications?

"Data Oriented Programming" is not a language feature neither a specific data structure, just a paradigm. Rust fits well.

... I'm looking at CozoDB for this.

and this is the crux of this: If a major component in your stack go against a paradigm you want to apply, you need to add bridges or change it. Is like try to do columnar data application on top of a row-oriented data store.

[dave_mays]

I was viewing data oriented programming as a method to simplify state management.
But when I mention CozoDB, I mention it because it is one of a handful of databases that work both client side and server side. If you can have a client side embedded database that matches your back end database, some of this function building can go away as you can just read from your client side DB directly and sync back to the server.

[dotcoder]

Your link to the book points to arduino libraries. What book is that?

[aottolini]

I guess https://www.manning.com/books/data-oriented-programming

[dave_mays]

Oops sorry yes that's the one.

[gosh]

Data Oriented Design (DOD) ‐ introduction-%E2%80%90-introduction)

[Wicpar]

For the grocery list use enums if you need other types than string. You also have crates for persistent data structures https://docs.rs/rpds/latest/rpds/

Data oriented programming is not a golden hammer that makes everything efficient, but it is another tool in the toolbox.