Consider avoiding AtomicT recommendation

[SabrinaJewson]

See this discussion for context: rust-lang/rust-clippy#4295

Basically, AtomicT is not just “a fast Mutex<T>”, it has many additional properties such as it not supporting locking and it accepting Ordering parameters. It is often harmful to recommend AtomicT as a direct replacement for Mutex<T>, because people can easily make assumptions about how they behave that turn out to not be correct, since their actual behaviour is quite subtle (even just with SeqCst, the model of a Mutex<T> is far simpler as it allows arbitrary mutation while in the “locked” state). I see AtomicT as beïng a very low-level primitive for implementing concurrent data structures; it’s mostly too complex for high-level code. Generally, if someone understands Rust well enough to correctly know how to use atomics, they would not need this chart in the first place.

[yugaego]

Even though it can be arguable, I find it useful that the cheat sheet includes many memory containers (smart pointers, wrapper types).

The introductory materials / books on Rust that I have met so far fail to provide a coherent mental model on, so to speak, memory management tools of the language. But that could be useful for a newbie to be exposed to such a mental model from the beginning, not after months or years of studying the language.

This cheat sheet is an excellent attempt to fill this gap. So I'd rather argue for updating, extending, and refining it, rather than removing types present in the language from it.

If someone ever commits to such a task, the only other existing attempts I'm aware of can be found in:

1. The Reddit thread with the pre-release version of this cheat sheet (and two other schemes).
2. Rust in Action book. See section 6.2.2 Rust’s pointer ecosystem.

Two more partially related resources on building a correct mental model of the ownership:

1. Parent blog post.
2. Related Reddit discussion.

Aside, for those interested in what Atomics are about:

1. There's a whole chapter with practical examples devoted to the topic in the Rust Atomics and Locks book.
2. This Reddit thread provides more insight into use cases and low-level operations.

[SabrinaJewson]

Even though it can be arguable, I find it useful that the cheat sheet includes many memory containers (smart pointers, wrapper types).

Atomics are not memory containers. AtomicT is the facility that Rust provides when programmers want atomics – there are few cases when a programmer wants atomics but doesn’t know they want atomics, and in those cases, it’s basically always fine to use a mutex instead.

The introductory materials / books on Rust that I have met so far fail to provide a coherent mental model on, so to speak, memory management tools of the language. But that could be useful for a newbie to be exposed to such a mental model from the beginning, not after months or years of studying the language.

Atomics should not be part of this mental model. If a Rust programmer never uses atomics in their lifetime, they will almost surely not be worse off for it, unless they’re implementing low-level synchronization primitives in which case they’ll know about atomics already. This is not information that is important to teach beginners, but can be actively harmful.

Two more partially related resources on building a correct mental model of the ownership:

I’m really confused. Ownership has nothing to do with atomics.

[yugaego]

Atomics are not memory containers.

Do you agree they could be called wrapper type? (This term was used in the quoted text.)

Atomics should not be part of this mental model.

It's clear this is the statement you stick to. I've presented a different point of view for consideration by any future reader and for the sake of the issue discussion.

I’m really confused.

The quoted "partially related resources" are supplementary ones. They refer a potentially interested reader to additional materials on building a correct mental model of Rust.

[SabrinaJewson]

Do you agree they could be called wrapper type?

I mean, depends on context: when listing all the interior mutable containers, sure, when listing data structures, no, since data structures are expected to be generic.