When you create an instance of a struct and assign it to a variable or field of another struct, that variable becomes the owner of that value. When you assign it to some other variable or pass it to a function that takes ownership, ownership will move. Otherwise, you will borrow. But there will always only be one owner for each value. That way you know exactly when to free up memory: whenever the owner is dropped.
You can store references in another structure, but you probably don't want to do this most of the time, since it's a major headache to get ownership and lifetimes right. You shouldn't think of references as pointers, but you should think of them as "borrows": you are temporarily borrowing something from the owner, but you can only do so if the owner exists. So you need to statically guarantee that for as long as you borrow it, the owner must be alive, which gets tricky when you store that borrow somewhere in some data structure. In practice, references or borrows will be short-lived, and most operations on data will be done by the owner of that data.
Underneath, references are represented by pointers, but you shouldn't think of them as pointers, but rather as something you have borrowed, so in that sense it's different from C.
Also, Python does use references everywhere, it's just implicit, and depends on the type. Try storing a list in a class: you've just stored a reference to another structure. Most things (e.g. lists, objects) are passed and stored by reference, some types like integers are copied. In Rust, you can choose whether you want to pass by reference, copy or move ownership. At this point we're still at a high level of abstraction, we don't think so much about whether this will be pointers at the low level.
But my main point is that whether you use pointers, references, or whether it's implicit or explicit doesn't make a language slow or fast, it just defines how programs are written. Rust is very fast because it's compiled to machine code and doesn't do garbage collection or have any other overhead from a "runtime". Python is relatively slow because it's interpreted. You could argue that more manual control over references/pointers can make a language faster, but it's not the main contributing factor.
I would argue that on the one hand you could say that the references to objects in garbage collected languages are also pointers.
On the other hand, you could argue that such references are not pointers, but then you might as well argue that references in rust are not pointers.
I just feel like "a language with pointers" is a weird way to describe a language and it isn't really something that causes the language to become fast. Pointers are low level constructs that are used all the time, and whether or not they are abstracted away in the high level language doesn't automatically make it slow or fast.
Trackmania Turbo has never really had an active online community. The new Trackmania game called "Trackmania" is the most popular one, but you need to pay €10 each year to access most features.
Why the hate against lemmygrad? Just let them have their opinion. Have they done anything wrong to you personally? No? Then let them be. At least this is how I like to think about it.
Also, are we really going to start witch hunts for instances that federate with an instance that you don't like?
I don't think his political views are relevant in the first place. As long as he's a great developer and nice to work with, there is no problem for Lemmy and its users.
People really need to stop doing this thing where they disagree with something someone says just to discredit everything else that person does.
I was already able to deploy it on my Raspberry PI 4 without any issues. It was using a lot of CPU when joining large rooms, but now it seems to have calmed down and it's using 1-2% CPU, which is very reasonable. In comparison, home assistant runs at around 2-3% idle, and lemmy fluctuates between 4% and 10%.
Thanks for bringing this up, this is great! It's also written in Rust, and I love Rust, so I might contribute this summer. I'll add it to my list of potential project to contribute to, along with Lemmy.
Updates can't really break anything, and if something would go wrong, I can simply boot on the previous image, which will still be there. They can also happen in the background, such that I don't even know it's updating. It just happens and never bothers me.
What's even more interesting is that you can rebase on another base image without having to worry. If I don't like it, I can just go back to the previous image. With ublue, you can even customize your own OS image.
I believe modern Android uses a similar concept. They use two partitions, and install an update to the other image while your phone is running normally. Then all you need to do is reboot, and you'll be on the new boot image.
When you create an instance of a struct and assign it to a variable or field of another struct, that variable becomes the owner of that value. When you assign it to some other variable or pass it to a function that takes ownership, ownership will move. Otherwise, you will borrow. But there will always only be one owner for each value. That way you know exactly when to free up memory: whenever the owner is dropped.