Do you have some public code you could link to that you’re having this issue with? There isn’t a one-size-fits-all solution for Rc/RefCell, I think.

I find these videos give a very visual explanation and help to put you into the right mindset: http://intorust.com/
(You can skip the first two videos.)

Sort of when it clicked for me, was when I realized that your code needs to be a tree of function calls.
I mean, that's what all code is anyways, with a main-function at the top calling other functions which call other functions. But OOP adds a layer to that, i.e. objects, and encourages to do all function calls between objects. You don't want to do that in Rust. You kind of have to write simpler code for it to fall into place.

To make it a bit more concrete:
You will have functions which hold ownership over some data, typically because they instantiated a struct. These sit at the root of a sub-tree, where you pass access to this data down into further functions by borrowing it to them.

You don't typically want to pass ownership all over the place, nor do you typically want to borrow (or pass references) to functions which are not part of this sub-tree.
Of course, there's situations where this isn't easily possible, e.g. when having two independent threads talking to each other, and then you do need Rc or Arc, but yeah, the vast majority of programming problems can be solved with trees of function calls.

Go is really good for std library, windows and Linux from same code and static binaries BTW.

It's nice that this exists these days, but my god is it horrendously unreadable at a glance

That is completely incomprehensible lol

Is there a way to avoid having to write copy and move twice every time yet?

It's because people put in the hard work of writing amazing macros instead of baking code reuse into the type system itself 😁 I'm a rust noob and I love the derive macro.

Yes, it is that simple. In Rust if you have a structure Person and you want to allow testing equality between instances, you just add that bit of code before the struct definition as follows:

#[derive(PartialEq, Eq)]
struct Person {
    name: String,
    age: u32,
}

In Rust, PartialEq and Eq are traits, which are similar to interfaces in Java. Manually implementing the PartialEq trait in this example would be writing code that returns something like a.name == b.name && a.age == b.age. This is pretty simple but with large data structures it can be a lot of boilerplate.

There also exist other traits such as Clone to allow creating a copy of an instance, Debug for getting a string representation of an object, and PartialOrd and Ord for providing an ordering. Each of these traits can be automatically implemented for a struct by adding #[derive(PartialEq, Eq, Clone, Debug, PartialOrd, Ord)] before it.

Derive macros are a godsend. There's macros to automatically implement serialization as well. Basically a Trait that can automatically be implemented when derived

Ahh, the comment I was looking for

I would have also accepted: "Haskell did it first."

OCaml has ppx_deriving. PureScript has derive instance.

Newer Scala follows the same when enabling strict equaility. It's a good thing.

The first iteration of the Rust compiler was written in OCaml...

Don't need the Ord instance for equality, just Eq is sufficient. Ord is for inequalities.

The point of the post is that most mainstream languages don't provide a way to automatically derive point-wise equality by value, even though it's pervasively used everywhere. They instead need IDEs to generate the boilerplate rather than the compiler handling it.

Yeah, I came to Rust from Scala and Kotlin, where equality is default-implemented (for case class and data class respectively, which is basically all we ever used), so this meme surprised me a bit.

I do actually like that you can decide a type cannot be compared, because sometimes it really just doesn't make sense. How would you compare two HTTP clients, for example? But yeah, it certainly is a choice one can disagree with.

NaN != NaN

I always hated the implementation for .toString() of Duration. It gives you a string like that: PT8H6M12.345S (not a hash)

Apparently, it's an ISO 8601 thing, but what the hell am I supposed to do with that?
It's not useful for outputting to end users (which is fair enough), but I don't even want to write that into a log message.
I got so used to this just being garbage that I would automatically call .toMillis() and write "ms" after it.

Well, and not to gush about Rust too much, but I recently learned that its debug string representation is actually really good. As in, it's better than my Java workaround, because it'll even do things like printing 1000ms as 1s.
And that's just like, oh right, libraries can actually provide a better implementation than what I'll slap down offhandedly.

In Python it's really hard!

def __eq__(self, other):
    ...

How do you even write those subscripted hyphens???

It's not hard, just if you're doing it for a struct with a lot of fields it's a lot of boilerplate

Then you should also override Equals(object), GetHashCode, and implement IEquatable<T>.

Thankfully a lot of the usual boilerplate code can be avoided using a record class or struct:

public record Person(string Name, uint Age);