Refined Ch01.

src/getting_started/hello_cargo.md

@@ -121,7 +121,7 @@ version = "0.1.0"
 *清单 1-3, `Cargo.lock`*
 
 
-咱们刚刚使用 `cargo build`，构建了一个项目，并使用 `./target/debug/hello_cargo` 运行了他，但我们也可以使用 `cargo run`，在一条命令中编译代码，然后运行生成的可执行文件：
+咱们刚刚使用 `cargo build`，构建了一个项目，并使用 `./target/debug/hello_cargo` 运行了他，但我们也可以使用 `cargo run`，在一条命令中，编译代码并随后运行生成的可执行文件：
 
 
 ```console
@@ -131,7 +131,7 @@ $ cargo run
 Hello, World!
 ```
 
-相比必须记住运行 `cargo build` 然后使用二进制文件的整个路径，使用 `cargo run` 要更方便，因此大多数开发人员，都会使用 `cargo run`。
+相比必须记住运行 `cargo build`，然后使用二进制文件的整个路径，使用 `cargo run` 要更方便，因此大多数开发人员，都会使用 `cargo run`。
 
 请注意，这次我们没有看到，表明 Cargo 正在编译 `hello_cargo` 的输出。Cargo 发现文件没有变化，所以他没有重建，而只是运行了二进制文件。如果咱们修改了源代码，Cargo 就会在运行项目前，重建该项目，咱们就会看到这样的输出：
 
@@ -144,7 +144,7 @@ $ cargo run
 Hello, Cargo!
 ```
 
-Cargo 还提供了一个叫做 `cargo check` 的命令。此命令会对代码进行快速检查，以确保代码可被编译，但该命令不会产生出可执行程序：
+Cargo 还提供了一个叫做 `cargo check` 的命令。此命令会对代码进行快速检查，以确保代码可被编译，但该命令不会产生可执行程序：
 
 ```console
 $ cargo check                                                                                      ✔
