I don't understand...? I think I never explicitly run a method/function that is called copy (there isn't at least not for the trait Copy)
Lol yea I think the .copy() comment was a little gaslighting or something.
no its not youre crazy
I thought it was randomly adding Send and Sync traits to function signatures until rustc is happy.
That too
Randomly wrapping things in Arc::new()
This was me in courses that used C. Keep adding and removing * and & until the IDE was happy and it usually worked.
Ah the good old times with C, when things were much more simple (but unsafe...)
(void*) flashbacks intensify.
The "best" way to program dynamically typed...
I'm gonna have to borrow this book
Me too. I also want to make some changes to it at the same time.
Better apply for a mutable library card now before someone else does
Hahaha yes tfw Rust forces you to put your shit in a Rc<Cell<Option<>>>
New your program deadlocks instead of crashing, peak safety.
EVERYBODY STOP. Nobody make a move or the memory dies. We have a Mexican Memory Standoff.
Follow up of: "Mmm... should I put lifecycle annotation in these 10 structs or just use and Rc and call it a day?". Rc and Box FTW.
So... now the rustc borrow checker is the new video game boss that is nearly impossible to beat for newcomers, right?
I think that's the only thing I dislike about rust. Not having to use * to dereference but later having to use is tad confusing. I know it's still clever solution but in this case I prefer c++'s straightforward consistency.
Using ampersand never was problematic for me.
C++ does have the problem that references are not objects, which introduces many subtle issues. For example, you cannot use a type like std::vector<int&>, so that templated code will often have to invoke std::remove_reference<T> and so on. Rust opts for a more consistent data model, but then introduces auto-deref (and the Deref trait) to get about the same usability C++ has with references and operator->. Note that C++ will implicitly chain operator-> calls until a plain pointer is reached, whereas Rust will stop dereferencing once a type with a matching method/field is found. Having deep knowledge of both languages, I'm not convinced that C++ features "straightforward consistency" here…
Same for C, & yields a pointer to a value, and * allows you to access the data. (For rust people, a pointer is like a reference with looser type checking)
I doubt many people have ever use that or any of the other low level memory API. The main appeal of rust is not having to do that.
Sure, but raw pointers and unsafe Rust are still covered in the official learning material, so I assume that most Rust devs know about raw pointers.
Replace that with golang and now we’re talking
Yeah, popped in the comments to say the same.
I dont know what my damage is with pointers…
honestly with Go in general I’m in a perpetual cycle of being annoyed with it and then immediately being amazed when I find some little trick for efficiency - with stringer interfaces and the like
Oh and .clone()
And .copy()
.copy()?
Are you copying a
ResultorOption?I don't understand...? I think I never explicitly run a method/function that is called copy (there isn't at least not for the trait
Copy)Lol yea I think the .copy() comment was a little gaslighting or something.
no its not youre crazy
I thought it was randomly adding Send and Sync traits to function signatures until rustc is happy.
That too
Randomly wrapping things in Arc::new()
This was me in courses that used C. Keep adding and removing * and & until the IDE was happy and it usually worked.
Ah the good old times with C, when things were much more simple (but unsafe...)
(void*)flashbacks intensify.The "best" way to program dynamically typed...
I'm gonna have to borrow this book
Me too. I also want to make some changes to it at the same time.
Better apply for a mutable library card now before someone else does
Hahaha yes tfw Rust forces you to put your shit in a
Rc<Cell<Option<>>>New your program deadlocks instead of crashing, peak safety.
EVERYBODY STOP. Nobody make a move or the memory dies. We have a Mexican Memory Standoff.
Follow up of: "Mmm... should I put lifecycle annotation in these 10 structs or just use and Rc and call it a day?". Rc and Box FTW.
So... now the
rustcborrow checker is the new video game boss that is nearly impossible to beat for newcomers, right?I think that's the only thing I dislike about rust. Not having to use * to dereference but later having to use is tad confusing. I know it's still clever solution but in this case I prefer c++'s straightforward consistency.
Using ampersand never was problematic for me.
C++ does have the problem that references are not objects, which introduces many subtle issues. For example, you cannot use a type like
std::vector<int&>, so that templated code will often have to invokestd::remove_reference<T>and so on. Rust opts for a more consistent data model, but then introduces auto-deref (and the Deref trait) to get about the same usability C++ has with references andoperator->. Note that C++ will implicitly chainoperator->calls until a plain pointer is reached, whereas Rust will stop dereferencing once a type with a matching method/field is found. Having deep knowledge of both languages, I'm not convinced that C++ features "straightforward consistency" here…Same for C, & yields a pointer to a value, and * allows you to access the data. (For rust people, a pointer is like a reference with looser type checking)
We have pointers in Rust, too :) see documentation
I doubt many people have ever use that or any of the other low level memory API. The main appeal of rust is not having to do that.
Sure, but raw pointers and unsafe Rust are still covered in the official learning material, so I assume that most Rust devs know about raw pointers.
Replace that with golang and now we’re talking
Yeah, popped in the comments to say the same.
I dont know what my damage is with pointers…
honestly with Go in general I’m in a perpetual cycle of being annoyed with it and then immediately being amazed when I find some little trick for efficiency - with stringer interfaces and the like
https://www.youtube.com/watch?v=co3ewqQlX-8
The actual video, not the reaction: https://www.youtube.com/watch?v=TGfQu0bQTKc
Here is an alternative Piped link(s): https://piped.video/watch?v=TGfQu0bQTKc
Piped is a privacy-respecting open-source alternative frontend to YouTube.
I'm open-source, check me out at GitHub.
Here is an alternative Piped link(s): https://piped.video/watch?v=co3ewqQlX-8
Piped is a privacy-respecting open-source alternative frontend to YouTube.
I'm open-source, check me out at GitHub.