@@brinblasco9037 for those who writes in similar low level languages, there are plenty of dead giveaways...i agree it's better for this channel to focus with Python. There are other channels who have mastered Rust and therefore much less misleading concepts (hint: read other comments here who have some experience with Rust..)
10:50 - string literal like "true" is actually stored in the read-only data segment of the executable. In the stack, value of 'a' is a fat pointer (pointer + length) to this read-only data segment.
Hey Tim, I can't say my thanks enough for you. You are the person that inspires me to start my coding channel. Because of your channel, I was able to jumpstart my coding experience and learn more on my own. If anyone is reading this comment and is starting out on their coding journey, I highly recommend Tim and Sentdex for their amazing projects. It's because of people like Tim that motivates me to learn other languages besides Java, which is being taught in my school (and very poorly taught). Anyway, Tim, keep up the amazing work and I can't wait to see how far you'll go with this Rust tutorial! ❤️
This rust series is amazing, thank you very much, can't wait for the next episodes! I've just turned a member of the channel to support you with that ❤️
Thanks, I am beginner to medium Java developer and i wanted to learn something more low level. I am happy i found you. I cant hold and I am learning other things because I cant wait for another video, but these fundamentals are super interesting and i wouldnt probably learn them in this stage by my own study. Again, thank you for this.
Also the heap isn’t that much slower after you have obtained the pointer to the starting memory page. You still need to dereference an address but the same goes for the stack pointer that you need to count back from the current point to the right variable that’s actually an extra indirect addressing function whereas the heap it’s optimized so that the pointer is already in a register “load effect address” and the data is also obtained using indirect addressing with offset. So in use it’s pretty similar in speed on some systems even identical because they don’t have shorter opcodes for best by addresses. But yeah, the allocation and freeing is where the performance pain is. And in some cases also the fact that the data is too large or randomly accessed to fit in level 2 cache.
I hope you continue this series. I like most of your videos, and a few years ago, your 6-hour, no-ads Python beginners course rekindled my interest in writing software after around 30 years away from it. This set, as interesting and helpful as it definitely was, felt like it just abruptly ended. Just like . . . we're done! Thanks for the lessons you posted, and I hope you decide to post more.
You forgot that before a and b there’s the return pointer from where example() was called. And ofcourse there’d no name associated in the stack, the arguments are derived from their size. And the values aren’t removed from the stack, the stack frame pointer is subtracted. The stack is never cleared that’s why it’s so fast, it’s just a stack pointer register that’s subtracted from.
Thank you for that. I don't know much about rust but have used C for a long time. I expect in a compiled language variable names are not retained in the compiled code. For C the compiler maintains a name table that associates names with addresses and/or address offsets. The compiled code only uses the addresses and offsets and knows nothing of the variable names in the source code. From this perspective I see the explanations given in this video as overly simplistic and misleading. I'm going to unsubscribe and look for a more realistic series.
I'm glad that I've stumbled across this series, it was simple and straightforward. I didn't think that Rust can be learnt this easily. Deserves a subscribe!
Tim, have you given up on this playlist? I know you've got a lot of irons in the fire, but you did the first nine of these in one month and now it's been over two months since the last.
From my old days with c, everything on the stack is referenced via a stack pointer. So when data goes out of scope, they aren't really deleted.. the stack pointer is just decremented.
Also, the stack are actually multiple stacks, one for each process. This is one of the reasons you cannot have data there that can dynamically grow. It might overwrite other stacks.
15:50 The string literal isn't stored on the stack either. It will be placed into the read-only section of the binary. We only get a &str reference to the string literal. Generally it is not possible to store str on the stack as str is not sized. We always need some kind of pointer such as a reference &, a Box, Rc, Arc, and so on.
Okay, that's a bit weird. Stacks normally grow up, not down. It's called a stack because it stacks up from higher address (aka bottom of memory) to lower addresses.
This is very helpful, but I REALLY wish you would have started with the stack address as 43210 and put everything on the bottom first then stack it as they are added like you were trying to explain but for some reason you illustrated it upside down.
At 10:40 when example() function is called, a return address will be pushed on the stack, but the string "true" will not. Why not use a debugger and step through the program instructions one by one and watch what happens on the stack, heap, registers etc? That would be a super video to make!
Thanks for the video! I'm missing one thing - if the stack always "cleans itself" starting from the top, what happens to unused variables deeper into the stack? Does the program always have to wait for the last function to stop running before it can start cleaning the stack? To illustrate this - let's say we have a program that has hundreds of variables, each of which will take one place in the stack. We've done whatever we needed with them, but we still have one variable at the bottom that we aren't finished with. Then, we use that last variable in a loop that will take, I don't know, 2 minutes (the point is it's a calculation heavy process). All those variables that came before it are still stuck in the stack and continue taking place in memory. Does something like this often happen in practice? Is it a common way to make a badly optimized program that uses too much RAM? Obviously hundreds of variables with constant values will probably not do anything to modern computers, but you get the point. I'm guessing that a language would give us a way to force-clean up the stack before we decided to run that loop?
This is a good question that confused me and a few other people i know when i started programming. In moat languages you can think of a stack as the space between { in here } brackets. Not every program uses them but most do. If you declare a variable there it is tied to that stack. If you start creating stacks inside stacks { var A { var B } } Then both values A and B live the exact same time. However since we are not using A in B's scope and we aren't using A after B's scope theoretical the compiler can change the scope to this. {Var A } { var B} Meaning we never have A and B taking up more memory then it needs to be. However there is more to the answer that may make it more complicated. In theory you want to declare variable only as you need them in the shortest lifetime possible. Hopefully that made sense and answered your question. If you want i can talk a bit more about stack frames and stack pointers if you want.
So, when I redeclare a variable to change it's type like this: let a: i32 = -5; let a: u32 = 7; Is it reasigned in the stack or popped and recreated? And if it is recreated, it may not be the last one on the stack right?
Actually neither! When you redeclare a variable with the same name, you are doing "variable shadowing". Shadowing occurs when you create a new variable with the same name as the previous one, but it's a separate entity with its own storage. Therefore, the first "a" variable is allocated on the stack and when declaring the second "a" variable, it's also allocated on the stack, they both will exist until the end of the scope, but the first "a" variable is inaccessible because of the shadowing.
He confused fixed-size with fixed-value. "let x = 2" is both fixed-size(i32) and fixed-value => stored on the stack, but also... "let mut x = 2; x = 3" is still the same size(i32) => still stored on the stack. Quoting from the book "All data stored on the stack must have a known, fixed size. Data with an unknown size at compile time or a size that might change must be stored on the heap instead."
Год назад
I would like to see the heap and stack memory in real time on my debug session. Do you know a tool?
Hi Tim, just want to ask, will you describe concept of code management for rust? I'm from Java developer, trying rust, but couldn't figure how we will separate codes and package?
I wonder if Rust uses something similar to C++ short string optimization, in which case, everything you said about the string is wrong just because it is a short string.
Tim please continue this series, PLEASE?!!
Will this series be continued? I'd love to see more of these, great videos!
Saidly series look dead too me😢
@@akash-kumar737 seriously, it's for the better
@@brinblasco9037 for those who writes in similar low level languages, there are plenty of dead giveaways...i agree it's better for this channel to focus with Python. There are other channels who have mastered Rust and therefore much less misleading concepts (hint: read other comments here who have some experience with Rust..)
@@kazuhah1743 Why?
Still waiting on Rust Tutorial #10 - Ownership
Same here
Bro really left us hanging at the toughest part 😂
this video released 1 year ago 🥲
2024 and still waiting..
Just read the Rust Book
Please continue the series Tim, I love rust and it is a huge language. I hope you cover mos of the things in it
10:50 - string literal like "true" is actually stored in the read-only data segment of the executable. In the stack, value of 'a' is a fat pointer (pointer + length) to this read-only data segment.
This needs more attention / likes
So, yeah, I'm addicted to this series now. Need more.
Hey Tim, I can't say my thanks enough for you. You are the person that inspires me to start my coding channel. Because of your channel, I was able to jumpstart my coding experience and learn more on my own. If anyone is reading this comment and is starting out on their coding journey, I highly recommend Tim and Sentdex for their amazing projects. It's because of people like Tim that motivates me to learn other languages besides Java, which is being taught in my school (and very poorly taught). Anyway, Tim, keep up the amazing work and I can't wait to see how far you'll go with this Rust tutorial! ❤️
Thank you Tim for these videos!
This was a great introduction to the rust syntax and I hope that you continue the series.
This rust series is amazing, thank you very much, can't wait for the next episodes! I've just turned a member of the channel to support you with that ❤️
Thanks, I am beginner to medium Java developer and i wanted to learn something more low level. I am happy i found you. I cant hold and I am learning other things because I cant wait for another video, but these fundamentals are super interesting and i wouldnt probably learn them in this stage by my own study. Again, thank you for this.
Tim of you read this comment, please continue this series at some point. It's the most comprehensive rust tutorial in YT.
Amazing series! I love that it was aimed at the intermediate programmer. I hope you will continue this!
Hey Tim,
Thanks for these videos.
May you kindly continue the series.
Would love to see this series continued. Thanks for the great introduction to Rust
Tim, continue this series, you explain Ⓡust so well!
Please continue this series. Your videos are a 10/10
Continue with the tutorials, please!
Pls continue this seires, you are a very good teacher!
Another vote for the series to continue. You have a very clear presentation.
Also the heap isn’t that much slower after you have obtained the pointer to the starting memory page.
You still need to dereference an address but the same goes for the stack pointer that you need to count back from the current point to the right variable that’s actually an extra indirect addressing function whereas the heap it’s optimized so that the pointer is already in a register “load effect address” and the data is also obtained using indirect addressing with offset. So in use it’s pretty similar in speed on some systems even identical because they don’t have shorter opcodes for best by addresses.
But yeah, the allocation and freeing is where the performance pain is. And in some cases also the fact that the data is too large or randomly accessed to fit in level 2 cache.
Tim please return with more tutorials. I prefer your videos over the official rust manual and other tutorials.
Man, I hope this series continues 🙏
Legend has it that the next video is still on its way!
I hope you continue this series. I like most of your videos, and a few years ago, your 6-hour, no-ads Python beginners course rekindled my interest in writing software after around 30 years away from it. This set, as interesting and helpful as it definitely was, felt like it just abruptly ended. Just like . . . we're done! Thanks for the lessons you posted, and I hope you decide to post more.
You forgot that before a and b there’s the return pointer from where example() was called. And ofcourse there’d no name associated in the stack, the arguments are derived from their size.
And the values aren’t removed from the stack, the stack frame pointer is subtracted. The stack is never cleared that’s why it’s so fast, it’s just a stack pointer register that’s subtracted from.
Thank you for that. I don't know much about rust but have used C for a long time. I expect in a compiled language variable names are not retained in the compiled code. For C the compiler maintains a name table that associates names with addresses and/or address offsets. The compiled code only uses the addresses and offsets and knows nothing of the variable names in the source code. From this perspective I see the explanations given in this video as overly simplistic and misleading. I'm going to unsubscribe and look for a more realistic series.
Please continue Tim. Your rust videos helping me a lot...
This is a very insightful video. Hope you continue this series.
This series needs to be continued Tim. Please
Thanks Tim, It was very good. Please make more videos about Rust. Good luck 🙏
Would love to see this video series continued!
This video series is awesome, thank you so much for making these videos!
I'm glad that I've stumbled across this series, it was simple and straightforward. I didn't think that Rust can be learnt this easily.
Deserves a subscribe!
The series helped a lot!!! Waiting for next advanced series on rust Tim!!!!
This is a helpful series. Like the others have mentioned, I hope the series continues to #10 and beyond.
The programming language FORTH is a great exercise/example when talking about the stack.
We need part 10!
Please continue the series!!! 🙏🏼
Tim, have you given up on this playlist? I know you've got a lot of irons in the fire, but you did the first nine of these in one month and now it's been over two months since the last.
From my old days with c, everything on the stack is referenced via a stack pointer. So when data goes out of scope, they aren't really deleted.. the stack pointer is just decremented.
Also, the stack are actually multiple stacks, one for each process. This is one of the reasons you cannot have data there that can dynamically grow. It might overwrite other stacks.
Fantastic explanation, looking forward to the next video.
Congratulations on 1 millions
Gotta love the difference between strings and Strings
Continue the series please!
15:50 The string literal isn't stored on the stack either. It will be placed into the read-only section of the binary.
We only get a &str reference to the string literal. Generally it is not possible to store str on the stack as str is not sized. We always need some kind of pointer such as a reference &, a Box, Rc, Arc, and so on.
Bro is teaching us about memory management before for and while loops
Good video as always! Your content is one of the main reasons I started my (still small) Tech RUclips channel myself. Thanks and have a good day!
Thank you very much! your explain is very understandable.
Nice!!! Very nice thanks for explaining memory, this is often brushed by in many tutorials.
Nice work on these!
Okay, that's a bit weird. Stacks normally grow up, not down. It's called a stack because it stacks up from higher address (aka bottom of memory) to lower addresses.
Thanks - like your explanations. Pity you did not continue the series.
Thanks for your Rust videos! Will you break the suspense and continue?
He will probably ignore these comments because he don't care about what we say as long as we are watching his videos. That's fine for him.
I'm guessing that you're done with the Rust series, despite mentions of future videos? The playlist ends at #9
No rust #10?
Thanks for the series anyway! It's so nice to watch your video
Why didn't you continue this series? Your explanation is very intuitive.
Great video, the explanation is very clear, thanks so much.
My lust for Rust is a must as the luster of Rust is a muster for bust.
This is very helpful, but I REALLY wish you would have started with the stack address as 43210 and put everything on the bottom first then stack it as they are added like you were trying to explain but for some reason you illustrated it upside down.
Tim! We're nearing 1 Million subs bro! 🥳🎉🎉
Please countinues this series,
Waiting for continuation 🥺
some people say bro is still learning ownership concepts ...
At 10:40 when example() function is called, a return address will be pushed on the stack, but the string "true" will not. Why not use a debugger and step through the program instructions one by one and watch what happens on the stack, heap, registers etc? That would be a super video to make!
Are you going to continue this? I'm invested now! Lol
Tim can you make more web development tutorials using flask, Django
Love the videos! Too bad there are not more
Thanks for the video! I'm missing one thing - if the stack always "cleans itself" starting from the top, what happens to unused variables deeper into the stack? Does the program always have to wait for the last function to stop running before it can start cleaning the stack?
To illustrate this - let's say we have a program that has hundreds of variables, each of which will take one place in the stack. We've done whatever we needed with them, but we still have one variable at the bottom that we aren't finished with. Then, we use that last variable in a loop that will take, I don't know, 2 minutes (the point is it's a calculation heavy process). All those variables that came before it are still stuck in the stack and continue taking place in memory.
Does something like this often happen in practice? Is it a common way to make a badly optimized program that uses too much RAM? Obviously hundreds of variables with constant values will probably not do anything to modern computers, but you get the point. I'm guessing that a language would give us a way to force-clean up the stack before we decided to run that loop?
This is a good question that confused me and a few other people i know when i started programming.
In moat languages you can think of a stack as the space between { in here } brackets. Not every program uses them but most do.
If you declare a variable there it is tied to that stack. If you start creating stacks inside stacks
{ var A { var B } }
Then both values A and B live the exact same time. However since we are not using A in B's scope and we aren't using A after B's scope theoretical the compiler can change the scope to this.
{Var A } { var B}
Meaning we never have A and B taking up more memory then it needs to be.
However there is more to the answer that may make it more complicated. In theory you want to declare variable only as you need them in the shortest lifetime possible.
Hopefully that made sense and answered your question.
If you want i can talk a bit more about stack frames and stack pointers if you want.
This is a good video!
Hey tim thanks for the video. Also I'm going to check out your programming expert school. Again thanks.
Just got the course. If I have any questions contact you or is there a discord?
非常好视频，爱来自瓷器❤️
Why not use let mut string instead of let string = string::from? Is there a difference between these 2? I believe they are both mutable
So, when I redeclare a variable to change it's type like this:
let a: i32 = -5;
let a: u32 = 7;
Is it reasigned in the stack or popped and recreated? And if it is recreated, it may not be the last one on the stack right?
Actually neither! When you redeclare a variable with the same name, you are doing "variable shadowing". Shadowing occurs when you create a new variable with the same name as the previous one, but it's a separate entity with its own storage. Therefore, the first "a" variable is allocated on the stack and when declaring the second "a" variable, it's also allocated on the stack, they both will exist until the end of the scope, but the first "a" variable is inaccessible because of the shadowing.
He confused fixed-size with fixed-value.
"let x = 2" is both fixed-size(i32) and fixed-value => stored on the stack, but also...
"let mut x = 2; x = 3" is still the same size(i32) => still stored on the stack.
Quoting from the book
"All data stored on the stack must have a known, fixed size. Data with an unknown size at compile time or a size that might change must be stored on the heap instead."
I would like to see the heap and stack memory in real time on my debug session. Do you know a tool?
Is the rust playlist completed (as needed to start rust)
Hi Tim, just want to ask, will you describe concept of code management for rust?
I'm from Java developer, trying rust, but couldn't figure how we will separate codes and package?
I wonder if Rust uses something similar to C++ short string optimization, in which case, everything you said about the string is wrong just because it is a short string.
What is wrong with the subtitles?
Wonderfull!!!
Where is the next video of this series :/?
Why is this playlist dead and no upcoming videos missing the videos man please make some videos
Is this the last vid?
Is this series stopped? :(
Waiting for the next on so muchhhhhhhhhhhhh :(
This gives me C flashbacks
All of Rust is basically C on steroids
will " let mut string = "hello"; " be on the heap????
Hi when will the next video be ready? Thanks in advance
Hey Tim 👋 can I have the name of the app you use for making your vids
Next video? when coming? Tutorial # 10 Ownerships???
when will be the next one? please continue hehe
The red font color seems a little bit less contrast to the background.
Bro is this series finished
Can you please make your own wordle with a tutorial? Thanks.
it looks like the caption file for episode 8 got uploaded for this one
Why everyone skips topic of loops is it really hard or what ? I never used rust. I call myself beginner-1.
After 9 months - Still waiting for #10 - Ownership
Or I guess I need to learn rust from some other youtuber.
where is the next vid???
still waiting rust tutorial-ownership
still waiting for the "ownership" video :(