[kaba0]

I don’t think there is much point to these discussions without at least fixing some parameters/problem domain across languages. Of course pointer chasing is worse than a well-thought out encoding that fits many objects into a cache-line and is sequentially accessed. The question is — can the problem at hand use such a structure in the first place? Because not every problem can be solved with ECSs and the like - hell, I would even go as far to claim that most programs have a small hot loop, and otherwise spend their time slowly crawling through vast amounts of code and data in a non-orderly fashion. What part is prone to nice, sequential access is traditionally handled by the DB, which does its work very well. For the resulting 10 lines that has to be iterated through, it doesn’t really matter if it’s pointer chasing, especially when it has to wait for IO at every step in a typical server application.

So if we actually compare similar problems at hand, for a certain kind the difference is negligible, and is well offset by safety, productivity, maintainability. Hell, due to having safer primitives, one might be able to take advantage of better parallelism, that easily makes up for the slower single-core performance.

[vkazanov]

I agree with most things you say. This is why most DBs are written in C relatives or descendants: C++, Rust, or just good old C. And Java dominates in the server-side business logic domain.

But boy it's cumbersome in anything other than those long running jit-friendly server-side processes..!

PS for IO-heavy purposes almost any mem-managed language would do. The real code running there is OS figuring out hardware and physical reality.