@@toolb0x_ It's working for me. Might take a minute for the email to arrive. It might also be in your spam folder. If you can't find the email please reach out to me at bogdan@letsgetrusty.com
Great video! Can't wait for the next one in the series. I used to program in C++ when I was kid. I read several books back then but none explained this topic. You just sit down and start programming. I think it should be the first thing that a programmer learns. Even if you don't manage memory manually, like in JS, it's always better to understand how your program works. Recently I read that in embedded systems there is no heap and there is Rust version for such systems. Would be nice if you get even deeper into this subject :). But anyway, keep doing great work! :)
As an embedded software developer I have one another thing to mention about heap memory. It's fragmentation. If you are developing software for aircraft or nuclear power plant you should care about it and probably use only stack and static memory
It's not exactly correct. To be precise, you should prefer stack and static memory by default. One of the huge problems with stack and static memory is that it must be provided by the system (assuming it's being executed in some OS) and it's not always possible to reserve sufficiently large chunk of memory for plenty of reasons. Because of that, sometimes allocation is inevitable but even so indeed it should happen only once. On Linux, the stack size limit is at 8/10Mb depending on the distribution. You can increase the limits but it's a slippery path and a serious question whether you truly need.
Memory management can handle fragmentation. Still good to know the concept for use cases where it might be an issue. No need to refrain from using heap though.
As another embedded developer, I agree. In fact, for custom HW, dynamic memory is absolutely forbidden. If you don't know the size of something, go back to the HW devs and ask the size of the storage/block/register/packet/etc.
A picture is worth a thousand words.. I've seen various memory diagrams for Rust but this is by far the most clear and meaningful I've seen thus far. Thanks much!!
Привіт. Thanks for amazing videos. I'm also a web dev so I really appreciate mainly these videos to get familiar with the low level programming concepts.
Awesome !! I guess rust is really different when u coming from high level programming background and this series really going to help !! Thanks a ton brother !! Cheers from INDIA ... by the way ur rust book playlist is amazing !! Anyone who wants to step into that playlist s the Best .
This is very important information for systems development. When I was working with Assembly and C/C++ it was imperative to understand memory and memory management. With languages like Java and C#, the garbage collector makes it less important to know. Probably why Rust is perceived to have a steep learning curve. Excellent video
Thanks you so much ♥♥♥. Your videos are really helpful and this one I've found it interesting. Didn't know that Heap memory was shared between the all threads. Its like static is the first level, then stack goes up with a limited size of memory that can consume but doesn't mean itll always consume that amount, like a dynamic range. And the heap as the unlimited. So interesting.
Helpful, useful video, great content, really brings understanding of the important concepts of program engineering. Thank you very much for producing high-quality content.
This series is going to be excellent, I can feel it. It's going to benefit developers outside of the Rust community too, which is even better. That being said I do have a very strong objection to the way educators like to graphically represent memory. In my opinion, the classical "stack grows down, heap grows up" diagram is unnecessarily confusing and could potentially be very misleading, so it should no longer be used. First of all, in any modern OS memory allocation is delegated several layers, each with their own management strategies and optimisations, so the diagram is not a physically accurate representation of the actual memory layout (e.g. there's no reason why the stack can't grow "upwards" instead of "downwards", whatever that means; nor is there a reason why stack, heap, and static regions are in that particular order). My past self as a CS student used to struggle to remember where each category of memory belongs and how they grow and shrink, while in fact it was a complete waste of time because it's just an arbitrarily-chosen representation. That being said it would be a useful teaching tool if it abstracts away complexity and aids in understanding. The problem is that it really doesn't. Unless you are a developer of extremely low-level memory management software, all you need is to see stack, heap, and static as three distinct and separate regions. The stack is well, a stack; a heap is basically a do-whatever-you-want sandbox; and static is determined at compile time. Where exactly they each are and what their physical layouts are is frankly none of your business. And I mean that in a good way, because the allocator has taken care of it for you. So why is it that we continue to draw our memory diagrams like that? Maybe because it highlights how memory is finite? But duh, everyone and their dog knows that; plus most programs are never going to run into "out of memory physically" situations these days. So what I propose is simple - draw these memory regions as separate things. The stack - sure it's a stack alright, we can keep the rectangular box. But don't tack on the heap after it - they are not actually "connected" anyway, and drawing them as such serves no purpose but to confuse. So just draw the heap separately, as a circle or something. Then draw the static region as a circle (or whatever shape you prefer) and we're done. Tells the same story but with much less confusion.
It is important to know that the stack does have a direction. Call it what you will, up, down, etc. Stacks are always (AFAIK) last-in-first-out buffers.
Great Video, this is exactly what I was looking for. Your content is the best I've seen when trying to learn Rust. As a byproduct I think its making me a better programmer as well learning these concepts that I didn't "need" to learn in python or JavaScript.
Good video! Thank you for the information! Perhaps more diagrams and pictures would help the understanding and visualization of the concepts in general :) I like Rust bc since I've been studying more in-depth fundamental concepts of CS the things and vocabulary used in rust lang started making more sense: -> The concept of why ownership was implemented makes more sense once one understands memory attacks (buffer overflow, format strings, data leaks....); -> The idea of lifetimes annotation is something often used when the compiler parses the code before compiling it, so it helps a lot the optimization as the code is transformed to lower levels of the architecture; -> Reference Counting is another idea already present in CS literacy before its use in Rust, in distributed systems, when facing naming resolutions, reference counting was a solution to keep track of objects references in the used network. Rust borrowed this solution to memory management security and fast process execution again; Many other advanced ideas were used when the rust started being developed! It's indeed a great language to learn!
I’m still learning so found this a little difficult to understand but I do have a question. When you mentioned the heap not storing a fixed string size due to the program not knowing the size of the user input… Does this mean even with a restriction in place to prevent the users string input size, it will still be stored on the heap? I hope this makes sense. Thanks
Great video thank you. Quick question, using your example of getting a name from the user. You said we don't know how long their name is, so the amount of memory needed to allocate to the variable is unknown at compile time => we have to use heap memory for this. But memory on the stack also has dynamic size, so why can't we just allocate some stack memory instead?
You technically can (although I'm not sure if you can in Rust) but it's not considered the best practice. What you're talking about is "Variable Lenght Arrays" or just in general dynamically-sized stack allocation. In C, you can use the function "alloca" to do this. There are a few reasons it is recommended against e.g. it creates a higher chance of stack overflow errors since you could allocate extremely large buffers. This in turn means you should probably have an upper limit on the size of the buffer, in which case it often makes more sense to just allocate that upper limit on the stack statically in the first place. Hope that helps!
Yasss! Thanks I was waiting for a video like this! It would be awesome if you did a video explaining how are diferent variable types stored in memory for example struts with traits and vectors.
Hmmm,... As an embedded and system Programmer - rather new to Rust - lots of "errors" popped up to me in this video. I do appreciate that these simplification makes a lot of sense when its gets to highlighting the memory management paradigm of Rust vs the "traditional" ways of C++ or Java. But I suppose Rust can be used without a heap for small embedded projects, as I often do with C++ . Or does that not make sense as Rust guarantees that the heap is safe ?
I am wondering.. What does "Coming from a web developer background" mean? How can a web developer not know how memory works? Because he doesn't need any?
Hi there, would you like to make new topics such as introducing some useful crates for writing some projects, or how to read Rust projects from the real world project level. Since I watched all your Rust videos and videos from other channels, I finished the Rust By Examples, and Rustlings (I didn't read the Rust Book and Cargo Book, I know, I know, I should read them). After I read some real project source code I learned a lot in Cargo.toml such as features, and so many useful crates used in the projects.
I'm a competitive programmer and I have to solve some coding questions and that's why I am learning rust but it's very hard for me to get inputs. Like integer Input, create 2d array and take input. How to make graph and all. Kindly help me for programming in rust rather than development only. Please make a good Input video in rust. Thanks
I need to you experience watching your video on a decent size modern quality HDR monitor. Stare into the sun of your white background for 10 minutes. Please... Stop abusing us. :D #DarkMode
📝 Get your *FREE Rust cheat sheet* :
www.letsgetrusty.com/cheatsheet
does not work.. :-/
Can confirm, not working
@@toolb0x_ It's working for me. Might take a minute for the email to arrive. It might also be in your spam folder. If you can't find the email please reach out to me at bogdan@letsgetrusty.com
@@letsgetrusty i have send you an email. looks like others have the same problem..
now it is working! Thanks Bogdan :-)
Great video! Can't wait for the next one in the series. I used to program in C++ when I was kid. I read several books back then but none explained this topic. You just sit down and start programming. I think it should be the first thing that a programmer learns. Even if you don't manage memory manually, like in JS, it's always better to understand how your program works. Recently I read that in embedded systems there is no heap and there is Rust version for such systems. Would be nice if you get even deeper into this subject :). But anyway, keep doing great work! :)
As an embedded software developer I have one another thing to mention about heap memory. It's fragmentation. If you are developing software for aircraft or nuclear power plant you should care about it and probably use only stack and static memory
It's not exactly correct. To be precise, you should prefer stack and static memory by default. One of the huge problems with stack and static memory is that it must be provided by the system (assuming it's being executed in some OS) and it's not always possible to reserve sufficiently large chunk of memory for plenty of reasons. Because of that, sometimes allocation is inevitable but even so indeed it should happen only once.
On Linux, the stack size limit is at 8/10Mb depending on the distribution. You can increase the limits but it's a slippery path and a serious question whether you truly need.
Memory management can handle fragmentation. Still good to know the concept for use cases where it might be an issue. No need to refrain from using heap though.
As another embedded developer, I agree. In fact, for custom HW, dynamic memory is absolutely forbidden. If you don't know the size of something, go back to the HW devs and ask the size of the storage/block/register/packet/etc.
Congrats on 20K boi :)
A picture is worth a thousand words.. I've seen various memory diagrams for Rust but this is by far the most clear and meaningful I've seen thus far. Thanks much!!
ur a legend bogdon, I wanted more info on this & u read my mind
Awesome idea, there are so many videos about stack and heap but not so many quality content about memory management strategies, hope you nail it!
I wish my Operating Systems professors in college had explained this as clearly, thanks for the refresher.
Привіт. Thanks for amazing videos. I'm also a web dev so I really appreciate mainly these videos to get familiar with the low level programming concepts.
Nice video, looking forward to other videos in the series
Thanks for posting these series, they are simple and clear, very easy to understand. Keep up the good work
Ok, Another great rust video, Its time to like it. Oh wait, its already liked 🤔 . Ah I liked it subconsciously 😂
Awesome !! I guess rust is really different when u coming from high level programming background and this series really going to help !! Thanks a ton brother !! Cheers from INDIA ... by the way ur rust book playlist is amazing !! Anyone who wants to step into that playlist s the Best .
This is very important information for systems development. When I was working with Assembly and C/C++ it was imperative to understand memory and memory management. With languages like Java and C#, the garbage collector makes it less important to know. Probably why Rust is perceived to have a steep learning curve. Excellent video
I just call Volatile memory -> “Memory”; Then I call Persistent Memory -> “Storage”;
I think it simplifies it.
Thank you so much, this video was very helpful.
Thanks you so much ♥♥♥. Your videos are really helpful and this one I've found it interesting.
Didn't know that Heap memory was shared between the all threads. Its like static is the first level, then stack goes up with a limited size of memory that can consume but doesn't mean itll always consume that amount, like a dynamic range. And the heap as the unlimited. So interesting.
Just passing by to leave a like. Nice breakdown. Thank you.
👍 Great! Looking forward for the next one!
so great content bro, love from Brazil
Helpful, useful video, great content, really brings understanding of the important concepts of program engineering. Thank you very much for producing high-quality content.
Awesome, can't wait for the next in the series!
very straightforward ✌
Thanks for playlists ❤️
This series is going to be excellent, I can feel it. It's going to benefit developers outside of the Rust community too, which is even better.
That being said I do have a very strong objection to the way educators like to graphically represent memory. In my opinion, the classical "stack grows down, heap grows up" diagram is unnecessarily confusing and could potentially be very misleading, so it should no longer be used.
First of all, in any modern OS memory allocation is delegated several layers, each with their own management strategies and optimisations, so the diagram is not a physically accurate representation of the actual memory layout (e.g. there's no reason why the stack can't grow "upwards" instead of "downwards", whatever that means; nor is there a reason why stack, heap, and static regions are in that particular order). My past self as a CS student used to struggle to remember where each category of memory belongs and how they grow and shrink, while in fact it was a complete waste of time because it's just an arbitrarily-chosen representation.
That being said it would be a useful teaching tool if it abstracts away complexity and aids in understanding. The problem is that it really doesn't. Unless you are a developer of extremely low-level memory management software, all you need is to see stack, heap, and static as three distinct and separate regions. The stack is well, a stack; a heap is basically a do-whatever-you-want sandbox; and static is determined at compile time. Where exactly they each are and what their physical layouts are is frankly none of your business. And I mean that in a good way, because the allocator has taken care of it for you.
So why is it that we continue to draw our memory diagrams like that? Maybe because it highlights how memory is finite? But duh, everyone and their dog knows that; plus most programs are never going to run into "out of memory physically" situations these days.
So what I propose is simple - draw these memory regions as separate things. The stack - sure it's a stack alright, we can keep the rectangular box. But don't tack on the heap after it - they are not actually "connected" anyway, and drawing them as such serves no purpose but to confuse. So just draw the heap separately, as a circle or something. Then draw the static region as a circle (or whatever shape you prefer) and we're done. Tells the same story but with much less confusion.
Thank you for the feedback Chameleon. I will take this into account!
It is important to know that the stack does have a direction. Call it what you will, up, down, etc. Stacks are always (AFAIK) last-in-first-out buffers.
This is truly a brilliant series 🌟
Nice video, thanks! Would be awesome to see more concurrent & async rust in your channel :D
Awesome topic, keep it up!)
Great explanation!!
Great Video, this is exactly what I was looking for. Your content is the best I've seen when trying to learn Rust. As a byproduct I think its making me a better programmer as well learning these concepts that I didn't "need" to learn in python or JavaScript.
good lesson, static memory was new to me. waiting for more about this. (watching from Ukraine)
love this series.
Awesome great explanation
Would be great a video of Async, Futures and Poll!
Awesome series
Good video! Thank you for the information! Perhaps more diagrams and pictures would help the understanding and visualization of the concepts in general :)
I like Rust bc since I've been studying more in-depth fundamental concepts of CS the things and vocabulary used in rust lang started making more sense:
-> The concept of why ownership was implemented makes more sense once one understands memory attacks (buffer overflow, format strings, data leaks....);
-> The idea of lifetimes annotation is something often used when the compiler parses the code before compiling it, so it helps a lot the optimization as the code is transformed to lower levels of the architecture;
-> Reference Counting is another idea already present in CS literacy before its use in Rust, in distributed systems, when facing naming resolutions, reference counting was a solution to keep track of objects references in the used network. Rust borrowed this solution to memory management security and fast process execution again;
Many other advanced ideas were used when the rust started being developed! It's indeed a great language to learn!
Keep um coming!!
Really helpful, thanks !
Worth watching 🔥
Excelente video, muchas gracias 👌
Very nice stuff.
Super !!Thx Bogdan
Thanks for the videos ☺️
Blows my mind that modern programmers don't know mem management. I blame Java
simple and informative thanks
❤ thanks for the explication
wow your camera is higher quality than my sight bro
Thanks for the explanation.
Is the table from minute 04:07 available online? :D
Great video, thank you!
@Ivan Bulyk
Hell yeah dude thanks
Thank you so much !
Good content, thank you.
Great ... waiting what next .. thanks.
Thanks for the good video!
Great video, ty
Thank you very much
great learning
Just excellent!
Interesting. I guess heap memory allocation is more for more specialised use cases.
I’m still learning so found this a little difficult to understand but I do have a question. When you mentioned the heap not storing a fixed string size due to the program not knowing the size of the user input… Does this mean even with a restriction in place to prevent the users string input size, it will still be stored on the heap? I hope this makes sense. Thanks
I'm just starting to learn rust, but I'm finding memory allocation to be very slow when compared with C++
Great video
You're the best!
Great video thank you. Quick question, using your example of getting a name from the user. You said we don't know how long their name is, so the amount of memory needed to allocate to the variable is unknown at compile time => we have to use heap memory for this. But memory on the stack also has dynamic size, so why can't we just allocate some stack memory instead?
You technically can (although I'm not sure if you can in Rust) but it's not considered the best practice. What you're talking about is "Variable Lenght Arrays" or just in general dynamically-sized stack allocation. In C, you can use the function "alloca" to do this. There are a few reasons it is recommended against e.g. it creates a higher chance of stack overflow errors since you could allocate extremely large buffers. This in turn means you should probably have an upper limit on the size of the buffer, in which case it often makes more sense to just allocate that upper limit on the stack statically in the first place. Hope that helps!
Good stuff good stuff
Yasss! Thanks I was waiting for a video like this! It would be awesome if you did a video explaining how are diferent variable types stored in memory for example struts with traits and vectors.
Is Zig a better companion language to Rust compared to C? Zig’s arena allocator seems to be well matched to a foreign function call from Rust.
thanks
Hmmm,... As an embedded and system Programmer - rather new to Rust - lots of "errors" popped up to me in this video. I do appreciate that these simplification makes a lot of sense when its gets to highlighting the memory management paradigm of Rust vs the "traditional" ways of C++ or Java. But I suppose Rust can be used without a heap for small embedded projects, as I often do with C++ . Or does that not make sense as Rust guarantees that the heap is safe ?
Cool, but isn't the Heap itself cleared at the end when the program exits (thanks to ownership)? Or did you mean it?
Everything should be gone. The whole application space has gone. The OS would deal with it, I would think.
Thanks.
How does one get your first rust job?
Nice :) We like
⚡⚡⚡⚡
I am wondering.. What does "Coming from a web developer background" mean? How can a web developer not know how memory works? Because he doesn't need any?
More specifically a JavaScript background. JS is garbage collected so you don't need to know the details of memory management.
This video was fucking amazing
:ᚨᛏᛟᛗᛁᚲ:ᛒᚨᛞᚷᛖᚱ: awesome video introducing memory management.
It is absolutely terrifying that "programmers" don't know about stack and heap as part of CS101.
Nice
Hi there, would you like to make new topics such as introducing some useful crates for writing some projects, or how to read Rust projects from the real world project level. Since I watched all your Rust videos and videos from other channels, I finished the Rust By Examples, and Rustlings (I didn't read the Rust Book and Cargo Book, I know, I know, I should read them). After I read some real project source code I learned a lot in Cargo.toml such as features, and so many useful crates used in the projects.
Thanks for the suggestion. I'll add that idea to the list.
I'm a competitive programmer and I have to solve some coding questions and that's why I am learning rust but it's very hard for me to get inputs.
Like integer Input, create 2d array and take input.
How to make graph and all.
Kindly help me for programming in rust rather than development only.
Please make a good Input video in rust.
Thanks
Dude
I need to you experience watching your video on a decent size modern quality HDR monitor. Stare into the sun of your white background for 10 minutes. Please... Stop abusing us. :D #DarkMode
Thanks a lot