Great content, thank you! It would be much easier to follow with the terminal to the right side. When the terminal appears from the bottom, it obscures most of the code and it not clear which code is responsible for printing. Example 5:51
Basically, [u8] + "I promise this slice of bytes is a valid utf8 string" = str Vec<u8> + "...(same as above)..." = String Since we don't usually use [u8] without & or &mut, we also don't usually use str without & and &mut. Also, &Vec<u8> derefs into &[u8] via the Deref trait and &String derefs into &str via the Deref trait too.
I like the way that you've got your monitor high and to your right, so that when you're typing, it almost looks like you can see the code as we see it in the composite image. I'd think about moving your monitor a little higher, to emphasise this a bit more. I don't know if anyone else would ever notice but I WOULD. ;)
Thanks. I've thought about this several times in the past and always lost the gist of it after a while. I found drawing out the memory structures and pointers, to get a proper understanding, helps me retain stuff better. Diagrams are also great for lifetimes. Back in the 80s, I didn't have any trouble learning C and C++, I suppose it's being retired and older.
I can strongly recommend this channel to anybody who's studying rust. The example is concise and easy to understand! Thanks!
you should do video for every coding language, and every framework,... your explanations are amazing,...
finally found thanks to the author
That was both extremely helpful and extremely frustrating. Rust is weird. One day it'll sink in.
Thanks, that pretty much cleared it up for me
Absolutely interesting
Tell soft soft I love what they did with the $15 doallors one %
Another reason for &String is that if you have an owned but the methods takes a slice, you can just throw the ref on there it will auto-convert it to &str - just shorter than .as_str() on it (which I'm not sure if as_str() is a compiler trick under the hood or if that's actually runtime method call (as it appears), but the & in front of String would (I believe) be all compile time, so it could possibly be faster too. Maybe worth a 1M call loop test to check if any performance diff.
1:27, line 6. How are we able to borrow the array [1,2,3]? Who owns it? I thought everything that can be borrowed must have an owner.
I am so confused after watching this, which is good. I guess I really didn't understand str and String before.
1:27 Isn't the value actually a reference to an array instead of a reference to a slice, and it only coerces to a reference to a slice because of the explicit type annotation? Edit: Same for the subsequent `slc_smart` declaration. It only ends up a boxed slice because of the explicit type annotation, since the value is a boxed array.
"A borrowed reference take a known amount of memory as it is ultimately a pointer.' But where does the 'thing' that it's pointing to exist? i.e [1,2,3]. I don't quite see how the size of [1,2,3] is not known statically and yet &[1,2,3] is. Is the size of [1,2,3] encoded in the pointer? (But if it is then it must(?) have been determined at compile time.) Could you explain a bit more please? Thanks
Correct me if I’m wrong but the slc2 where you said it doesn’t make a copy, that’s wrong. Integers implement the copy trait so any reference to an integer makes a copy hence why you don’t need the .copy() method on borrowed integers.
Which theme are you using? Awesome video btw.
I wish I could type that fast
@aqdasak