Implementing Rust's Vec From Scratch

In this stream, we implement a limited version of Rust's Vec type from scratch. In doing so, we learn a lot about unsafe Rust. This stream is geared towards those with at least intermediate experience in Rust, but beginners should also learn more about how Rust's memory model works.
Note: This is just a learning exercise! The standard library's Vec is great, and you should just use that.
The resource on covariance I mention in the stream can be found here: github.com/sun...

[@Fawaz-vn5eg]

I love you for taking your time and effort for making these great videos possible. I know you must have busy schedules, even though you are doing this. This is totally amazing for me. I am just craving to give you a hug for this 😭 Thank you so much.♥️

[@xrafter]

Noooo ,don't hug he is a nice guy if you hug him he will go ill because of reasons

[@BiA-hg7qr]

@@xrafteris he "the gay"?

[@comradepeter87]

what is this reply section 💀

[@gsniteesh3794]

Love the way you make these tutorials :). Instead of teaching individual concept, we learn more when you build stuff like these. Hoping to see you build more complex projects in coming sessions.

[@carsonholloway]

I am new to rust (have been learning for about 2 weeks or so), and haven't slept in over 24 hours now, and this still makes perfect sense. I think you have a talent for explanation and not going too slow or fast. Keep up the good work!

[@liptherapy]

I really really appreciate the 1080p!! Thank you for all your great videos 😃

[@nilshaberstroh2705]

Super good! Thank you very much for taking the time to produce this video. This is a fantastic approach to show-case "unsafe" in Rust.

[@1vader]

I didn't know that using *ptr = val is unsound for uninitialized memory but you're right, the documentation says it will drop the previous value in there.

[@thibozaide4429]

Really great video helped me a lot ! Thank you

[@dimkir100]

Seems that at 1:07:40 the `self.len.checked_mul(...)` must be `(self.len+1).checked_mul(...)` as this way we're checking not only starting offset of a pointer, but rather resulting offset of the pointer and making sure it doesn't wrap around when the actual operaiton of `ptr.as_ptr().add(self.len)...` is finished 🤔

[@lizzienovigot]

Exactly what I thought. Dude checks the existing length for safety, which would already exploded on the previous push if too large

[@theartist8835]

I hit like before I watch the video. I know your videos are informative and full of knowledge. Thanks Ryan!

[@nullc847]

yeah same lol

[@treee6145]

Thank you, this is incredibly useful for learning how to implement data structures with unsafe components and also taught me a lot about how to approach writing unsafe rust. I’ve found that writing some data structures in safe rust can be extremely tedious and inefficient!

[@kevinking385]

Missed opportunity to call your vec type LeVec xD

[@tomasscott7088]

i guess I am kind of randomly asking but do anyone know a good website to watch new tv shows online ?

[@camdenlouie1424]

@Tomas Scott flixportal =)

[@tomasscott7088]

@Camden Louie Thank you, I signed up and it seems like a nice service :D I really appreciate it!

[@camdenlouie1424]

@Tomas Scott you are welcome xD

[@embeddor2230]

There's indeed a very good reason to write your own vector implementation. The vector of the standard library is optimized for general purpose use not for performance nor memory efficiency. When it comes to high memory restrictions or perf ciritical code, where you need for example custom allocation strategies, different amortized memory growth or different destruction behaviour, the standard vector is pretty much useless. No wonder C++'s boost has many different vector-like implementations for different use cases.

[@kvadratbitter]

At ~ 1:10 why use the from_size_align_unchecked() and manually do the prerequisite safety checks, instead of using from_size_align() which does those checks for you? Am I missing something?

[@doge6363]

As a junior dev, these are great!

[@PublicAccount0]

2 hours about vectors in Rust - so good.

[@rnavarro50]

Great video! Thanks a lot Ryan!

[@dartme18]

It looks like you press "escape" "up" "down" compulsively. ... I do, too...why do we do this? I use kinesis advantage and vim. What kind of keyboard do you use? Thank you for the walkthrough!

[@joelmontesdeoca6572]

Awesome video, thanks

[@thisismyalias]

That was really nice lesson. Thanks a lot!

[@naturallyinterested7569]

Hey, a philosophical programming languages question, especiaally with NonNull and its dangling() constructor: isn't a dangling pointer much more dangerous than a null pointer? At least with a null pointer you get a crash directly which ist a very localized and easily debuggable problem, while with a dangling pointer you have silent failure with possible data corruption in the worst case.

[@SimonBuchanNz]

A bit late a reply, but the reason Vec does this is is for a neat trick: because the pointer can never be null (even if it's not valid to access), this gives the type a "niche" that the compiler can squeeze a an extra literal bit of information out of, which means that you can store an Option without any more space than a Vec.

[@TernaryM01]

Given that a dangling pointer can be constructed without the "unsafe" block, I'm pretty sure that the compiler will ensure that you won't be able to dereference the dangling pointer (in safe Rust). In contrast, in C and C++, because there is no such mechanism of memory safety check baked into the language, there is NEVER a good reason to assign a pointer as NULL. (In C++, it can be replaced by nullptr).

[@fbytgeek]

Here is a like before I even start watching it :) because I know it will be worthwhile!

