Skip to content

Commit 40caede

Browse files
committed
docs: Add new Rust concepts and journal entries
- Created new journal entry for December 10, 2025, linking to key Rust concepts including Heap, Stack, and Ownership. - Added detailed pages for Heap and Stack memory concepts, explaining their mechanisms, principles, and misconceptions. - Introduced a page for Ferris the Crab, the unofficial mascot of Rust, and its significance within the Rust community. - Updated the Ownership page to clarify the relationship between ownership and heap memory management in Rust.
1 parent 2b9bb3b commit 40caede

9 files changed

+270
-19
lines changed

journals/2025_12_10.md

Lines changed: 9 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,9 @@
1+
- [[Programming/Concept/Heap]]
2+
- [[Programming/Concept/Stack]]
3+
- [[Rust/Owner/ship]]
4+
- [[Rust/Book/TRPL/ch/04/01 What is Ownership]]
5+
- [[LOL]] [[TIL]] Rust uses the word [[Rustic]] for "idiomatic rust"
6+
- > These conceptual foundations should help you with interpreting Rust’s error messages. They should also help you ==design more [[Rustic]] APIs==.
7+
- [[Rust/Ferris]] is the "little crab guy" that's the unofficial mascot of Rust
8+
- [[Rust/Energy]]
9+
-
Lines changed: 51 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,51 @@
1+
tags:: [[Programming]], [[Diataxis/Explanation]]
2+
3+
- # Heap Conceptual Overview
4+
- ## Overview
5+
- The heap is a region of memory used for dynamic memory allocation
6+
- Unlike the stack, heap memory is not automatically managed by the program's execution flow
7+
- Allows for flexible allocation and deallocation of memory at runtime
8+
- Memory allocated on the heap persists until explicitly freed or garbage collected
9+
- ## Context
10+
- **Memory Management Need**: Programs need memory that can outlive function calls and vary in size at runtime
11+
- **Historical Development**: Heap memory management has been a core concern since early programming languages
12+
- **Modern Relevance**: Critical for understanding memory safety, performance, and resource management in systems programming
13+
- Addresses the need for data structures whose size is unknown at compile time or that must persist beyond the current scope
14+
- ## Key Principles
15+
- **Dynamic Allocation**: Memory is allocated at runtime, not at compile time
16+
- **Manual or Automatic Management**: Depending on the language, heap memory may require manual deallocation or be managed automatically
17+
- **Persistence**: Heap-allocated memory persists until explicitly freed or garbage collected
18+
- **Flexible Size**: Can allocate variable-sized blocks of memory as needed
19+
- **Slower Access**: Generally slower than stack access due to pointer indirection and potential fragmentation
20+
- ## Mechanism
21+
- Heap memory is managed by the runtime system or operating system
22+
- Allocation typically involves:
23+
- Requesting a block of memory of a specific size
24+
- The memory allocator finds available space
25+
- Returns a pointer to the allocated memory
26+
- Deallocation can be:
27+
- **Manual**: Programmer must explicitly free memory (C, C++, Rust)
28+
- **Automatic**: Garbage collector reclaims unused memory (Java, Python, Go)
29+
- Memory fragmentation can occur when blocks are allocated and freed in different orders
30+
- ## Examples
31+
- ### Manual Memory Management
32+
- **C/C++**: Use `malloc()`/`free()` or `new`/`delete`
33+
- **Rust**: Uses ownership system to automatically manage heap memory through types like `Box<T>`
34+
- ### Automatic Memory Management
35+
- **Java, Python, Go**: Garbage collectors automatically reclaim unused heap memory
36+
- **Swift**: Uses Automatic Reference Counting (ARC) to manage heap memory
37+
- ### Common Heap-Allocated Types
38+
- Dynamic arrays and vectors
39+
- Strings (in many languages)
40+
- Objects and structs that need to outlive their creation scope
41+
- Large data structures
42+
- ## Misconceptions
43+
- Heap is always slower than stack → **Context-dependent**. Heap access involves indirection, but for large or long-lived data, the heap is appropriate
44+
- All languages require manual heap management → **False**. Many modern languages provide automatic garbage collection
45+
- Heap memory is unlimited → **False**. Heap size is limited by available system memory and runtime constraints
46+
- Heap and stack are physical locations → **False**. They are logical memory regions that may be implemented in various ways
47+
- ## Related
48+
- [[Programming/Concept/Stack]] - The stack, which contrasts with heap memory
49+
- [[Rust/Box]] - Rust's heap-allocated pointer type
50+
- [[Rust/Owner/ship]] - How Rust manages heap memory through ownership
51+
Lines changed: 59 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,59 @@
1+
tags:: [[Programming]], [[Diataxis/Explanation]]
2+
3+
- # Stack Conceptual Overview
4+
- ## Overview
5+
- The stack is a region of memory used for automatic, temporary storage during program execution
6+
- Follows a Last-In-First-Out (LIFO) structure
7+
- Automatically managed by the program's execution flow
8+
- Memory is allocated when entering a function scope and deallocated when leaving it
9+
- ## Context
10+
- **Execution Model**: The stack is fundamental to how function calls and local variables are managed
11+
- **Historical Development**: Stack-based execution has been a core feature of programming languages since the early days
12+
- **Modern Relevance**: Essential for understanding function calls, recursion, local variables, and memory management
13+
- Provides automatic, efficient memory management for temporary data that follows a predictable lifetime pattern
14+
- ## Key Principles
15+
- **LIFO Structure**: Last item pushed is the first item popped
16+
- **Automatic Management**: Memory is automatically allocated and freed based on scope
17+
- **Fast Access**: Stack memory is typically faster to access than heap memory
18+
- **Limited Size**: Stack size is usually smaller and more constrained than heap
19+
- **Scope-Based Lifetime**: Variables live only within their defining scope
20+
- **Predictable Layout**: Stack frames are organized in a predictable, sequential manner
21+
- ## Mechanism
22+
- When a function is called:
23+
- A new stack frame is pushed onto the stack
24+
- Local variables and parameters are stored in this frame
25+
- Return address is stored for when the function completes
26+
- When a function returns:
27+
- The stack frame is popped
28+
- All local variables in that frame are automatically deallocated
29+
- Execution returns to the calling function
30+
- Stack pointer tracks the current top of the stack
31+
- Stack overflow occurs when the stack grows beyond its allocated size (often from deep recursion)
32+
- ## Examples
33+
- ### Function Calls
34+
- Each function call creates a new stack frame
35+
- Local variables are stored in the current stack frame
36+
- When the function returns, its frame is removed
37+
- ### Recursion
38+
- Each recursive call adds a new stack frame
39+
- Deep recursion can cause stack overflow
40+
- ### Common Stack-Allocated Types
41+
- Local variables
42+
- Function parameters
43+
- Return addresses
44+
- Small, fixed-size data structures
45+
- ### Language Examples
46+
- **C/C++**: Local variables are typically stack-allocated
47+
- **Rust**: Most values are stack-allocated by default
48+
- **Python**: Function call frames use a stack structure
49+
- ## Misconceptions
50+
- Stack is always faster than heap → **Generally true, but context matters**. Stack is faster for small, short-lived data
51+
- All variables go on the stack → **False**. Large or dynamically-sized data often goes on the heap
52+
- Stack size is unlimited → **False**. Stack size is limited and stack overflow is a real concern
53+
- Stack and heap are physical locations → **False**. They are logical memory regions with different management strategies
54+
- Stack frames are only for function calls → **False**. Stack frames can also contain exception handling information and other execution context
55+
- ## Related
56+
- [[Programming/Concept/Heap]] - The heap, which contrasts with stack memory
57+
- [[Rust/Variable]] - How Rust uses the stack for variable storage
58+
- [[Programming/Time/Run]] - Runtime behavior including stack management
59+
Lines changed: 64 additions & 19 deletions
Original file line numberDiff line numberDiff line change
@@ -1,6 +1,6 @@
11
- [What is Ownership? - The Rust Programming Language](https://rust-book.cs.brown.edu/ch04-01-what-is-ownership.html)
2-
- [[Rust/Variable]]s by live in the scope of function's stack, and are deallocated at the end of the function.
3-
- [[Rust/Box]]es, in contrast, live in the heap.
2+
- [[Rust/Variable]]s by live in the scope of function's [[Programming/Concept/Stack]], and are deallocated at the end of the function.
3+
- [[Rust/Box]]es, in contrast, live in the [[Programming/Concept/Heap]].
44
- Internally, [[Rust/Collection]]s like [[Rust/Vec]] and [[Rust/String]] use `Box`es.
55
- Rust is unique because it does not permit manual memory management.
66
- [[Rust/Variable]]s cannot be used after being moved.
@@ -14,25 +14,70 @@
1414
}
1515
```
1616
- To get around this, you can clone the string so there are two copies.
17-
- [[Rust/Ownership]] comes into play in the difference between these two phrases:
17+
- [[Rust/Owner/ship]] comes into play in the difference between these two phrases:
1818
- **Box deallocation principle (almost correct):** if a variable **is bound to** a `Box`, when rust deallocates the variable's frame, then Rust deallocates the box's heap memory.
1919
- **Box deallocation principle (fully correct):** if a `Box` **is owned by** a variable, when Rust deallocates the variable's frame, then Rust deallocates the Box's heap's memory.
2020
- Here ownership refer s to how variables can fall out of scope.
2121
- None of the following example compile;
22-
- ```rust
23-
// example 1
24-
let b = Box::new(0);
25-
let b2 = b; // this is okay
26-
move_a_box(b); // not okay: Box is not owned by b
27-
28-
// example 2
29-
let b = Box::new(0);
30-
move_a_box(b); // Box passed to func. when done, rust deallocates its mem
31-
println!("{}", b); // Box is not owned by b
32-
33-
// example 3
34-
let b = Box::new(0);
35-
move_a_box(b); // Box passed to func. when done, rust deallocates its mem
36-
let b2 = b; // box is not owned by b
37-
```
22+
- ```rust
23+
// example 1
24+
let b = Box::new(0);
25+
let b2 = b; // this is okay
26+
move_a_box(b); // not okay: Box is not owned by b
27+
28+
// example 2
29+
let b = Box::new(0);
30+
move_a_box(b); // Box passed to func. when done, rust deallocates its mem
31+
println!("{}", b); // Box is not owned by b
32+
33+
// example 3
34+
let b = Box::new(0);
35+
move_a_box(b); // Box passed to func. when done, rust deallocates its mem
36+
let b2 = b; // box is not owned by b
37+
```
38+
- Here's an example of the compilation error for the first one:
39+
- code
40+
- ```rust
41+
42+
fn move_a_box(b: Box<i32>) {
43+
println!("b in move_a_box: {b}");
44+
}
45+
46+
fn main() {
47+
let b = Box::new(0);
48+
println!("b: {b}");
49+
let b2 = b;
50+
println!("b2: {b2}");
51+
// works at this line
52+
move_a_box(b2);
53+
// but if you include the next line,
54+
// this will cause compiler error
55+
move_a_box(b);
56+
}
57+
58+
```
59+
- rust panic on compile if last line `move_a_box(b);` is kept in:
60+
- ```rust
61+
error[E0382]: use of moved value: `b`
62+
--> exercises/ch04-01-ownership/src/main.rs:12:16
63+
|
64+
7 | let b = Box::new(0);
65+
| - move occurs because `b` has type `Box<i32>`, which does not implement the `Copy` trait
66+
8 | println!("b: {b}");
67+
9 | let b2 = b;
68+
| - value moved here
69+
...
70+
12 | move_a_box(b);
71+
| ^ value used here after move
72+
|
73+
help: consider cloning the value if the performance cost is acceptable
74+
|
75+
9 | let b2 = b.clone();
76+
| ++++++++
77+
78+
For more information about this error, try `rustc --explain E0382`.
79+
error: could not compile `ch04-01-ownership` (bin "ch04-01-ownership") due to 1 previous error
80+
```
81+
- See [[Rust Ownership]] for a summary
82+
-
3883
-

pages/Rust___Energy.md

Lines changed: 32 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,32 @@
1+
- via [That is why you and I should be Rustaceans | KBTG Life](https://medium.com/kbtg-life/that-is-why-you-and-i-should-become-rustaceans-31ddd212e52f)
2+
- [Ranking programming languages by energy efficiency - ScienceDirect](https://www.sciencedirect.com/science/article/pii/S0167642321000022)
3+
- [Table 4. Normalized global results for Energy, Time, and Memory.](https://www.sciencedirect.com/science/article/pii/S0167642321000022#sp0170)
4+
- | Empty Cell | Energy (J) | Empty Cell | Time (ms) | Empty Cell | Mb |
5+
| ---- | ---- | ---- |
6+
| (c) C | 1.00 | (c) C | 1.00 | (c) Pascal | 1.00 |
7+
| (c) Rust | 1.03 | (c) Rust | 1.04 | (c) Go | 1.05 |
8+
| (c) C++ | 1.34 | (c) C++ | 1.56 | (c) C | 1.17 |
9+
| (c) Ada | 1.70 | (c) Ada | 1.85 | (c) Fortran | 1.24 |
10+
| (v) Java | 1.98 | (v) Java | 1.89 | (c) C++ | 1.34 |
11+
| (c) Pascal | 2.14 | (c) Chapel | 2.14 | (c) Ada | 1.47 |
12+
| (c) Chapel | 2.18 | (c) Go | 2.83 | (c) Rust | 1.54 |
13+
| (v) Lisp | 2.27 | (c) Pascal | 3.02 | (v) Lisp | 1.92 |
14+
| (c) Ocaml | 2.40 | (c) Ocaml | 3.09 | (c) Haskell | 2.45 |
15+
| (c) Fortran | 2.52 | (v) C# | 3.14 | (i) PHP | 2.57 |
16+
| (c) Swift | 2.79 | (v) Lisp | 3.40 | (c) Swift | 2.71 |
17+
| (c) Haskell | 3.10 | (c) Haskell | 3.55 | (i) Python | 2.80 |
18+
| (v) C# | 3.14 | (c) Swift | 4.20 | (c) Ocaml | 2.82 |
19+
| (c) Go | 3.23 | (c) Fortran | 4.20 | (v) C# | 2.85 |
20+
| (i) Dart | 3.83 | (v) F# | 6.30 | (i) Hack | 3.34 |
21+
| (v) F# | 4.13 | (i) JavaScript | 6.52 | (v) Racket | 3.52 |
22+
| (i) JavaScript | 4.45 | (i) Dart | 6.67 | (i) Ruby | 3.97 |
23+
| (v) Racket | 7.91 | (v) Racket | 11.27 | (c) Chapel | 4.00 |
24+
| (i) TypeScript | 21.50 | (i) Hack | 26.99 | (v) F# | 4.25 |
25+
| (i) Hack | 24.02 | (i) PHP | 27.64 | (i) JavaScript | 4.59 |
26+
| (i) PHP | 29.30 | (v) Erlang | 36.71 | (i) TypeScript | 4.69 |
27+
| (v) Erlang | 42.23 | (i) Jruby | 43.44 | (v) Java | 6.01 |
28+
| (i) Lua | 45.98 | (i) TypeScript | 46.20 | (i) Perl | 6.62 |
29+
| (i) Jruby | 46.54 | (i) Ruby | 59.34 | (i) Lua | 6.72 |
30+
| (i) Ruby | 69.91 | (i) Perl | 65.79 | (v) Erlang | 7.20 |
31+
| (i) Python | 75.88 | (i) Python | 71.90 | (i) Dart | 8.64 |
32+
| (i) Perl | 79.58 | (i) Lua | 82.91 | (i) Jruby | 19.84 |

pages/Rust___Ferris.md

Lines changed: 37 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,37 @@
1+
# Ferris the Crab
2+
- mascott of Rust
3+
- ![Ferris the Crab](https://c.tenor.com/4GZQk1XepvYAAAAd/tenor.gif){:height 320, :width 393}
4+
- ## Why a crab?
5+
- ### 🦀 [[Rustaceans]]
6+
- Rust community members often jokingly call themselves **Rustaceans** — a play on *crustacean*. If the people are Rustaceans, the mascot being a crustacean (crab) fits perfectly.
7+
- ### 🦀 Ferris = “Ferri-cious” pun
8+
- The name *Ferris* comes from *ferrous* (relating to iron), since *rust* is oxidized iron. So:
9+
- **Rust → iron → ferrous → Ferris.**
10+
- And Ferris just happened to be designed as an adorable crab.
11+
- ### 🦀 Crabs are “safe”
12+
- There’s also a cute metaphor floating around: crabs have a **hard shell** (safety) and **claws** (power) — mirroring Rust’s safety-and-control philosophy.
13+
- ## History
14+
- Ferris was created by [[Person/Karen Rustad Tolva]] (formerly Karen Rustad), an early member of the Rust community, around [[2015]]
15+
- ## **Design Philosophy**
16+
- Ferris was intentionally:
17+
- **Friendly**, not fierce
18+
- **Gender-neutral**
19+
- **CC-BY licensed** so the community could remix and use it freely
20+
- Drawn in a **simple, expressive vector style** that works at many sizes
21+
- Ferris quickly became a symbol of Rust’s welcoming culture, especially important given Rust’s mission to make systems programming feel approachable.
22+
- ## **Canonical Traits of Ferris**
23+
- Always smiling or expressive
24+
- Small legs, big claws
25+
- Orange body
26+
- No sharp angles or threatening posture
27+
- Often shown interacting with code concepts (ownership, borrow checker, concurrency)
28+
- ## **Ferris vs. Rust Logo**
29+
- The **official Rust logo** is the gear-shaped “R”.
30+
- **Ferris is not official**, but *widely used* by the community, conferences, crates, meetups, and merchandise.
31+
- ## **Extended Family**
32+
- The community later created variants:
33+
- **“Oxidation” Ferris** (angry)
34+
- **“Borrow Checker” Ferris** (glowing eyes)
35+
- **“Safety Dance” Ferris**
36+
- **“Rustacean” badge Ferris**
37+
- Many more, all based on open, remixable SVGs

pages/Rust___Owner___ship.md

Lines changed: 10 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,10 @@
1+
alias:: [[Rust Ownership]]
2+
3+
- [[Rust/Book/TRPL/ch/04/01 What is Ownership]]
4+
- Summary
5+
- all [[Programming/Concept/Heap]] data must be owned by exactly one variable
6+
- rust deallocates [[Programming/Concept/Heap]] data once its owner goes out of scope
7+
- ownership can be transferred with [[Rust/Owner/Move]]s, which happen in [[Rust/Variable]] assignments and [[Rust/Function]] calls
8+
- [[Programming/Concept/Heap]] data can only be accessed through the current owner, not previous owners
9+
-
10+
-

pages/Rust___acean.md

Lines changed: 3 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,3 @@
1+
alias:: [[Rustacean]], [[Rustaceans]]
2+
3+
- Rust community members often jokingly call themselves **Rustaceans** — a play on *crustacean* (like [[Rust/Ferris]] is). If the people are Rustaceans, the mascot being a crustacean (crab) fits perfectly.

pages/Rust___ic.md

Lines changed: 5 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,5 @@
1+
alias:: [[Rustic]]
2+
tags:: [[Term]]
3+
4+
- Rustic: (adj) - written in the manner that is aligned with Rust best practices and mindset
5+
-

0 commit comments

Comments
 (0)