@@Cookiekeks I have! I watch most of his videos. The rust content feels a little fluffy though. But that's just stylistic and a lot of people probably really like it
Basically, [u8] + "I promise this slice of bytes is a valid utf8 string" = str Vec + "...(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 derefs into &[u8] via the Deref trait and &String derefs into &str via the Deref trait too.
Yeah, and don't forget: The length of the u8 slice is not neccessarily equal to the length of the string, as a unicode character in UTF8 may span more than one byte. Correct?
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 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. ;)
Nice, yeah actually the first time I did green screen it happened to serendipitously turn out this way, ever since then it's been deliberate. Good point about the monitor being higher, that makes sense! I'll likely be building out a little studio soon, so I'll definitely incorporate that...
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
"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
In this example, [1,2,3] is a literal and thus is included in the program executable, and I believe is loaded into memory alongside the machine code instructions for the program, so that's what the pointer points to. This is a little confusing - In this particular example we know the size of [1,2,3], and we could assign it to an array which carries a known size at compile time - similar to what we are doing on line 5. But because we are assigning it to a variable of a slice type on line 6, and the size of slices isn't known at compile time, we get a compiler error. Hopefully that makes sense :)
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.
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.
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.
@@codetothemoon My confusion, I believe, stems from mostly seeing Vec used in the book. I am also confused why `let a [i32] = [1,2,3];` would give an error. This seems exactly like the sort of case that the rust compiler would be able to figure out, similar to how `let x = 3;` works fine, since the compiler sees that 3 is i32 (assumed) and goes along with it happily.
The short answer is that Rc is for when the data needs to be referenced from multiple places and should be cleaned up when nothing references it anymore, and Box is for when it only needs one owner and should be cleaned up when that one owner goes out of scope. For more info check out my video called "Rust's Alien Data Types" - we cover them more thoroughly there!
Usually your videos are very clear, this one for me was a little hurried and convoluted also this one lacked the explanation about which type one should use when designing APIs so that its easier for everyone to call. I know this I just hope this video also covered that so anyone stumbling on this video for rust strings is aware. Overall great content, i love watching your videos even if they are on topics i already understand. Video Suggestion: Actix Actor Framework
Abishek - thanks, this is great feedback, exactly the sort of thing I was looking for. When I saw the final edit I definitely wished I had gone into a bit more detail on some of the topics. Will incorporate these learnings into future videos! Re: Actix actor framework, good idea, I've added it to the video idea list!
I think this is going to be the best Rust channel on RUclips. Your offerings are very crisp and concise with a good base. You are such a good chef.
Wow thanks Aqdas! I appreciate the kind words!
Second to this. I watch them all and this is the most clear channel I've found so far. High quality as well
@@jrmoulton have you watched no boilerplate?
@@Cookiekeks I have! I watch most of his videos. The rust content feels a little fluffy though. But that's just stylistic and a lot of people probably really like it
Basically,
[u8] + "I promise this slice of bytes is a valid utf8 string" = str
Vec + "...(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 derefs into &[u8] via the Deref trait
and &String derefs into &str via the Deref trait too.
Yeah, and don't forget: The length of the u8 slice is not neccessarily equal to the length of the string, as a unicode character in UTF8 may span more than one byte. Correct?
Sounds right to me!
@@kiffeeify Depends what you meant by "the length of the string" as almost all str funcions (e.g. len()) operate on bytes.
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.
Re: drawing diagrams to help retain things better - I'm exactly the same way. But for some reason I don't do it as often as I should.
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. ;)
Nice, yeah actually the first time I did green screen it happened to serendipitously turn out this way, ever since then it's been deliberate. Good point about the monitor being higher, that makes sense! I'll likely be building out a little studio soon, so I'll definitely incorporate that...
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,...
Thanks Erik! I should wish I could! So little time, so many cool technologies to explore...
Thanks, that pretty much cleared it up for me
nice, happy you found it valuable!
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
thank you and thanks for the feedback!
finally found thanks to the author
Nice!
"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
In this example, [1,2,3] is a literal and thus is included in the program executable, and I believe is loaded into memory alongside the machine code instructions for the program, so that's what the pointer points to.
This is a little confusing - In this particular example we know the size of [1,2,3], and we could assign it to an array which carries a known size at compile time - similar to what we are doing on line 5. But because we are assigning it to a variable of a slice type on line 6, and the size of slices isn't known at compile time, we get a compiler error. Hopefully that makes sense :)
@@codetothemoon Thanks!
That was both extremely helpful and extremely frustrating. Rust is weird. One day it'll sink in.
Absolutely interesting
glad you liked it!
Which theme are you using? Awesome video btw.
Dark+! and thank you!
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.
Good point, yeah I'm not sure if .as_str() is equivalent to just using & either. I find auto coercion using the Deref trait pretty handy in general...
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.
im hungry now
right?? I find it very difficult to talk about slices without having an image like the one in the thumbnail pop into my head...
Are you using Producer edition?? What do y'all recomnd if I want to make s but not record my voice or tutorial?
Producer edition of what? I think the answer is no because I'm not sure what that is :)
Tell soft soft I love what they did with the $15 doallors one %
🔥
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.
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.
I am so confused after watching this, which is good. I guess I really didn't understand str and String before.
sorry about that! I've gotten quite a bit of feedback that this isn't the clearest explanation I've done. What part did you get stuck on?
@@codetothemoon
My confusion, I believe, stems from mostly seeing Vec used in the book.
I am also confused why `let a [i32] = [1,2,3];` would give an error. This seems exactly like the sort of case that the rust compiler would be able to figure out, similar to how `let x = 3;` works fine, since the compiler sees that 3 is i32 (assumed) and goes along with it happily.
What is the difference between Rc and Box?
The short answer is that Rc is for when the data needs to be referenced from multiple places and should be cleaned up when nothing references it anymore, and Box is for when it only needs one owner and should be cleaned up when that one owner goes out of scope. For more info check out my video called "Rust's Alien Data Types" - we cover them more thoroughly there!
I wish I could type that fast
All you need is a screen recording program, and a video editing program with a fast forward function! Voilà!
I use String for everything because of the limitations of &str.
Yeah I can definitely see the appeal in that approach!
Aweso tutorial but I dont have a snare anywhere on my list. Wtf
snare?
Usually your videos are very clear, this one for me was a little hurried and convoluted also this one lacked the explanation about which type one should use when designing APIs so that its easier for everyone to call. I know this I just hope this video also covered that so anyone stumbling on this video for rust strings is aware.
Overall great content, i love watching your videos even if they are on topics i already understand.
Video Suggestion: Actix Actor Framework
Abishek - thanks, this is great feedback, exactly the sort of thing I was looking for. When I saw the final edit I definitely wished I had gone into a bit more detail on some of the topics. Will incorporate these learnings into future videos!
Re: Actix actor framework, good idea, I've added it to the video idea list!
L struggled to make soft
🔥
i need an soft soft crack how can i get it
I am not an expert in "soft soft" sorry!