I think part of what makes programming languages hard to learn is that two authors rarely can agree on the same terminology. Reading a mixture of sources can lead to confusion about what's going on.

This article explains the uniqueness/mutability relation well, but it uses the terms "variable" and "value" with different meanings than most programmers would use. What the article calls "value" I would call "memory location" (maybe one could even call it "variable"); and what it calls "variable" isn't 100% accurate but I guess it works to keep the explanation simple.

UnsafeCell (a wrapper for all the hacky unsafe memory access) is such a great idea. This allows rest of the program to be easier to statically analyze. For everything not in it, the compiler can assume it respects strict aliasing and immutability without any gotchas. If UnsafeCell didn't exist it, it would be unclear where the programmer really meant to allow data races or poke holes in immutability, etc.

Maybe add a (2019) to the title?

as a language designer.. im still stuck wether ownership is a good or bad idea. I like ownership because that's how we handle things in the real world. Eg. 2 people grabbing potato chips out of a bag at the same time is a bad idea. We pass the bag along. wait turns. But for some reason, we dont do this with computer programs. So.. should we do this with computers or not? Feel free to reply.

My instinct says 'yes'. But i also have a feeling that im going to run into problems that current languages dont have. Such as being forced to copy data or have complex systems like in rust to make the compiler happy.

Does Rust provide support for low level synchronisation related operations such as memory fences? If so is there any way relying on these can break data race freedom (which as I understand Rust guarantees)?