yewler

There is not a single image across the entire universe more fit to describe exactly what happened to me last night than this one

I had a cry about something and I thought the estrogen was doing its thing but then I woke up 😭

After years of identifying as aroace, me thinks I might like girls in the gay way

I audibly chuckled at this. This is amazing

I think my brain is just hard wired to not understand sports. I've had the game of football explained to me no less than 4 times in my life and I still don't really get it 😭

One of the other grad students just told me that my outfits are always so cute. This gal's killing it 😎

Today I get to add to my list of hilariously awful Microsoft features. I tried using Word's LaTeX "support" and it's horrendous

Basically in Rust every piece of data has exactly one owner, and when that owner doesn't exist anymore, the data doesn't either. But often times you want to have multiple different ways to access the same data. For example, if you're calling a function and passing in owned data, there can only be one owner, so the function has to take ownership of that data. When the function returns, the variable that owns that data goes out of scope, and boom there goes that data. So if you try to access that data again after calling the function, you'll get an error. This is incredibly annoying behavior. What you want is some way for the function to be able to tell the compiler "no no I don't actually want to own this data, I just want to borrow it." This is what borrowing is. We're telling the compiler that we don't want to tie the lifetime of our data to the variable in the function call. The data will still be lost when the original variable dies, and doesn't care about the new one. Problem solved. But now that we have a concept of borrowing, it introduces some nuanced potential issues. This is what the borrow checker is for. It's job is to make sure you haven't done anything stupid with the power borrows give you.

For example, its entirely possible for you to write some code that borrows some data, but the owner of that data goes out of scope (taking the data with it) before the borrow does. Then the borrow would be trying to hold onto data that no longer exists. The borrow checker makes sure you don't do this.

The second issue you could run into involves mutable references, which I'm sure you've seen. Let's say you have some data owned by some variable. Let's say that you also have one immutable borrow and one mutable borrow to that data, active at the same time. So the mutable borrow is allowed to make changes to the data, but the immutable borrow is making the assumption that the data can't change. So the borrow checker won't let you do this because the whole point of an immutable reference is that it doesn't change.

Lastly, let's say you have 2 mutable references. This would make it possible to have a data race, where both references are trying to edit the data at the same time, and end up messing each other up. So Rust says no. You're only allowed to have one mutable reference at a time.

As long as your program never breaks these few rules, you've appeased the borrow checker. This is often easier said than done though

Someone needs to get on making a computer worm that downloads the rust book to your machine and encrypts everything else on your hard drive until you've finished reading it. This is how we trans the world. hehe. HEHEHE. MWAHAHAHAHAHAHA

I'm unhealthily addicted to sweaters and cardigans

I painted my nails and I wasn't sure I liked it, and then I put on girlclothes and all of a sudden I really like it

I hurt my lower back violently thrusting my pelvis to the dubstep remix of Sweet Caroline