---

yaml
---
r: 24208
b: refs/heads/master
c: ae1a730
h: refs/heads/master
v: v3

Author: brson

[refs]

@@ -1,5 +1,5 @@
 ---
-refs/heads/master: 1880d783b73387c1baac9e5cb0167d7a0f6e768c
+refs/heads/master: ae1a73029ce422ccd52c3c659a32c19ac60d0d4e
 refs/heads/snap-stage1: e33de59e47c5076a89eadeb38f4934f58a3618a6
 refs/heads/snap-stage3: cd6f24f9d14ac90d167386a56e7a6ac1f0318195
 refs/heads/try: ffbe0e0e00374358b789b0037bcb3a577cd218be

trunk/doc/tutorial.md

@@ -957,7 +957,7 @@ Rust has three competing goals that inform its view of memory:
 Most languages that offer strong memory safety guarantees rely upon a
 garbage-collected heap to manage all of the objects. This approach is
 straightforward both in concept and in implementation, but has
-significant costs. Languages that take this approach tend to
+significant costs. Languages that follow this path tend to
 aggressively pursue ways to ameliorate allocation costs (think the
 Java Virtual Machine). Rust supports this strategy with _managed
 boxes_: memory allocated on the heap whose lifetime is managed
@@ -982,7 +982,7 @@ tasks. Experience in other languages has proven that isolating each
 task's heap from the others is a reliable strategy and one that is
 easy for programmers to reason about. Heap isolation has the
 additional benefit that garbage collection must only be done
-per-heap. Rust never "stops the world" to garbage-collect memory.
+per-heap. Rust never "stops the world" to reclaim memory.
 
 Complete isolation of heaps between tasks implies that any data
 transferred between tasks must be copied. While this is a fine and