Obviously it should be "shared nothing" as it would allow you to horizontally scale your application and code will be much easier to develop and test. But in reality you inevitably need to have a shared state in one way or another. You could try to move that state into some dedicated service, like database, but it's not always performant enough (or even applicable). So you end up with shared memory because of performance.

What would you suggest?

"Many lock-free structures offer atomic-free read paths, notably concurrent containers in garbage collected languages, such as ConcurrentHashMap in Java. Languages without garbage collection have fewer straightforward options, mostly because safe memory reclamation is a hard problem..." - Travis Downs https://travisdowns.github.io/blog/2020/07/06/concurrency-co...

But it seems there is also some benefit to have a VM in addition to a GC for this joint/atomic parallelism.

E.g., you can look up something like a lock-free linked lists, the first of which were described decades ago. They have an algorithm to delete a node from the list, but what often isn't emphasized is that you can't just free that note by calling `free()` on it, because you don't know if any other readers might happen to have a reference to that node, and thus may access the underlying memory. If you free it, they might access freed memory.

In general, this is a hard problem to solve. You can wait, but how long is long enough?

Garbage collected languages solve this more or less automatically: there is no explicit free() but instead the GC determines when there are no more live objects and frees it for you.

This isn't unsolvable in native languages, but none of the solutions are as clean and tradeoff-free as you'd find in a GC'd language.