An Introduction to Data Oriented Design with Rust

> This is just as cumbersome in the array-of-structs case: some structs are larger than others in the same array, you need some signalling mechanism to know which structs are and aren't Point3Ds

Strong disagree. The traditional OOP approach is passing indirect pointers to everything and incurring an inefficient level of indirection.

Ex:

    vector blah;
    blah.push_back(&somePoint2D);
    blah.push_back(&somePoint3D.xy); 

    foo(blah); // "Function foo" works on Point2D and Point3Ds, none the wiser
    // Note that foo may change *blah[10].x += 5
    // and it updates the original Point2D or Point3D. This
    // wouldn't work for a copied array.

I think OOP's inefficiency is well known and often criticized. Critics are correct: OOP methodologies are inefficient (compared to other techniques). But OOP seems to have a win on various software-engineering metrics: Extendability, Open-Closed, DRY, etc. etc.

> In Rust the AOS case would be an Enum of Point and Point3D, and the SOA case would be two Vecs of ints and one Vec of Options.

Rust is a general purpose language. I'm not too good at Rust, but the AOS case would simply be a Box(Point2D).

> More generally, this sounds like a language support problem

ISPC got SOA types by the way. Check em out if you're interested:

https://ispc.github.io/ispc.html#structure-of-array-types

You don't need a very large SOA-type to take advantage of SIMD or auto-vectorization. You can "gather" into an SOA, then "scatter" back to your main representation.

Hmm, I'll admit that this is the first time I've heard of the ECS pattern. So I'm not too familiar with your argument. From your description, and from various links discussing the pattern, it seems like an adequate solution to the problem I posed.

I would argue that an ECS is quite far removed from what the original article was talking about however. But perhaps the original article was too superficial in its discussion of DOD.

So?

> Whilst it’s impressive you’ve managed to hold an argument with yourself

I like to address the boringly predictable responses up front so we can avoid rehashing the same silly arguments over and over. I apologize if that spoiled your fun.

> Is immutability a defining feature of FP? Let the battles commence.

I think most would agree that immutability is more prevalent in FP even if struct immutability isn’t required. Moreover, everyone would agree that first class functions and functional composition are key characteristics. Contrast that with OOP where you have some OOP enthusiasts arguing that inheritance is a defining feature and others who argue it isn’t. Some argue that the “kingdom of nouns”, banana-gorilla-jungle design is inherently OOP and others argue it’s “bad programming and not true OOP”. Others argue that message passing is required, but many others argue to the contrary. While other programming paradigms have fuzzy edges, OOP has no discernible shape at all.

> And whilst I’m not particularly interested in defending OOP I think describing it as uniquely plagued with bad code is not something anyone should just take axiomatically.

Why are there no equivalent criticisms of FP or DO? We might find FP codebases that are overly abstract or a bit slow, but we don’t tend to find (m)any that are designed such that a Book object holds a reference to an Amazon SDK client or a banana with a reference to the gorilla holding it with a reference to the entire jungle. There aren’t prevalent guidance to write code like that in other communities like there is (or perhaps “was”) in OOP circles. Similarly, there aren’t enterprise-y abstract factory beans or anything like that in the FP world.

Mind you, I’m not dumping on OOP—indeed I couldn’t if I wanted to because it has no agreed upon definition, per its proponents.

Correct if i'm wrong: The general conclusion is Vectors are faster and pattern matching is slower in observable way when generating vectors.

I wonder if it changes when vec items becomes bigger structs and size goes to millions.

Rust dosc says with LinkedLists that you should better use Vec for speed. I think just raw array of bytes is always faster than linked pointers. But LinkedList will probably have less of a memory pressure in cases where you have to maintain large list and remove elements at random while keeping coherency.

from Rust docs: Vector = "A contiguous growable array type, written Vec but pronounced 'vector'."

LinkedList = "A doubly-linked list with owned nodes.

The LinkedList allows pushing and popping elements at either end in constant time.

NOTE: It is almost always better to use Vec or VecDeque because array-based containers are generally faster, more memory efficient, and make better use of CPU cache."