[@mrvectorhc7348]

Thanks a lot for your time and effort :3

[@Lexikon00]

Can you make a video about variance in rust? It's an important topic in unsafe with generics. Might be nice to have a detailed video about it.

[@nicolasherve7853]

Thank you for your great videos. I think there is an error in the push method when you check the rounded value : you should add "align - size % align" instead of "align % size".

[@taffinaround]

To see why this is the case, notice that size = k*align + (size % align) for some integer k. Then size + (align - size % align) = (k+1) * align, aka the nearest multiple of align rounding up from size. In the example of size = 10 and align = 4 it was just bad luck that align - size % align = align % size = 2, so you had the right outcome by accident.

[@pedrodesanti6266]

That is pure gold

[@evanxg852000]

0:38:27 I think since an unsized type may have only one value (memory is the same), a flag can be kept to true and store the single value of the unsized type. then based on length & capacity we just return a copy of that same value when pop is called. Would that work? do you any issue with that?

[@preeeby]

Thanks!

[@lunaticwyrm4675]

sometimes it's a good thing to reinvent the wheel

[@shantanuvichare6792]

Great video! Got to learn a lot about how to deal with various safety checks before writing unsafe code. Just had a doubt.. is it possible to take reference outside the unsafe block in the get method. (I think I should rather ask if it's possible to return the dereferenced value outside the unsafe block, which shouldn't be possible according to me but please correct me if I'm wrong) Also, would love to go through more content covering varied use cases around unsafe code. Really appreciate your efforts for taking this approach of teaching advanced concepts.

[@elijahwoelbing6360]

this was awesome

[@n.fejzic]

Hey I like your videos a lot! May I know what keyboard are you using? Seems like a nice one!

[@GlobalYoung7]

thank you 👍😀

[@catalinavram3187]

Awesome video!

[@danielgurgel8080]

Thank you for all your videos! Would you mind sharing which shell do you use?

[@RyanLevicksVideos]

In this video I'm using zsh on WSL.

[@vkjvivek7]

Why alloc::alloc(layout) return a null pointer? @Ryan

[@austecon6818]

Did you do a video of benchmarking this against the std vector? I'd be quite curious

[@Mrhennayo]

Thanks

[@bestformspielt]

Why are there three "Droppin'" at the end of the video? Shouldn't there be only two as only two items have been pushed into the vector?

[@argh523]

For testing, he actually created another instance of `Dropped` to put into the assert to compare it to what was in the MyVec. So there's two `Dropped` in the MyVec, and a third one he created for the assert that he's comparing it to. That's why he rearranged to code in the very end, moving the creation (and scope) of this third instance outside of the assert, to show that this is what was created and then dropped.

[@pdxholmes]

Anyone know what VS Code plugin he's using that gives the type inference lens like that? E.g. that it shows him the inferred type is Vec. Is that part of the standard Rust VS Code plugin and I missed it?

[@RyanLevicksVideos]

The is the rust-analyzer extension marketplace.visualstudio.com/items?itemName=matklad.rust-analyzer

[@naveendavisv]

Why if the size of T is 16, its memory address needs to be evenly divisible by 16 ?

[@qwerte6948]

compiler nonesense, but proper aligment does help the CPU when shufling data around.

[@FiskKatt]

Could you please link to the reading of covariance that you referred to?

[@RyanLevicksVideos]

Here you go! github.com/sunshowers/lifetime-variance-example/

[@Lexikon00]

At the end you said: "you are totally right". What did the chat say?

[@RyanLevicksVideos]

They simply pointed out that there was another instance of `Dropped` which I was creating in the test which was the reason we saw a third printing of "droppin'". I originally thought this was a double drop of the same instance (which would make our implementation wrong), but it wasn't. The code was totally fine. At the end I simply rearrange the test to demonstrate that the drops happen when we expect them to happen (at the end of the test function).

[@argh523]

He had two `Dropped` in the MyVec, but he actually created a third one to compare in the assert, and that's why there were three droppin's. So it wasn't a bug, just the test code.

[@CarrotCakeMake]

Reference from a raw pointer is unsafe{&*ptr}, it doesn't drop.

[@adho12]

Thanks for your teachings. But what’s the repo link?

[@RyanLevicksVideos]

It's in the description of the video: github.com/sunshowers/lifetime-variance-example

[@adho12]

@@RyanLevicksVideos i meant of your vec implementation

[@xrafter]

The rustnomicon 😱😱😭😦

[@voidnull7329]

when will u complete gameboy emulator book...??. I'm Having some trouble implementing it..??

[@CGMossa]

Article by rain about vi covariant

[@RyanLevicksVideos]

Here you go! github.com/sunshowers/lifetime-variance-example/

[@androth1502]

after watching this,: unsafe{ self.hate_for_rust -= 1; }

[@mkgh7322]

Thank you sir