Update Chapter2.md

getting_started/Chapter2.md

@@ -303,11 +303,11 @@ iex> list ++ [4]
 [1, 2, 3, 4]
 ```
 
-在上面的例子中，第一个操作是比较块的，因为我们只是加入了一个新的元组，并且让它指向旧的列表。第二个列子就比较慢了，因为我们必须重建整个列表然后才能加入新元素。
+在上面的例子中，第一个操作是比较快的，因为我们只是加入了一个新的元组，并且让它指向旧的列表。第二个列子就比较慢了，因为我们必须重建整个列表然后才能加入新元素。
 
 从另一方面来说，元组在内存中是一个整体。这意味着获取它的大小或通过索引来访问元素是非常快的。然而，修改或增减元组中的元素是非常昂贵的操作，因为它首先需要在内存中复制整个元组。
 
-更具这些性能上的特点，我们可以来决定两者的不同用途。一个非常常见的例子是用函数返回一个元组来表示附加的信息。比如，`File.read/1`用来读取一个文件的内同，它返回的就是一个元组：
+根据这些性能上的特点，我们可以来决定两者的不同用途。一个非常常见的例子是用函数返回一个元组来表示附加的信息。比如，`File.read/1`用来读取一个文件的内同，它返回的就是一个元组：
 
 ```
 iex> File.read("path/to/existing/file")
@@ -316,8 +316,8 @@ iex> File.read("path/to/unknown/file")
 {:error, :enoent}
 ```
 
-在Elixir中，当我们计算一个数据结构的大小时，需要遵循一个简单的原则：当这个操作所需的时间是一个恒量（也就是说，这个数值是事先已经计算好了的）的时候，函数应该用`size`来命名，否这的话应该用`length`。
+在Elixir中，当我们计算一个数据结构的大小时，需要遵循一个简单的原则：当这个操作所需的时间是一个恒量（也就是说，这个数值是事先已经计算好了的）的时候，函数应该用`size`来命名，否则的话应该用`length`。
 
 例如，迄今我们遇到过4个此类的函数：`byte_size/1`（获取字符串中的字节数），`tuple_size/1`（获取元组的大小），`length/1`（获取列表的大小），`String.length/1`（获取字符串中的字符数）。可见，当我们用`byte_size/1`去获得字符串中的字节数的时候，这个操作是相当简单的，但当我们希望用`String.length/1`得到其中的unicode字符的数量时是非常昂贵的，因为我们需要历遍整个字符串。
 
-Elixir同时也支持其他的一些数据类型，`Port`，`Reperence`和`PID`，用于进程间的通许。当讲到进程相关的章节的时候，我们会具体谈到它们。现在让我们了解一下和基础数据结构相关的一些基础操作符。
+Elixir同时也支持其他的一些数据类型，`Port`，`Reperence`和`PID`，用于进程间的通讯。当讲到进程相关的章节的时候，我们会具体谈到它们。现在让我们了解一下和基础数据结构相关的一些基础操作符。

getting_started/Chapter3.md

@@ -18,7 +18,7 @@ iex> "foo" <> "bar"
 "foobar"
 ```
 
-Elixir也提供个是那个布尔值操作符`or`，`and`和`not`。这些操作符严格地指定它们一个参数必须是一个布尔值（`true`或者`false`）：
+Elixir也提供布尔值操作符`or`，`and`和`not`。这些操作符严格地指定它们一个参数必须是一个布尔值（`true`或者`false`）：
 
 ```
 iex> true and true
@@ -98,7 +98,7 @@ iex> 1 < :atom
 true
 ```
 
-我们之所以可以在Elixir在不同数据类型之间比较是因为有一个内建的不同类型之间的顺序，所以算法在排序时无需担心数据类型上  的不同。下面就是内建的类型之间的顺序：
+我们之所以可以在Elixir的不同数据类型之间比较是因为有一个内建的不同类型之间的顺序，所以算法在排序时无需担心数据类型上  的不同。下面就是内建的类型之间的顺序：
 
 ```
 number < atom < reference < functions < port < pid < tuple < maps < list < bitstring