---

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

Author: brson

[refs]

@@ -6,7 +6,7 @@ refs/heads/try: d324a424d8f84b1eb049b12cf34182bda91b0024
 refs/tags/release-0.1: 1f5c5126e96c79d22cb7862f75304136e204f105
 refs/heads/ndm: f3868061cd7988080c30d6d5bf352a5a5fe2460b
 refs/heads/try2: d0c6ce338884ee21843f4b40bf6bf18d222ce5df
-refs/heads/incoming: 1880d783b73387c1baac9e5cb0167d7a0f6e768c
+refs/heads/incoming: ae1a73029ce422ccd52c3c659a32c19ac60d0d4e
 refs/heads/dist-snap: 2f32a1581f522e524009138b33b1c7049ced668d
 refs/tags/release-0.2: c870d2dffb391e14efb05aa27898f1f6333a9596
 refs/tags/release-0.3: b5f0d0f648d9a6153664837026ba1be43d3e2503

branches/incoming/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