How to fight Rust's borrow checker... and win. 

Because it does not take ownership when you pattern match it, but fun enough pattern matching itself consider borrowed T, &T as a separate type than T. So it's like borrow checker not being there if the code is not multithreaded.

Although technically not very correct; this is a very, very good analogy on how to deal with the borrowchecker :) [IMO]

​@@djangofakkeldijagreed

This is sound advice for all kinds of programming

Yeah I have this same issue, where if I don't make it clean or optimize fast enough, the spagetti mess will come to quick. I guess it's about finding balance

Ahhh, another soul who shares my pain

I’ve actually used AI quite a bit now and it has definitely helped me learn and improve my code. I recommend Phind, as it specialises in dev and tech stuff and provides good links and you get some free access to GPT-4. Also Perplexity. Both provide links as well. A free alternative to Copilot is Codeium, which is cross-IDE. I used it on my Rust a couple of days ago and learnt something.

That essentially leads to 2 mutable references to the same memory, that's undefined behavior in Rust. So, for an example of how 2 mutable references can break code, imagine you took a mutable reference to posts inside of main and then set the first element to String::from("Hello"). You then call set_id(), which maliciously sets the first element of posts to String::from("Goodbye"). Then you attempt to print the first element of posts. What you might expect is it printing "Goodbye". But, not only, this might be confusing, the compiler also assumes that there is at most only one mutable reference to any value at any given time, and it uses it to elide reads. So, at the end, in a release build, the compiler might reason that, since we've just set the first element to "Hello" and no other mutable reference to posts exists (incorrect in this case), then we don't really need to read the first element, we know what it is already, so it would print "Hello".

@@SophieJMore Thanks for the example. Is there a situation in which it could lead to a segfault, too? (If the compiler didn't forbid the whole situation.) For example, could `set_id()` do something that amounts to (in C terms) calling `free()` on `posts` or an element of `posts`? I guess it could set `posts` to a completely new Vector, thus having the old Vector deallocated, while the code in main still holds a reference to the old Vector; is that plausible?

@@SophieJMore The actual problem with this code is that posts are not borrowed, but moved. I don't know, how moving really works, but if it actually MOVES, then posts in the struct should be an invalid memory (For Vec it's especially dangerous, because the Vec itself just stores a pointer to data and length, so if you try to mutate the data that invalidated pointer points to, you'll get a segfault)

Oftentimes, it will make more sense and be more efficient to store a reference rather than a copy, even if a copy is still possible. For example, if you're writing a parser, it would make more sense for a "struct parser" to store a reference to the input string rather than to make a copy of it.

@@somebodyelse9130 : You make it sound like our only choices are to either borrow or copy. The whole point of Rc is that it allows us to have pointers that are not borrows, and no one suggests that we should make copies.

Using the Rc reference counter to manage the connections between structs. (Or Arc if your appliacation is multithreaded.)

Long live the Kingdom. Long live the king Ferris !!!

people at starbucks miswrite names

Because basic girls order Starbucks 😂

Me neither but a soy latte maga hat drinker is a funny Paradox 😂

"Basic" is slang to describe someone (usually a girl) that just likes and does mainstream things. Think of a blonde, white girl that drinks Starbucks and listens to Taylor Swift, just like all her friends and tens of thousands of other girls, for example.

​@ernesto906 yes we exist, yes we drink soy lattes. TMYK 🇺🇲☕️

at least in my real life 😅

That depends a lot on the kind of program you're making. I hit the borrow checker almost every day, but it's usually not a problem to just go around it by cloning or breaking a large struct into smaller parts

individual chars are owned unless you borrow them.

@@sproccoli … are they?

@@TheRealMangoDev yes. they just implement copy , so they are cloned rather than moved when you assign them without a borrow. each copy still has a lifetime and can be borrowed\moved. the defaults are just different. you really cannot have an 'unowned' type.

True that. Problem is that having no borrow checker C is free to fight you in all kind of devious ways. At least C does not delude you about that so much. C++ is much more devious

@@Heater-v1.0.0 C does exactly what you tell it to do, and not the other way around.

@@Antagon666 Indeed it does. And that is exactly the problem. More often than we care to admit what we tell C to do is not what we intended to to tell it to do. Due to some silly mistake or other. For example this week I sent too much time trying to find out why my C code which worked on my PC and worked on my ARM based McBook did not work on an embedded ARM system running Linux. Turned out I had made an error which caused some malloced memory to not be properly initialised. Rust would never have allowed that silly mistake in the first place. A lot of time would have been saved. Don't get me wrong, I'm still happy to use C and appreciate it very much for what it is. But I do also appreciate the advantages that Rust gives. I even more appreciate that the Rust version of the code I was talking about is faster! It is wrong to imply that Rust tells anyone what to do. It clearly does not.

Hard to make. And yes, almost always pointless

3. Avoid Battle

Avoid Rust

@@xshady2967 for me error handling falls under making it work

Yeah the third point really sounds odd. I know where he comes from, but the way he put it, you get the impression "to avoid having ha hard time using rust, just ignore the difficult parts" which is basically just ignoring the issue. I also have a small gut feeling he might have deliberately made the third point sound a little controversial so people correct him in the comments ;)

90% of the time that's your language telling you that your data structure was bad to begin with.