docs: Add new journal entries and Rust documentation

- Created a journal entry for December 12, 2025, documenting insights on Rust study topics including references, borrowing, and ownership errors.
- Added detailed pages on Rust async programming and closures, explaining key concepts and syntax.
- Included links to relevant chapters from "The Rust Programming Language" for further reading.

Author: codekiln

journals/2025_12_12.md

@@ -0,0 +1,8 @@
+- [[Rust]] study
+	- [[Rust/Book/TRPL/ch/04/02 References and Borrowing]]
+		- I'm now starting to understand why for a perfectionist's language, Rust code tends to be less [[DRY]] than some other languages like [[Haskell]].
+	- [[Rust/Book/TRPL/ch/04/03 Fixing Ownership Errors]]
+	- [[Langstar]] development
+		- This morning I got in early and had two or three tries at using [[Git Worktrees]] to do work with [[Claude Code]]. Even though I've been relatively successful lately using a [[DevContainer]] to do 3-5 trees, I'm finding that docker and the devcontainer crash more and more when I'm doing unattended coding on Rust. I think it might have to do with rust extensions doing type checking in the IDE on the various worktrees while the source code is changing, and Docker bumping into its memory limit. But I'm a bit surprised that 16 GB of [[RAM]] wasn't enough. It could also have to do with switching to [[Cargo/nexttest]], which has a higher CPU burden. With one worktree active in claude code, I'm at 5.34 GB of container memory usage. Within 10 min it was up to 10GB.
+	- [[Rust/Closure]]
+	- [[Rust/async]]

pages/Rust___Book___TRPL___ch___04___02 References and Borrowing.md

