You completely missed the point, which is that you fundamentally don't understand how these things work. > Joint as I said; and it's not rocket science so I'm

You completely missed the point, which is that you fundamentally don't understand how these things work. > Joint as I said; and it's not rocket science so I'm getting a little annoyed; is when two separate cores work on the same real-time task that shares memory, most software 1) does not do this yet because it's hard 2) most programmers don't learn this because 1). That's just parallelism. What do you think openMP does? It is a fork-join model and is the easiest method of parallel programming because reading data that isn't being written to is trivial. > For example Erlang, Rust and Go are terrible at sharing memory because they have simple memory models, they solve parallelism by synchronizing hard and slow with copying and locks. This is not true. Again you are not understanding the fundamentals of what a system language like rust does. https://doc.rust-lang.org/std/sync/atomic/ https://doc.rust-lang.org/std/sync/atomic/ > And yes games today have 10 frames of motion-to-photon latency, I measured it myself. I measured it and it was 1 frame > Until you show me something joint parallel you have done and preferably proven (with say 450 concurrent real-time action users on one machine); I'm calling this settled, your arguments are thin! (also why am I arguing with a user called dildo?!) None of this has to do with validating the things you have said. If you can use the concurrent data structures then that's good, that's what they are there for. I think you have a very warped idea of what you actually understand. Cars get people where they want to go but getting your driver's license doesn't mean you can design an engine.