Note that the diagram of a Mutex is not how a Mutex works today, at least on reasonable platforms.
First, Mara changed it to be something much less silly, on Linux and similar it's a Futex, while on Windows it was an SRWLock. However, more recently (last year IIRC) the Windows Mutex is also basically a Futex, albeit Microsoft doesn't call their analogous feature a Futex.
In either case this futex-based design means there's no "inner" pointer, and nothing for it to point to, instead there's some sort of atomic integer type, when we're contended we go to sleep waiting on the integer via futex or similar OS feature.
Edited to add:: Also, the niche trick in the bottom right is somewhat broader than this suggests. If the type doesn't need every bit pattern then Rust might and in some cases is guaranteed to see a niche it can use for this memory optimisation.
Option<&T> is the same size as &T but also Option<NonZeroU16> is the same size as u16, Option<OwnedFd> is the same size as OwnedFd (and thus same size as a C integer by definition), Option<Ordering> is the same size as the Ordering (either of them) and Option<bool> is of course the same size as a bool.
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.
If it had no or few comments, the dupe won't be treated as a dupe after some period of time. Then your submission probably ended up in the second chance pool and we get this situation. It happens pretty often.
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.
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.
Only if Rust did not have so much symbol soup... :/ It is a bit too much for me, personally. If you are accustomed to it, it is probably not a big deal for you anymore, but for someone who does not know Rust as well, it could be a deal-breaker, which is why I would still rather prefer reference implementations in C, not Rust. Do not hide things from me!
To be honest the few rust formatting options are easier to remember and more logical than the printf placeholders, e.g. ? for debugging, x for hex, X for upper case hex etc.
I like it, looks cool on desktop, but a mobile view would be cool to have as well. Having to scroll from left to right is a little awkward. Just as a side note
Nothing to do with the content, but not sure there's not reason - it seems a lot of responsive websites are low density and poorly formatted on desktop just so it is mobile-first. Just based on observations, doesn't seem like it's little effort for most people.
Blogs sure. This is a reference. Seems silly to potentially compromise the UI for its primary purpose just so random people from HN can better read it from the toilet.
Is it a reference? It doesn't look like something anyone would consistently be reaching for. It looks more like a fun visualization of some core concepts, something you would show people as a cool thing you made.
Even if it was a reference, the same criticism about left-right scrolling would still apply, at least if you're using the combination of resolution and DPI that people like me do. In fact, if it's meant to be a reference, then it's even more important to make it ergonomic.
Is it just me, or does this seem a surprisingly bad teaching aid? I mean, it's correct and concise, but it almost distracts from the things that actually matter. I feel if I was learning Rust again this would've been almost useless, if not actually demotivating (because of how much complexity it shoves in your face all at once).
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 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
> not useful for teaching at all ... _It pretty much only is relevant if you write the compiler or the standard library for rust_.
This seems a little hyperbolic.
> isn't really that useful for know what the "core" of rust is
In the same way it isn't useful for python developers to know what the stack and heap are, maybe.
> conflicts with the term of lib-core
I don't know what group of people might see this and get it confused with lib-core. Most people looking at this will never encounter lib-core directly, the rest are unlikely to look at this and think it has anything to do with lib-core.
> 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"
first class syntax makes them pretty special IMHO
> there really is little use for the overview outside of a curiosity
I think its a great way to get a high level view of the Types/Traits provided by Rust.
But what the author really mixes up is that lang item is in now way the same as "a core part of rust".
lang item is only a way to tag things to be special known to the compiler, which sometimes is related to implementation details of the compiler which have little to do with the language design
which also means the following statement
> The purpose is to demystify what can be built purely in library code.
is not fully right.
E.g. at least all of Ordering, Option, Result, Clone can be build just fine in library, the lang item is mainly there for optimization hints (and in case of Option FFI layout reasons), but it's an implementation detail which doesn't really needs them to be lang items it was just more convenient to do so when implementing the compiler. A compiler could just give similar properties to anything which "looks like" them. There are subtle fiddly reasons why you maybe don't want to do that for now but technically an implementation detail anyway.
And lot of the things which technically can be implemented in a library (e.g. Display) practically kinda can't, as this would cause major interoperability issues.
Oh also some special macros you can't implement in a library are missing, but that just seems like a minor oversight of the otherwise quite complete list.
But most importantly this is not the conceptual core of the language (but a overlap with it) which would include stuff which has no need to be lang tagged but is a fundamental core design aspect of rust (e.g. Waker for async rust).
For a technical aspect of what needs special handling Ordering, Result and some other parts do not, it's just conveniently makes certain things mostly related to optimizations easier to implement.
From a high level POV especially in context of teaching rust it contains too many low level parts for niche extension functionality (e.g. panic stuff, termination trait) or too advanced to belong in a high level overview IMHO. And misses a lot of things you would include in a teaching the core of rust for people which learn rust overview.
I mean without question the author put a lot of work into it and it's not useless, but IMHO badly named as a listing of lang items just isn't exactly core of rust language design, or core of how you use it.
It it an important listing for changing the rust compiler or writing your own lib-core, tho.
But that means the the thing its effectively most useful for is an advanced topic, so I wouldn't use it for teaching rust. Too many parts which are core of teaching rust missing (e.g. Debug) while exposing students to too many advanced topics in a way where they look as relevant as relevant parts.
> 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.
Right, I also have some chemistry knowledge, so maybe that's why this felt off (form over function?) to me.
There's a reason labs continue to have the modern periodic table on their wall even though they have Wikipedia in their pockets, and it's not just because they get freebies from lab equipment vendors :).
Makes me think of another Rust visualisation of the memory layouts, that I find amazing: https://johnbsmith.github.io/Informatik/Rust/Dateien/Rust-co...
Especially helpful if you come from C / C++
That's a nice one, hadn't seen it before for some reason
Note that the diagram of a Mutex is not how a Mutex works today, at least on reasonable platforms.
First, Mara changed it to be something much less silly, on Linux and similar it's a Futex, while on Windows it was an SRWLock. However, more recently (last year IIRC) the Windows Mutex is also basically a Futex, albeit Microsoft doesn't call their analogous feature a Futex.
In either case this futex-based design means there's no "inner" pointer, and nothing for it to point to, instead there's some sort of atomic integer type, when we're contended we go to sleep waiting on the integer via futex or similar OS feature.
Edited to add:: Also, the niche trick in the bottom right is somewhat broader than this suggests. If the type doesn't need every bit pattern then Rust might and in some cases is guaranteed to see a niche it can use for this memory optimisation.
Option<&T> is the same size as &T but also Option<NonZeroU16> is the same size as u16, Option<OwnedFd> is the same size as OwnedFd (and thus same size as a C integer by definition), Option<Ordering> is the same size as the Ordering (either of them) and Option<bool> is of course the same size as a bool.
Was on the front page under 24h ago: https://news.ycombinator.com/item?id=45167401
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.
I'm happy it was posted again because I missed the previous post and I happen to need this cheatsheet right now.
If it had no or few comments, the dupe won't be treated as a dupe after some period of time. Then your submission probably ended up in the second chance pool and we get this situation. It happens pretty often.
I love a page that doesn't react to my browser width.
How this is structured reminds me of the periodic table.
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.
That is nice. I absorbed a lot of understandable info in a very short time since I am familiar with some other statically typed languages.
Reminds me of https://cosmic.mearie.org/2014/01/periodic-table-of-rust-typ.... Link not available to me, WBM has it https://web.archive.org/web/20240706045446/http://cosmic.mea....
I feel like I need a guide for the guide
Does Rust not have built in Traits for string representations (like Show) or json representations of data?
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.
Only if Rust did not have so much symbol soup... :/ It is a bit too much for me, personally. If you are accustomed to it, it is probably not a big deal for you anymore, but for someone who does not know Rust as well, it could be a deal-breaker, which is why I would still rather prefer reference implementations in C, not Rust. Do not hide things from me!
To be honest the few rust formatting options are easier to remember and more logical than the printf placeholders, e.g. ? for debugging, x for hex, X for upper case hex etc.
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
Someone mentioned a syntactic sugar for stuff like "let mut iter = a.into_iter();" (into_iter() bit) and the like, may I get reminded of them again?
I like it, looks cool on desktop, but a mobile view would be cool to have as well. Having to scroll from left to right is a little awkward. Just as a side note
I agree. With a 1920-pixel wide monitor, I have to scroll horizontally to see everything.
It looks like about 2110 pixels is the minimum window width at which the horizontal scroll disappears.
Ctrl-- (browser zoom down to 80%)
Why would I do that if there is stuff like CSS where the dev responsible for the implementation could've built it responsive from the start.
Ironically this does not surprise me on a Rust based website.
1280x1024, I have to scroll horizontally as well and it is quite annoying. It works at zoom level 50%, but the font is a bit too small, then. :P
For all the rust programming you do on your phone?
There's absolutely no reason to not make a website responsive. Its even expected considering how little effort it takes.
It would slightly defeat the point of arranging it the way it is.
But I also don't think the arrangement is that useful.
Nothing to do with the content, but not sure there's not reason - it seems a lot of responsive websites are low density and poorly formatted on desktop just so it is mobile-first. Just based on observations, doesn't seem like it's little effort for most people.
I occasionally read about programming when I'm not programming. Some of that reading happens on my phone.
Blogs sure. This is a reference. Seems silly to potentially compromise the UI for its primary purpose just so random people from HN can better read it from the toilet.
Is it a reference? It doesn't look like something anyone would consistently be reaching for. It looks more like a fun visualization of some core concepts, something you would show people as a cool thing you made.
Even if it was a reference, the same criticism about left-right scrolling would still apply, at least if you're using the combination of resolution and DPI that people like me do. In fact, if it's meant to be a reference, then it's even more important to make it ergonomic.
Is it just me, or does this seem a surprisingly bad teaching aid? I mean, it's correct and concise, but it almost distracts from the things that actually matter. I feel if I was learning Rust again this would've been almost useless, if not actually demotivating (because of how much complexity it shoves in your face all at once).
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.
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
> not useful for teaching at all ... _It pretty much only is relevant if you write the compiler or the standard library for rust_.
This seems a little hyperbolic.
> isn't really that useful for know what the "core" of rust is
In the same way it isn't useful for python developers to know what the stack and heap are, maybe.
> conflicts with the term of lib-core
I don't know what group of people might see this and get it confused with lib-core. Most people looking at this will never encounter lib-core directly, the rest are unlikely to look at this and think it has anything to do with lib-core.
> 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"
first class syntax makes them pretty special IMHO
> there really is little use for the overview outside of a curiosity
I think its a great way to get a high level view of the Types/Traits provided by Rust.
But what the author really mixes up is that lang item is in now way the same as "a core part of rust".
lang item is only a way to tag things to be special known to the compiler, which sometimes is related to implementation details of the compiler which have little to do with the language design
which also means the following statement
> The purpose is to demystify what can be built purely in library code.
is not fully right.
E.g. at least all of Ordering, Option, Result, Clone can be build just fine in library, the lang item is mainly there for optimization hints (and in case of Option FFI layout reasons), but it's an implementation detail which doesn't really needs them to be lang items it was just more convenient to do so when implementing the compiler. A compiler could just give similar properties to anything which "looks like" them. There are subtle fiddly reasons why you maybe don't want to do that for now but technically an implementation detail anyway.
And lot of the things which technically can be implemented in a library (e.g. Display) practically kinda can't, as this would cause major interoperability issues.
Oh also some special macros you can't implement in a library are missing, but that just seems like a minor oversight of the otherwise quite complete list.
But most importantly this is not the conceptual core of the language (but a overlap with it) which would include stuff which has no need to be lang tagged but is a fundamental core design aspect of rust (e.g. Waker for async rust).
For a technical aspect of what needs special handling Ordering, Result and some other parts do not, it's just conveniently makes certain things mostly related to optimizations easier to implement.
From a high level POV especially in context of teaching rust it contains too many low level parts for niche extension functionality (e.g. panic stuff, termination trait) or too advanced to belong in a high level overview IMHO. And misses a lot of things you would include in a teaching the core of rust for people which learn rust overview.
I mean without question the author put a lot of work into it and it's not useless, but IMHO badly named as a listing of lang items just isn't exactly core of rust language design, or core of how you use it.
It it an important listing for changing the rust compiler or writing your own lib-core, tho.
But that means the the thing its effectively most useful for is an advanced topic, so I wouldn't use it for teaching rust. Too many parts which are core of teaching rust missing (e.g. Debug) while exposing students to too many advanced topics in a way where they look as relevant as relevant parts.
> 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.
Right, I also have some chemistry knowledge, so maybe that's why this felt off (form over function?) to me.
There's a reason labs continue to have the modern periodic table on their wall even though they have Wikipedia in their pockets, and it's not just because they get freebies from lab equipment vendors :).