Fix some errors/typos

rustbook-ru/src/ch06-01-defining-an-enum.md

@@ -128,7 +128,7 @@ enum IpAddr {
 
 Тем не менее, концепция, которую null пытается выразить, является полезной: null - это значение, которое в настоящее время по какой-то причине недействительно или отсутствует.
 
-Проблема на самом деле не в концепции, а в конкретной реализации. Таким образом, в Rust значений null, но есть перечисление, которое может закодировать концепцию присутствия или отсутствия значения. Это перечисление `Option<T>` , и оно [определено стандартной библиотекой <!-- ignore --> следующим образом:]
+Проблема на самом деле не в концепции, а в конкретной реализации. Таким образом, в Rust нет значений null, но есть перечисление, которое может закодировать концепцию присутствия или отсутствия значения. Это перечисление `Option<T>`, и оно [определено стандартной библиотекой <!-- ignore --> следующим образом:]
 
 ```rust
 enum Option<T> {
@@ -173,4 +173,4 @@ enum Option<T> {
 
 
 [определено стандартной библиотекой <!-- ignore --> следующим образом:]: ../std/option/enum.Option.html
-[его документации]: ../std/option/enum.Option.html
+[его документации]: ../std/option/enum.Option.html

rustbook-ru/src/ch07-00-managing-growing-projects-with-packages-crates-and-modules.md

@@ -2,7 +2,7 @@
 
 По мере роста кодовой базы ваших программ, организация проекта будет иметь большое значение, ведь отслеживание всей программы в голове будет становиться всё более сложным.  Группируя связанные функции и разделяя код по основным функциональностям <em>(фичам, feature)</em>, вы делаете более прозрачным понимание о том, где искать код реализующий определённую функцию и где стоит вносить изменения для того чтобы изменить её поведение.
 
-Программы, которые мы писали до сих пор, были в одном файле одного модуля. По мере роста проекта, мы можем организовывать код иначе, разделив его на несколько модулей и несколько файлов. Пакет может содержать несколько бинарных крейтов и опционально один крейт библиотеки. Пакет может включать в себя много бинарных крейтов и опционально один библиотечный крейт. По мере роста пакета вы можете извлекать части программы в отдельные крейты, которые затем станут внешними зависимостями для основного кода нашей программы. Эта глава охватывает все эти техники. В свою очередь для очень крупных проектов, состоящих из набора взаимосвязанных пакетов развивающихся вместе, Cargo предоставляет рабочие пространства, *workspaces*, их мы рассмотрим за пределами данной главы, в разделе ["Рабочие пространства Cargo"] Главы 14.
+Программы, которые мы писали до сих пор, были в одном файле одного модуля. По мере роста проекта, мы можем организовывать код иначе, разделив его на несколько модулей и несколько файлов. Пакет может состоять из нескольких бинарных крейтов и опционально одного крейта библиотеки. По мере роста пакета вы можете извлекать части программы в отдельные крейты, которые затем станут внешними зависимостями для основного кода нашей программы. Эта глава охватывает все эти техники. В свою очередь для очень крупных проектов, состоящих из набора взаимосвязанных пакетов развивающихся вместе, Cargo предоставляет рабочие пространства, *workspaces*, их мы рассмотрим за пределами данной главы, в разделе ["Рабочие пространства Cargo"] Главы 14.
 
 Мы также обсудим инкапсуляцию деталей, которая позволяет использовать код снова на более высоком уровне: единожды реализовав какую-то операцию, другой код может вызывать этот код через публичный интерфейс, не зная как работает реализация. То, как вы пишете код, определяет какие части общедоступны для использования другим кодом и какие части являются закрытыми деталями реализации для которых вы оставляете право на изменения только за собой. Это ещё один способ ограничить количество деталей, которые вы должны держать в голове.
 
@@ -18,4 +18,4 @@ Rust имеет ряд функций, которые позволяют упр
 В этой главе мы рассмотрим все эти функции, обсудим как они взаимодействуют и объясним, как использовать их для управления областью видимости. К концу у вас должно появиться солидное понимание модульной системы и умение работать с областями видимости на уровне профессионала!
 
 
-["Рабочие пространства Cargo"]: ch14-03-cargo-workspaces.html
+["Рабочие пространства Cargo"]: ch14-03-cargo-workspaces.html

rustbook-ru/src/ch07-02-defining-modules-to-control-scope-and-privacy.md

@@ -64,7 +64,7 @@ backyard
 
 В качестве примера, давайте напишем библиотечный крейт предоставляющий функциональность ресторана. Мы определим сигнатуры функций, но оставим их тела пустыми, чтобы сосредоточиться на организации кода, вместо реализации кода для ресторана.
 
-В ресторанной индустрии некоторые части ресторана называются *фронтом дома*, а другие *задней частью дома*. Фронт дома это там где находятся клиенты; здесь размещаются места клиентов, официанты принимают заказы и оплаты, а бармены делают напитки. Задняя часть дома это где шеф-повара и повара работают на кухне,  работают посудомоечные машины, а менеджеры занимаются административной деятельностью.
+В ресторанной индустрии некоторые части ресторана называются *фронтом дома*, а другие *задней частью дома*. Фронт дома это там где находятся клиенты; здесь размещаются места клиентов, официанты принимают заказы и оплаты, а бармены делают напитки. Задняя часть дома это где шеф-повара и повара работают на кухне, работают посудомоечные машины, а менеджеры занимаются административной деятельностью.
 
 Чтобы структурировать крейт аналогично тому, как работает настоящий ресторан, можно организовать размещение функций во вложенных модулях. Создадим новую библиотеку (библиотечный крейт) с именем `restaurant` выполнив команду `cargo new restaurant --lib`; затем вставим код из листинга 7-11 в *src/lib.rs* для определения некоторых модулей и сигнатур функций. Это секция фронта дома:
 
@@ -98,6 +98,6 @@ crate
 
 <span class="caption">Листинг 7-2: Древо модулей для программы из Листинга 7-1</span>
 
-Это дерево показывает, как некоторые из модулей вкладываются друг в друга; например, `hosting` находится внутри `front_of_house`. Дерево также показывает, что некоторые модули являются  *братьями* (siblings) друг для друга, то есть они определены в одном модуле; `hosting` и `serving` это братья которые определены внутри `front_of_house`. Если модуль A содержится внутри модуля B, мы говорим, что модуль A является *потомком * (child) модуля B, а модуль B является *родителем * (parent) модуля A. Обратите внимание, что родителем всего дерева модулей является неявный модуль с именем `crate`.
+Это дерево показывает, как некоторые из модулей вкладываются друг в друга; например, `hosting` находится внутри `front_of_house`. Дерево также показывает, что некоторые модули являются  *братьями* (siblings) друг для друга, то есть они определены в одном модуле; `hosting` и `serving` это братья которые определены внутри `front_of_house`. Если модуль A содержится внутри модуля B, мы говорим, что модуль A является *потомком* (child) модуля B, а модуль B является *родителем* (parent) модуля A. Обратите внимание, что родителем всего дерева модулей является неявный модуль с именем `crate`.
 
 Дерево модулей может напомнить вам дерево каталогов файловой системы на компьютере; это очень удачное сравнение! По аналогии с каталогами в файловой системе, мы используется модули для организации кода. И так же, как нам надо искать файлы в каталогах на компьютере, нам требуется способ поиска нужных модулей.