[bsder]

I retort that almost all of the concurrent data structures are obnoxious to represent in Rust.

A lock-free ConcurrentHashMap, for example, is by no means a straightforward data structure in a non-GC language. Even if you somehow dodge Rust's pedantry, you still have to figure out who owns what, who pays for what and when they pay for it--and there are multiple valid choices!

Non-GC allocation/deallocation in concurrent data structures probably still qualifies as a solid CS problem.

(And, before you point me to your favorite crate for ConcurrentHashMap, please check it's guarantees when one process needs to iterate across keys while another process simultaneously is inserting/deleting elements. You will be shocked at how many of them need to pull a lock--so much for lock-free.)

[kprotty]

This is partially why allocation is left to the caller (concurrent data structures are often intrusive), have single consumers (made lock free using separate synchronization) or only have lockless guarantees not obstruction freedom.

I think the obnoxious part in Rust is doing intrusive and shared mutability parts of data structures. Having to go between NonNulls, Options, Pin, and Cell/UnsafeCell is not a pleasant experience.

[richardwhiuk]

You should always know who owns some data, even if you aren't using Rust!

[rafram]

Garbage collection means the VM owns it! And that’s great. How it should be.

[richardwhiuk]

Welcome to a land of memory bloat because you've got a chain to a reference due to a lack of clear ownership.