1 files changed, 53 insertions, 0 deletions
diff --git a/docs/umich/w25_491_journal.md b/docs/umich/w25_491_journal.md
new file mode 100644
index 0000000..c9e25ab
--- /dev/null
+++ b/docs/umich/w25_491_journal.md
@@ -0,0 +1,53 @@
+# Winter 2025 Course Journal: EECS 491
+
+Course Title: Distributed Systems
+
+## Motivation
+
+This is one of the only three upper-level courses that doesn't conflict
+with my schedule. Also, Brian Noble is one of my favorite professors.
+
+When he was teaching 482, Brian brings up 491 sometimes, and if he teaches
+it, it has to be good. Although I'm not a software person, it might come
+useful in designing a mesh of embedded systems.
+
+## Go language
+
+I wrote a little bit of Go in high school but it was nothing serious.
+
+Brian said we use Go because it was invented at Google to power their
+distributed systems, concurrency and all that stuff. He also emphasized we
+were to write "idiomatic Go", which means making use of strengths in the
+language.
+
+Being C-like makes it easy to pick up, but there's new stuff. So far, my
+favorite thing is the `for ... select` loop and it's incredibly cool.
+
+Over the winter I've been doing an embedded project in C++ with FreeRTOS.
+In FreeRTOS, one way to block a task until data shows up is to receive
+from a queue. The problem is, I need to wait for three events (represented
+as three structs), but you can only shove one type in a queue. So what
+I ended up doing is write a wrapper struct with an event type and
+a pointer, which I then cast to various types based on event type.
+
+With Go, each queue would be a channel, and you could wait for three all
+at once.
+
+The `go` keyword in go spawns a goroutine, which is basically like
+spawning a thread, but safer and cheaper.
+
+Another big thing that's different from the C world, namely 482, is that
+we're forbidden from using mutexes or any low-level synchronization
+mechanism. We're also cautioned against passing values by pointer to two
+concurrent processes. Copying a couple kilobytes is negligible compared to
+network roundtrips.
+
+## Non-deterministic behavior
+
+I've taken 482, so I'm familiar with programs where things happen in
+a different order each time. And I know that, if there is more than one
+thing in a pool, you cannot predict which one is getting out first. This
+can lead to non-deterministic behavior, and that's ok as long as it's in
+the set of "allowed" non-deterministic behaviors. This reminds me of a Tom
+Scott video that explains why computers "can't count", e.g. why the number
+of upvotes on a Reddit post changes every time you refresh.