Scoped threads were added in Rust 1.63.0, which could be used to cleanly solve your specific simple example without unsafe

Just wanted to let you know that scoped threads now made it to Rust's Std library in 1.63.

Very nice video. It's hard to find examples online of memory corruption in Rust, so it was nice that you demonstrated how that could be possible. Also, as you iterated over the example I was getting high hopes that you would explore pinning but then the video ended, haha. I was ready for more 30 minutes just on Pin 🙂. I hope you can explore that in the future as your examples oriented approach makes everything much more comprehensible.

Thanks for starting with a normal for loop and working your way up to idiomatic rust. Really appreciated by a starter like myself.

Awesome! Thanks for the video! Although I knew most of this before, watching videos like this feels like casually "strengthening" my inner understanding of rust which is always appreciated :)

14:30 the worker thread will outlive main() {} if you decided to add a conditional panic!() before the join. 16:00 aah, so crossbeam's scope will be dropped at that diabolical panic, ensuring the threads join

Love your work! this video was pitched at the perfect level for me

I love your blog, learned from it so much.

Insanely well explained, fasterthanlime ! Keep up the good work :D

The more I learn about Rust (and what it makes explicit about how hard it used to be in C++) .... The more I appreciate simplicity of programming with GC.

Where is Cool Bear though 🐻 😞

The feeling when you finally understand ownership! Great video.

18:00 The reason that move doesn't work is because rust compiler doesn't understand the difference between shallow and deep borrow. Since the "good_lines" vec borrows (points to) the heap where "input" points, it's actually safe to move input while good_lines exist. If good_lines pointed to the input's length, for example, then you couldn't move the input, because then good_lines would point to invalid memory. But the Rust compiler has no way of knowing that. There are no type annotations for it. The same problem is with shallow/deep mutability. Sometimes you have to declare a variable binding as mut even when you don't need shallow mutability.

I did not understand *all* of the parts of this video, but I still managed to learn a lot by watching it. I will be coming back to this video, certainly.

Yeah this was really insightful into subtle workings of rust safe code. Would like to see more of it. I'll try to write a "safe" fn woops this afternoon hopefully, now that I'm curious to make it work :P

Very interesting demonstration and explanation! I dealt with the same situation a couple of weeks ago, but I didn't delve into the "unsafe territory" since I'm "still learning" Rust. Finding out about this video was a pleasant surprise, in the past days!

Great video. How about Pin and Unpin. They should help with these problems (almost) without unsafe. Are there a any good guides on how to use it in self-referential structs?

loved that part with the diagram

This was indeed fun. Thanks!

i have been wondering for months why joining threads doesn't join lifetimes, you are a lifesaver for demonstrating crossbeam's scope. so useful, thank you so much :DDD

Amazing video! thank you!

Love you videos! keep it up!

Hopefully there are more in que regarding rust.

What a good simple language!

Excellent video

Once you mentioned the second thread, all I could think was "you could just do the entire thing in the new thread".

Hi bro, thanks for all of your hard work. I would like you know, which plug-in are using, to show the errors on the line in Vs Code

Great video - what is the drawing tool you're using for doing the diagrams?

Hey, I love this video, you're amazing at explaining! Could you tell me what software you're using to make those diagrams? I feel like it could be insanely helpful for sketching out the logic flow of programs.

More please!

Great video also keep in mind aliasing could still screw things up.

The comment about a move being a memcpy, is that only true in the context of moving across a thread boundary? I always think of it as more of "compile-time rules enforcement" (playing the game of the language so to speak) than an actual memory operation at runtime, but I don't really know ... Was just the way I had envisioned. Maybe it's a runtime thing for thread boundary, but compile time thing otherwise. Something to ponder. I would think for a thread boundary, it would have to be an actual runtime consideration (move to stack of other thread), but otherwise I envision compiler enforcement only, and no memory op. I guess the bigger point is that a move may or may not be a memory op (i think...)

Hmmm... I wonder if this problem could be solved with a little language help - can we assume it's fine to hold a reference to a heap value, such as a T in `Box` while the box itself is moved?

Awesome video!! thanks!! :)

So... what approach would you use if you were to avoid unsafe?

Why did we get Pin instead of relative pointers? The issue is that references and pointers have absolute addresses. So &a returns the absolute address of a. If we had some way to do relative pointers/references we could have a pointer that is more of a "take my address and sub/add x to get to the thing I point to" instead of "I contain the address of the thing I point to".

