A clickable visual guide to the Rust type system

That's a nice one, hadn't seen it before for some reason

OP here - yes, something didn't work with dup detection?, this one was submited days ago, before then one you linked and both ended up on the front page. Certainly not intentional.

Yeah, except this one is much more arbitrary in its choice of groupings and arrangement. Why is the boolean and Unicode scalar type in the same column as floating-point types? Why is the ! type not next to enums if () is next to tuples? (Both are neutral elements of their respective type-formation operations.) How is Sized to Drop as Copy is to Clone? You can go on and on. If you take the "periodic table" framing seriously, you can see some actual correspondences on display (like between plain operators and compound assignment operators), but they drown in a sea of spurious ones.

It's like infographics. Pretty visuals, but little to no insight.

Given the title "Elements of Rust", I suspect that is very much intentional.

it has Display and Debug trait

both require a `fn fmt(&self, f: &mut Formatter<'_>) -> Result<(), Error>` function

while they work the same semantically it's "convert to string for displaying" and convert to string for debugging" (where debugging could be log messages, or print line debugging etc. by default debug for strings will do string escaping and for structs does print the structure/fields/type name in some semi standard way).

the Formatter is mostly just a string writer/sink, which also exposes a fixed set of formatting options and some utility methods

if a type implements Display through stuff I will skip over you then can also write `instance_of_type.to_string()` and get a string.

This trait are used in the default formatting mechanism used by e.g. `println!()` which other libraries (e.g. log) can use through `format!` and some other more internal/95% of case you don't need to know stuff. E.g. `println!("{a}, {a:?}, {a:#?}")` will in order print the display formatting of a, the debug formatting of a and then the alternative debug formatting (if there is one, else the normal one). And other options like pad left, floating point format options etc. exist too.

Through it should be noted that rust doesn't contain build in serialization, through nearly everything uses the library/traits/types from `serde` for that.

String representations are obtained with the Display trait, which automatically results in an implementation of to_string() as well.

Those are in (widely used) packages like serde

I agree. With a 1920-pixel wide monitor, I have to scroll horizontally to see everything.

For all the rust programming you do on your phone?

yes

the main issue here is that it's basically a list of thing which are "lang_item"s, i.e. have a `#[lang = ...]` attribute or are build in `&/&mut/str/[T]` etc. (but then for some reasons lists combinations of them!?). But `#[lang]` is mainly there to map types to some compiler special casing which might be as trivial as a optimization hint...

and the thing with that is it's

- not useful for teaching *at all* as it's not representing the semantic/logical building blogs, or what "core" means in rust terms or what you have to learn when learning the language or anything. _It pretty much only is relevant if you write the compiler or the standard library for rust_.

- isn't really that useful for know what the "core" of rust is (as many of this items only have a lang tag to make sure some "special case" optimizations, compiler messages, etc. map correctly, and at least in the past you also didn't really have to have all lang items to use rust in a _very_ cut down way)

- conflicts with the term of lib-core (which is a very cut down version of lib-std for embedding use-cases where you e.g. might not have alloc, but you can even write rust without lib-core)

E.g. `Termination` isn't a "core" rust feature, it's a nice customization hook which main exist so that you can have all of `!, (), ExitCode, Result<T,E>` as return types of main, which is mostly irrelevant outside of some QoL edge cases. In general you don't need to know about it and in 99% of cases you shouldn't implement it either.

E.g. Deref,DerefMut, Index, IndexMut, the various Range types, the various operator aren't really special in any way except "hey they have first class syntax" and thats it, the #[lang] tag just tell the compiler "if you find += map it to AddAsing::add_assign".

E.g. the lang tag on `Ordering` is basically a optimization hint AFIK.

etc. etc.

there really is little use for the overview outside of a curiosity and calling it the "core elements" of rust is really just very very misleading

> It reminds me of one of the ways of visually laying out elementary particles according to the Standard Model. And now I wonder how much that representation is also actually detrimental to its use as a teaching aid.

The Periodic Table does seem like the inspiration. The crucial difference being that the Periodic Table has that shape for a reason. Take the first column of this page for example: u8, i8, bool. Ok, probably 8 bits big so good so far, but then that SAME ROW also has fn(T...) -> U, const T, mut T. Only two of which are related in any way with eachother, let alone the 8 bits column which is 100% not the same thing.

Contrast to the Periodic Table where the first row has H and He which both only use the base electron shell. H is to the left because it has (when neutral) 1/2 electrons in it's shell and He to the right because it has 2/2. Then going down from He are all the nobel gases which all have full electron shells.

Going down on the right most side of this page has just a bunch of random stuff.

Anyway, the reason people try to draw things like the Periodic Table is because it's super good, but the people who do it think it's good marketing, not based on physics/chemistry, missing the entire point.