discord: 0xfffe
elephant: https://hachyderm.io/@pastels
24.24.2.287


artemis
@artemis

rust's memory ownership model makes way more sense if u aren't already afflicted with computer programmer brain from languages that copy or reference automatically all the time.

u cut out a square and u move it into a box. now u dont have it anymore, its in the box.

but if u cut out another square using the first square as a template (clone()), now u have two squares, u can put one in the box and keep the other for yrself

but of course now its 2 different squares, they arent the same square anymore, changing one doesnt change the other.

and if u lend yr square to yr friend, well, they can do anything they want to the square, and u cant do anything with the square until they give it back to u. but they can't keep it forever because u will be very cross with them if they do.

into()/from() is also very easy: u take yr square and cut off the corners to turn it into() a circle. now u dont have a square anymore, but u do have a circle. Put another way, u created a circle::from() a square.

immutable borrows are probably the least intuitive. are you showing everyone a picture of the square? are you holding the square and letting everyone look at it but they can't touch it? are you letting the touch it but enforcing the no-changes rule with force? who knows.

and for some reason u cant change the square while more than one person is looking at it, because it's an accursed square, and every viewer's minds will shatter if u do. but other than that, it is a perfectly normal square!

(edited to fix an error with from)


You must log in to comment.

in reply to @artemis's post:

The immutable borrow might make sense as “here’s some laminated worksheets of my square that you can use as reference for your crafts, and I promise I’ll keep my square the same until everyone is done with their worksheets.”

Kind of a stretch. But like, I could see myself in grade school having to turn in my laminated worksheet because it’s a public school and these 30 laminated papers are gonna have to scrape by for like 10 years

just depends on whether you like writing out types or not. into() lets type inference write out the types for you if you're using it in a context where the type is already known

similarly, from() lets the type checker write out the types for stuff like let bindings when the type wouldn't have otherwise been known.

the convenience is situational. does the compiler need more type context right now or not?

the convenience is situational. does the compiler need more type context right now or not?

I’d argue the real question is “does the reader need more type context or not” and the answer is “yes” more often than not :)

In Haskell I circumvented that by realizing “plain old functions” are the solution, if you call them fooToBar :: Foo -> Bar.

this is something i’ve appreciated about how the language server integrates with VS code, it includes all the implied types so you get the benefit of clarity for the reader without having to type out and know everything in advance. especially useful for someone still relatively inexperienced in rust (me)

yeah I just use inlay types so my text editor writes the types out for me to see. cause i don't like typing, and I do like seeing types. some people don't like it I guess tho and that's fine.

Send and Sync is like this except the people in this metaphor are threads instead of functions. Send is “I’m allowed to give this away to my friend” and Sync is “I’m allowed to share this with my friend” (maybe you can’t give away your calculator but you can both agree to share it)

immutable borrow means everyones very close to the square to look at it (the square is small) so if anyone tries to cut the square they'll probably cut someone by accident which is very unsafe

you can instead tell everyone to step away for a bit while you cut the square (Mutex)