@@ -152,27 +152,38 @@ $ cargo check
     Finished dev [unoptimized + debuginfo] target(s) in 0.35s
 ```
 
-这里为何不要一个可执行文件呢？通常，由于 `cargo check` 跳过了产生出可执行程序的步骤，因此他要比 `cargo build` 快得多。但在编写代码时，要持续检查已完成的工作时，那么 `cargo check` 的使用，就会加速工作流程！由于这个原因，许多的 Rust 公民，都会在编写他们的程序时，定期运行 `cargo check`，来确保程序通过编译。而在准备好使用可执行文件的时候，在运行 `cargo build`。
+为什么咱们不想要个可执行文件呢？通常，`cargo check` 要比 `cargo build` 快得多，因为他跳过了生成可执行文件的步骤。如果咱们在编写代码时，持续检查咱们的工作，那么使用 `cargo check` 将加快让咱们知道，项目是否仍在编译的过程！因此，许多 Rustaceans 在编写程序时，都会定期运行 `cargo check`，以确保程序能编译成功。然后，当他们准备好要用到可执行文件时，再运行 `cargo build`。
 
-来概括一下到现在，已经掌握的有关 Cargo 的内容：
+我们来回顾一下，到目前为止我们所了解的有关 Cargo 的知识：
 
 - 使用 `cargo new` 就可以创建出项目；
-- 使用 `cargo build` 就可以构建出项目；
-- 使用 `cargo run` 就可以一步完成项目的构建和运行；
-- 使用 `cargo check`就可以在不产生出二进制程序的情况下，对项目加以构建以进行错误检查；
-- Cargo 是将构建结果保存在 `target/debug` 目录，而不是保存在与源代码同样的目录。
 
-使用 Cargo 的一个额外优势，就是不论是在何种操作系统上工作，那些命令都是同样的。基于这个原因，本书后续就不再提供针对 Linux 与 macOS，以及Windows 的特别说明了。
+- 使用 `cargo build` 就可以构建出项目；
+
+- 使用 `cargo run` 可一步完成项目的构建和运行；
+
+- 使用 `cargo check`，可以在不产生出二进制程序的情况下，构建某个项目以进行错误检查；
+
+- Cargo 不会将编译结果，保存在与代码相同的目录中，而是将其保存在 `target/debug` 目录中。
+
+
+使用 Cargo 的另一个好处是，无论咱们在哪个操作系统上工作，命令都是一样的。因此，我们将不再提供 Linux 和 macOS 与 Windows 的具体说明。
+
 
 ## 发布目的的构建
 
-在项目最终准备好发布时，就可以使用 `cargo build --release` 来带优化地对其进行编译了。该命令将创建出一个位于 `target/release`，而非 `target/debug` 中的可执行文件。其中的那些优化，会令到项目的 Rust 代码运行得更快，不过开启这些优化，将增加程序编译的时间。这就是为什么有两种不同配置文件的原因：一个配置是为开发目的，在希望快速且频繁地对项目进行重新构建时使用的配置，而另一个，则是为构建要给到用户的、不会反复重新构建的、将尽可能快速运行的最终程序所用到的配置。在要对程序进行性能测试时，就一定要运行 `cargo build --release`，并对 `target/release` 中的可执行程序进行性能测试。
 
-## 约定俗成的 Cargo
+当咱们的项目最终准备好发布时，咱们可以使用 `cargo build --release`，对其进行带有优化的编译。该命令将在 `target/release`，而不是 `target/debug` 下，创建可执行文件。这些优化会让 Rust 代码运行得更快，但开启这些优化，会延长程序的编译时间。这就是为什么有两种不同的（构建）配置文件：一种是当咱们打算快速、频繁地重建程序时，用于开发的；另一种用于编译咱们会将其交给用户，不会被反复重建，而且会尽可能快地运行的最终程序。如果咱们正对咱们代码的运行时间，进行基准测试，那么请确保运行 `cargo build --release`，并使用 `target/release` 中的可执行文件，进行基准测试。
 
-对于那些简单项目，相比于使用 `rustc`，Cargo 并未提供到很多价值，然而在程序变得愈加错综复杂时，他就会证明他的价值了。对于那些由多个代码箱（crates） 构成的复杂项目，让 Cargo 来对构建进行协调，就要容易得多。
 
-即使这个`hello_cargo` 项目如此，此刻也用到了将在接下来的 Rust 编程生涯中会用到的真正工具。事实上，对于在任何既有的 Rust 项目，都应使用下面这些命令，使用 Git 来检出代码，然后前往到项目目录，进而加以构建：
+## 作为约定惯例的 Cargo
+
+
+对于简单项目，Cargo 并不能提供比仅使用 `rustc` 更多的价值，但当咱们的程序变得越来越复杂时，他将证明自己的价值。一旦程序增加到多个文件，或需要依赖项时，让 Cargo 来协调构建，就容易多了。
+
+
+尽管 `hello_cargo` 项目很简单，但他现在就用到了，咱们在 Rust 职业生涯中将会用到的许多真正工具。事实上，要在任何现有项目上工作，咱们都可以使用以下的，运用 Git 检出代码，切换到该项目的目录，然后构建的这些命令：
+
 
 ```console
 $ git clone example.org/someproject
@@ -180,4 +191,24 @@ $ cd someproject
 $ cargo build
 ```
 
-更多有关 Cargo 的信息，请查看看[Cargo 文档](https://doc.rust-lang.org/cargo/)。
+更多有关 Cargo 的信息，请查看 [Cargo 文档](https://doc.rust-lang.org/cargo/)。
+
+
+## 本章小结
+
+
+咱们的 Rust 之旅，已经有了一个良好的开端！在本章中，咱们已经掌握了如何：
+
+
+- 使用 `rustup` 安装最新的 Rust 稳定版;
+
+- 更新到较新的 Rust 版本;
+
+- 打开本地安装的文档;
+
+- 编写并直接使用 `rustc` 运行一个 “Hello, world!” 程序；
+
+- 使用 Cargo 的约定，创建并运行一个新项目。
+
+
+这正是编写一个更大型程序，来习惯于读写 Rust 代码的大好时机。因此，在第 2 章中，我们将构建一个猜数游戏程序。如果咱们想从掌握那些常见编程概念，在 Rust 中的工作原理开始，那么请参阅第 3 章，然后返回第 2 章。