Problem with the Rust demo last time:
	I forgot the second parameter of open
		Oddly enough, that problem had nothing to do with Rust
		But the compiler would have found it if I hadn't been using Rust

The Rust team considers parallel programming problems to be memory problems
	Can be solved with memory ownership, etc
	Are they actually memory and object ownership problems?
	Note:  Concurrent vs. Parallel
		Parallel actually happens at the same time
		Concurrent doesn't have to (network server, etc)

Message passing vs. shared state
	Message passing:  A thread sends a message to another thread
		A thread can wait for a particular message
	Shared state:  Threads share a memory area
		This shared memory area can contain mutexes, heap allocations, etc.

Very simple demo with race condition

We can join threads, like pthreads does
	Meaning of "unwrap"
		Get result, panic if it was an error instead
		Very useful for errors that should crash the program

Closures:  Useful to pack a parameter into a thread

Rust book example on borrowing for a thread:
	drop will disown a heap value
		What if it's nowhere else?
	move, in the closure, will preserve it

If we need more than one reference:
	Arc - Atomic Reference Counting
	Can be combined with a mutex
		Then you have a mutex-protected reference-counted data structure
		That seems to be the way Rust wants shared memory to work

Combining the mutex and the reference does mean one mutex per structure
	Could make a more elaborate object than I did
	Prevents access without locking the mutex