This is about deep references. Still interesting, but I was hoping it would be about shallow self-referencing. Much more fun, since you cannot even move the struct then. Does "Pin" help there?

i don't think anyone has mentioned it but scoped threads were added rust's std 1.63.0, wish someone would have commented this earlier

what vscodes extensions are you using???? those seems useful

Currently, `std::thread` also have `scope()` which is pretty nice

Very nice!

I'm currently new to rust but, I know C++ very well. In rust I tried to solve exactly this problem for about 3 hours using "safe" rust without success. Having my background, I had some assumptions about how certain things work in rust. - Unlike C++, rust "moves" are just memcpy's. - Moving the container (String or Vec) shoud not mean moving its data from one location to another. It's just a handle. I even checked if String in rust has short string optimization. And it doesn't. So, what's the problem, rust? Why don't you let me do this clearly safe thing? In your video you asked exactly the questions I had in my head while trying to make it work. I also started to think, that "unsafe" rust is the solution to the problem. Thank you for the thought process and the solution. Great video!

What if you created an ImmutableString type that can be built from String? In that case it seems like self-reference to the ImmutableString could be made safe.

I wonder if it would be possible for Rust to be aware of the distinct lifetimes of the String struct and the string data it points to? when moving something, you invalidate anything that points to it directly, but it shouldn't invalidate pointers to things it points to. it doesn't seem like a super difficult rule to get right and it should be a fairly common case: if i borrow a pointer from a struct, you can move the struct, but you can't drop it nor mutate the pointer part of the struct. the last part is similar to rules that already exist, since you can partially borrow a struct and then the rest of the struct is still available *edit:* there seems to be a crate that attempts to solve this, called owning_ref. unfortunately it (and the example in the video) seems to be unsound/UB for some technical reasons, which is proposed to be fixed by the "maybe_dangling" rfc. *edit2:* another crate called _self_cell_ claims to be sound, so maybe that's the way to go. it uses a macro to define the struct and the allowed operations

Nice video! Just curious, what's that program around 8:18?

awesome! thanks

4:19 was there any specific reason to wrap the filter function in a lambda instead of just writing .filter(starts_with_capital_letter) directly?

Amazing!!!

"load bearing keyword" lol

7:00 How in the world did you get rust analyzer to highlight line 17 too?

I think there's some serious misunderstanding about "move" in rust, "move" here does not mean the memory address is _moved_, it's just the ownership of a value been moved.

23:03 Swapping the pointer, length and capacity of the two strings (input2 and s.input) does nothing to the references stored in S::good_lines. And I would imagine it also does nothing at all to each heap-stored string slice (pointed to by the pointer field of input2 and s.input - so the pointers on the stack are swapped, but the bytes in heap aren't.) But why does it then start failing when enclosed in a scope (curly braces)?!?

Hi, At 22:00 to 22:15 time, why does return S not complain about returning a reference to local variable input_slice? good_lines hold a reference to input_slice which is a local variable. Can someone please explain?

Which application are you using?

relatable intro xD even tho i never coded in rust, i understand the pain you are having.. why would anyone make another language as fast as c++ but puts tonns of restriction so no one can use it as free as they want

I think RcString is the best solution here

What font are you using in the video ?

So you are saying std::thread::spawn never drops any resource moved into it? That seems like a major source of memory leaks. Good to know.

Which drawing program is that?

In 2023 is there an safe way of achieving self referencial structs? ❤??

What software do you use for your diagrams?

Can anyone point me to good material on the topic of building your own LinkedList/ Graph type structures in Rust? This is what I understand by "self-referential".

`scoped_threadpool` may be lighter weight than crossbeam

_`starts_with_capital_letter`..._ 🤦‍♀️ Or just `.starts_with(|&x| x.is_uppercase())`...

4:30 filter(|x| f(x)) is the same as just filter(f).

good video. but where is self referential structs? looks like clickbait title

😂😂😂

GUI in rust lol

Contrived. "Main" is the program. Join the thread and end, else send the changed input to another file. You're creating an unnecessary problem.

rust is cringe

Oh man, I thought there was going to be some neat trick to create self referential structures without the unsafe keyword 🥲

Good work! May I ask what's the software you used to draw those diagrams.