@@ -0,0 +1,2 @@
+- [References and Borrowing - The Rust Programming Language](https://rust-book.cs.brown.edu/ch04-02-references-and-borrowing.html)
+	-

pages/Rust___Book___TRPL___ch___04___03 Fixing Ownership Errors.md

@@ -0,0 +1,2 @@
+- [Fixing Ownership Errors - The Rust Programming Language](https://rust-book.cs.brown.edu/ch04-03-fixing-ownership-errors.html)
+	-

pages/Rust___Closure.md

@@ -0,0 +1,60 @@
+# Rust Closure - `| x |`
+	- via [[Langstar/PR]] [🧪 test(project): add comprehensive tests for project commands by codekiln · Pull Request #709 · codekiln/langstar](https://github.com/codekiln/langstar/pull/709/changes)
+	- ## Basic Idea
+		- In this code:
+			- ```rust
+			  let found = projects.iter().any(|p| {
+			          p.get("id")
+			              .and_then(|v| v.as_str())
+			              .map(|id| id == project_id.to_string())
+			              .unwrap_or(false)
+			      });
+			  ```
+		- `|v|` is just the parameter list for a **closure** in Rust.
+		- ### What this closure is
+			- `and_then` takes a function that receives the inner value of an `Option`.
+			  In this case, `p.get("id")` returns an `Option<&Value>` (`serde_json::Value`).
+			- So `and_then(|v| v.as_str())` means:
+			- If the option is `Some(v)`, call `v.as_str()`.
+			- If the option is `None`, skip the closure and return `None`.
+		- ### What  `|v|`  means specifically
+			- `| ... |` is the syntax for closure parameters.
+			  Inside the bars goes the argument list:
+			- `|v|` → one argument named `v`
+			- `|a, b|` → two arguments
+			- `||` → no arguments
+			- The body follows after the `|...|`.
+		- ### Full semantics
+			- `|v| v.as_str()` is roughly equivalent to writing:
+				- ```rust
+				  fn temp(v: &serde_json::Value) -> Option<&str> {
+				    v.as_str()
+				  }
+				  ```
+			- …but inline and anonymous.
+		- ### Summary
+			- `|v|` is simply the closure argument list.
+			  The whole expression applies a closure to the `Some(v)` branch of the `Option`, transforming `Option<&Value>` into `Option<&str>` by calling `.as_str()` on the JSON value.
+	- ## What if `p.get("id")` is `false`?
+		- In the selected block:
+			- ```rust
+			  projects.iter().any(|p| {
+			      p.get("id")
+			          .and_then(|v| v.as_str())
+			          .map(|id| id == project_id.to_string())
+			          .unwrap_or(false)
+			  })
+			  ```
+				- If `p.get("id")` is `None`, here is the exact flow:
+					- `p.get("id")` → `None`
+					- `None.and_then(|v| v.as_str())` → still `None`
+					- `None.map(|id| ...)` → still `None`
+					- `None.unwrap_or(false)` → returns **false**
+		- So the closure returns **false**, meaning that this `p` does *not* match.
+		- ### Why this works
+			- It’s using the `Option` combinators as a pipeline:
+			- `get("id")` fetches the JSON field (or not).
+			- `and_then` ensures the value is actually a string.
+			- `map` performs the equality check if possible.
+			- `unwrap_or(false)` means: *if anything in the chain failed, treat as no match*.
+			- The `any()` call only returns `true` if at least one project has an `"id"` that matches.

pages/Rust___async.md

@@ -0,0 +1,74 @@
+- # Rust async
+	- Here's a clean, Rust-native explanation of the selected line and the constructs involved.
+	- ## 🔍 The selected line
+		- ~~~rust
+		  let _cleanup = runtime.block_on(async { client.delete_project(project_id).await });
+		  ~~~
+		- This combines **four** concepts:
+			- **`async { ... }` block**
+			- **`.await` operator**
+			- **A future value**
+			- **A synchronous executor call (`block_on`)**
+		- Let's break those down.
+	- ## 1. `async { ... }` — an async block expression
+		- `async { ... }` is an **expression** that returns a *future* — specifically an *anonymous type that implements `Future<Output = T>`*.
+		- Inside an async block, you can use `await`, but the block itself **does not run** until something *polls* the future (usually an executor).
+		- It is similar to:
+			- ~~~rust
+			  async fn foo() -> T { ... }
+			  ~~~
+			- but inline.
+		- Other Rust constructs that work the same way (i.e., block forms that produce values) include:
+			- `unsafe { ... }`
+			- `const { ... }`
+			- `try { ... }` (unstable; returns `Result`)
+			- `loop { ... }`, `if { ... }`, etc., because *blocks are expressions*
+		- Rust's rule: **Blocks are expressions that evaluate to the last expression inside.**
+		- So the async block:
+			- ~~~rust
+			  async {
+			    client.delete_project(project_id).await
+			  }
+			  ~~~
+			- produces a future whose output type is whatever `.await` returns — here likely `Result<(), SomeError>` or whatever the API defines.
+	- ## 2. What is `.await`?
+		- `.await` is **neither a method nor a property** — it is a **postfix operator built into the language parser**, like `?`.
+		- It transforms a `Future<Output = T>` into a `T`, *but only inside an async context*.
+		- If you want an analogy:
+			- It is like Python `await f()`, **but syntactically resembles a field access** (`obj.field`).
+			- Under the hood, it compiles down to state-machine code that polls the future and suspends.
+		- Its "type"?
+			- The expression:
+				- ~~~rust
+				  some_future.await
+				  ~~~
+				- has the type **`T`**, where the original future was `Future<Output = T>`.
+	- ## 3. The sequence of evaluation
+		- Your full line:
+			- ~~~rust
+			  let _cleanup = runtime.block_on(async { client.delete_project(project_id).await });
+			  ~~~
+			- ⚙️ *Steps:*
+				- `async { ... }` creates a future of type `impl Future<Output = DeleteResult>`.
+				- `runtime.block_on(...)` takes that future and **runs it to completion**, turning async → sync.
+				- The result of the `.await` inside is returned out of the async block.
+				- That value becomes `_cleanup`.
+	- ## 4. Are there other parts of Rust with similar syntax?
+		- Yes — Rust has several "block operators" and "postfix operators":
+			- ### **Block expressions:**
+				- `async { … }` — future-producing
+				- `unsafe { … }` — unsafe block
+				- `try { … }` — result-producing block (unstable)
+				- `const { … }` — const-evaluated block (stable)
+				- `{ … }` plain blocks
+			- ### **Postfix operators (built-in, not methods):**
+				- `.await`
+				- `?`
+				- Array indexing (`arr[idx]`)
+				- Deref and reference are prefix/suffix but part of expression syntax, not methods.
+		- These are all *language-level constructs*, unlike Python where most constructs desugar into method calls.
+	- ## Quick mental model
+		- **`async { ... }`** → "Create a future value."
+		- **`.await`** → "Extract the future's output; pause until ready."
+		- **`block_on(fut)`** → "Drive the future to completion from sync code."
+		- You can think of `.await` like Python `await`, **but it is not a function or property — it is language syntax.**