📝 Get your *FREE Rust cheat sheet* : www.letsgetrusty.com/cheatsheet

@toolb0x_

2 жыл бұрын

does not work.. :-/

@xy9439

2 жыл бұрын

Can confirm, not working

@letsgetrusty

2 жыл бұрын

@@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

@toolb0x_

2 жыл бұрын

@@letsgetrusty i have send you an email. looks like others have the same problem..

@toolb0x_

2 жыл бұрын

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

@dmitriidemenev5258

2 жыл бұрын

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.

@mlenox

2 жыл бұрын

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.

@PrivateUsername

2 ай бұрын

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!!

Ok, Another great rust video, Its time to like it. Oh wait, its already liked 🤔 . Ah I liked it subconsciously 😂

Congrats on 20K boi :)

ur a legend bogdon, I wanted more info on this & u read my mind

I wish my Operating Systems professors in college had explained this as clearly, thanks for the refresher.

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!

Thank you so much, this video was very helpful.

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 .

Привіт. 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.

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.

Thanks for posting these series, they are simple and clear, very easy to understand. Keep up the good work

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.

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 for playlists ❤️

so great content bro, love from Brazil

Nice video, looking forward to other videos in the series

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 topic, keep it up!)

👍 Great! Looking forward for the next one!

Great explanation!!

Would be great a video of Async, Futures and Poll!

Keep um coming!!

very straightforward ✌

love this series.

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.

Awesome, can't wait for the next in the series!

Nice video, thanks! Would be awesome to see more concurrent & async rust in your channel :D

good lesson, static memory was new to me. waiting for more about this. (watching from Ukraine)

Awesome great explanation

Awesome series

This is truly a brilliant series 🌟

Really helpful, thanks !

Very nice stuff.

simple and informative thanks

Excelente video, muchas gracias 👌

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!

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.

@letsgetrusty

2 жыл бұрын

Thank you for the feedback Chameleon. I will take this into account!

@mlenox

2 жыл бұрын

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.

Thanks for the videos ☺️

Great ... waiting what next .. thanks.

Good content, thank you.

Super !!Thx Bogdan

Great video, ty

Thank you so much !

Thanks for the good video!

Great video, thank you! @Ivan Bulyk

Thank you very much

Thanks for the explanation. Is the table from minute 04:07 available online? :D

Just excellent!

Great video

Thanks a lot

Nice :) We like

thanks

Good stuff good stuff

You're the best!

This video was fucking amazing

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?

@gvcallen

2 жыл бұрын

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!

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

wow your camera is higher quality than my sight bro

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.

Cool, but isn't the Heap itself cleared at the end when the program exits (thanks to ownership)? Or did you mean it?

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 ?

:ᚨᛏᛟᛗᛁᚲ:ᛒᚨᛞᚷᛖᚱ: awesome video introducing memory management.

Nice

How does one get your first rust job?

⚡⚡⚡⚡

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?

@letsgetrusty

2 жыл бұрын

More specifically a JavaScript background. JS is garbage collected so you don't need to know the details of memory management.

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.

@letsgetrusty

2 жыл бұрын

Thanks for the suggestion. I'll add that idea to the list.

I just call Volatile memory -> “Memory”; Then I call Persistent Memory -> “Storage”; I think it simplifies it.

It is absolutely terrifying that "programmers" don't know about stack and heap as part of CS101.

Blows my mind that modern programmers don't know mem management. I blame Java

Dude

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