> I'd add a recommendation at the top of this to have a Rust compiler handy.
If you haven't already, check out the Playground: https://play.rust-lang.org/
It's reasonably full-featured for a web IDE (much more so than the Go playground), and it includes many commonly used packages.
> Because on my screen in non-dark mode...
The little sun icon in the lower left corner of the page turns on dark mode! Hopefully that helps.
> I don't understand why b=a; c=a; This is something called "linear typing", and it's admittedly pretty unusual in a mainstream language.
The core idea is that the assignment operator _only ever_ creates a "shallow" (bitwise) copy of data; it never invokes anything like C++'s copy assignment operator. For types that are "plain old data" (like primitives), the old and the new values are fully independent, so the assignment works the same way it would in most languages, i.e., `a` is not "used up". This is what other commentors mean when they say that primitives "implement `Copy`". But if the old value has pointers or references, then the two values are not independent: after the bitwise copy, they both have pointers to the same data. Since data can only ever be shared explicitly in Rust, and the assignment operator never performs a deep copy, the old value, `a`, is considered invalid and cannot be re-used.
If you're familiar with C++11 or later, one way to think of it is that `=` in Rust always behaves somewhat like `std::move` in C++:
`b = std::move(a);`
The details are substantially different (this will call `a`'s move-assignment operator if one exists, which has no equivalent in Rust, and C++ offers no support for ensuring that `a` is no longer used if its move-assignment operator invalidates it). But the general idea that "move semantics are on by default" is essentially accurate.