Blog Posts

我开始使用 Elixir 大约有一年了。起初，我只打算在博客中使用这种语言，认为它可以帮助我更好地说明 Erlang 虚拟机（EVM）的优势。然而，我立即被这种语言所带来的魅力所吸引，并很快将其引入了我当时正在开发的基于 Erlang 的生产系统。如今，我认为 Elixir 是开发 EVM 支持系统的更好选择，在这篇文章中，我将尝试强调它的一些优点，并消除对它的一些误解。

## Erlang 语言的问题

EVM有很多优点，可以让我们更轻松地构建高可用、可扩展、容错的分布式系统。互联网上有各种证明，我在博客中也提到了 Erlang 的一些优点，在[这里](http://theerlangelist.com/2012/12/yet-another-introduction-to-erlang.html)和[这里](http://www.theerlangelist.com/2013/01/erlang-based-server-systems.html)，我即将出版的新书《Elixir in Action》的第一章介绍了 Erlang 和 Elixir 的优点。

长话短说，Erlang 为管理高度可扩展的容错系统提供了出色的抽象，这在必须执行许多独立或松散依赖任务的并发系统中尤其有用。三年多来，我一直在生产中使用 Erlang，构建了一个基于长轮询的 HTTP 推送服务器，在高峰期每秒可提供超过 2000 次请求（非缓存）。在此之前，我从未编写过如此大规模的程序，也从未开发过如此稳定的程序。这项服务就这样快乐地运行着，无需我多想。这实际上是我的第一份 Erlang 代码，其中充满了反模式和糟糕的方法。但事实证明，EVM 仍然具有很强的适应能力，并能以最好的状态运行代码。最重要的是，由于 Erlang 的并发机制，我可以非常直接地解决这个复杂的问题。

不过，尽管 Erlang 有一些很好的特性，但我在用 Erlang 编程时却从来没有（现在也没有）感到十分自如。不知何故，编码过程总是感觉不太流畅，而且生成的代码总是带有过多的模板和重复。**问题不在于语言的语法**。我在学生时代学过一点 Prolog，我非常喜欢这种语言。推而广之，我也喜欢 Erlang 的语法，而且实际上我认为它在很多方面都比 Elixir 更好、更优雅。我是一名面向对象(OO)开发人员，大部分时间都在使用 Ruby、JavaScript、C# 和 C++ 等语言。

Erlang 给我带来的问题是，这种语言在某种程度上过于简单，很难消除模板和结构上的重复。相反，由此产生的代码也会变得有点乱，更难编写、分析和修改。在使用 Erlang 编程一段时间后，我认为就高效代码组织而言，函数式编程不如面向对象编程。

## Elixir 是什么（不是）

这就是 Elixir 改变我看法的地方。在我花了足够多的时间使用 Elixir 之后，我终于能够更清楚地看到函数式编程的好处和优雅之处。现在，我不能再说我更喜欢 OO 而不是 FP 了。我发现在 Elixir 中的编码体验要愉悦得多，我可以专注于我要解决的问题，而不是处理语言的缺点。

在讨论 Elixir 的一些优点之前，我想强调一件重要的事情：**Elixir 不是 Erlang 的 Ruby**。它也不是用于 Erlang 的 CoffeeScript、Clojure、C++ 或其他语言。Elixir 和 Erlang 之间的关系是独特的，Elixir 在语义上往往与 Erlang 非常接近，但又从不同的语言中引入了许多想法。从表面上看，Elixir 的最终结果可能很像 Ruby，但我觉得它更接近 Erlang，两种语言完全共享类型系统，走的是相同的函数式路线。

那么 Elixir 是什么呢？在我看来，Elixir 是一种类似 Erlang 的语言，具有更好的代码组织能力。这个定义与你在官方页面上看到的不同，但我认为它抓住了 Elixir 与 Erlang 相比的精髓。

让我详细说明一下。在我看来，编程语言有以下几个作用：

- 它作为一种界面，允许程序员控制某些东西，例如硬件、虚拟机、运行中的应用程序、用户界面布局......
- 它塑造了开发人员思考他们正在建模的世界的方式。OO 语言会让我们寻找具有状态和行为的实体，而 FP 语言则会让我们考虑数据和转换。声明式编程语言会迫使我们思考规则，而在命令式语言中，我们会更多地考虑动作序列。
- 它提供了组织代码、去除重复、模板和噪音的工具，并希望尽可能按照我们理解的方式对问题进行建模。

Erlang 和 Elixir 在前两个角色上完全相同--它们的目标是相同的 "事物"（EVM），并且都采用了函数式方法。Elixir 在第三种作用上对 Erlang 进行了改进，为我们提供了额外的工具来组织代码，并希望能更高效地编写生产就绪、可维护的代码。

## 构成要素

互联网上关于 Elixir 的讨论很多，但我尤其喜欢 Devin Torres 的两篇文章，你可以在[这里](https://devinus.io/the-excitement-of-elixir/)和[这里](https://devinus.io/elixir-its-not-about-syntax/)找到。Devin 是一位经验丰富的 Erlang 开发人员，他还编写了一个广受欢迎的 [poolboy](https://github.com/devinus/poolboy) 库，因此他对 Elixir 的看法值得一读。

我将尽量不重复很多内容，并避免涉及许多机械细节。相反，让我们简要介绍一下可以用来更好地组织代码的主要工具。

### 元编程

Elixir 中的元编程有几种形式，但本质是一样的。它允许我们编写简洁的结构体，这些结构体仿佛是语言的一部分。这些结构在编译时会被转换成合适的代码。在机械层面上，它可以帮助我们消除结构上的重复--即两段代码具有相同的抽象模式，但在许多机械细节上存在差异。

例如，下面的代码段展示了一个用户记录模型模块的简图：

<Code language="elixir">
{`defmodule User do
 #initializer
 def new(data) do ... end

# getters
def name(user) do ... end
def age(user) do ... end

# setters
def name(value, user) do ... end
def age(value, user) do ... end
end`}
</Code>

其他类型的记录也会遵循这种模式，但包含不同的字段。我们可以使用 Elixir **defrecord** 宏来代替复制粘贴这种模式：

<Code language="elixir">
{`defrecord User, name: nil, age: 0`}
</Code>

根据给定的定义，defrecord 会生成一个专用模块，其中包含用于操作用户记录的实用功能。因此，通用模式只在一个地方（defrecord 宏的代码）进行了说明，而特定的逻辑则不需要机械地执行细节。

Elixir 宏与 C/C++ 宏完全不同。它们不处理字符串，而是类似于编译时的 Elixir 函数，在解析过程中被调用，并处理抽象语法树（AST），即以 Elixir 数据结构表示的代码。宏可以在 AST 上工作，并产出一些替代的 AST 来表示生成的代码。因此，宏是在编译时执行的，所以一旦进入运行时，性能就不会受到影响，也不会出现某些代码会更改模块定义的意外情况（例如 JavaScript 或 Ruby 中就会出现这种情况）。

由于宏的存在，Elixir 的大部分功能实际上都是在 Elixir 中实现的，包括 if、unless 或单元测试支持等构造。Unicode 支持的工作原理是读取 UnicodeData.txt 文件，并生成相应的 Unicode 字符串函数（如downcase或upcase）。这反过来又使开发人员更容易为 Elixir 做出贡献。

宏还允许第三方库作者提供与语言自然匹配的内部 DSL。[Ecto](https://github.com/elixir-lang/ecto) 项目提供嵌入式集成查询，类似于 Elixir 的 LINQ，这是我个人最喜欢的项目，它真正展示了宏的力量。

有时，我看到有人对 Elixir 不屑一顾，说他们不需要元编程功能。元编程虽然非常有用，但也可能成为非常危险的工具，建议谨慎使用。尽管如此，元编程还是提供了很多功能，即使你不亲自编写宏，你也可能会喜欢其中的很多功能，比如前面提到的记录、Unicode 支持或集成查询语言。

### 管道运算符

这个看似简单的运算符非常有用，甚至在我知道 Elixir（或其他语言）中存在这个运算符之前，我就 "发明 "了它的 Erlang 对应运算符。

让我们先来看看问题所在。Erlang 中没有管道运算符，此外，我们也无法重新分配变量。因此，典型的 Erlang 代码通常会以如下模式编写：

<Code language="elixir">
{`State1 = trans_1(State),
State2 = trans_2(State1),
State3 = trans_3(State2),
...`}
</Code>

这是一段非常笨拙的代码，它依赖于中间变量，以及将上一次结果正确传递给下一次调用。实际上，我曾遇到过一个令人讨厌的错误，因为有一处我不小心使用了 State6 而不是 State7。

当然，我们可以通过内联函数调用来解决这个问题：

<Code language="elixir">
{`trans_3(
 trans_2(
 trans_1(State)
 )
)`}
</Code>

正如你所看到的，这段代码很快就会变得很难看，而且当转换函数接收到额外参数和转换次数增加时，问题往往会更加严重。

管道运算符可以在不使用中间变量的情况下组合各种操作：

<Code language="elixir">
{`state
|> trans_1
|> trans_2
|> trans_3`}
</Code>

这段代码从上到下读起来就像散文一样，突出了 FP 的优势之一，即我们将函数视为数据转换器，通过各种方式将其组合起来，以实现所需的结果。

例如，下面的代码计算一个列表中所有正数的平方和：

<Code language="elixir">
{`list
|> Enum.filter(&(&1 > 0)) # take positive numbers
|> Enum.map(&(&1 * &1)) # square each one
|> Enum.reduce(0, &(&1 + &2)) # calculate sum`}
</Code>

由于 Elixir 库中的 API 遵循 "主语（名词）作为第一个参数 "的惯例，因此管道操作符运行得非常好。与 Erlang 不同，Elixir 认为所有函数都应将其操作对象作为第一个参数。因此，String 模块函数将 string 作为第一个参数，而 Enum 模块函数则将 enumerable 作为第一个参数。

### 通过协议实现多态性

协议是 Elixir 提供大致类似于 OO 接口的方式。起初，我对协议的印象并不深刻，但随着时间的推移，我开始发现协议带来的诸多好处。协议允许开发人员创建一个通用逻辑，该逻辑可用于任何类型的数据，前提是为给定的数据实现了某种契约。

枚举模块就是一个很好的例子，它提供了许多有用的函数，可用于处理任何可枚举的数据。例如，我们可以这样遍历一个枚举：

<Code language="elixir">
{`Enum.each(enumerable, fn -> ... end)`}
</Code>

当然，我们也可以通过实现相应的协议为自己的类型添加支持。这类似于 OO 接口，但有一个额外的特点，即即使你不拥有某个类型的源代码，也可以为该类型实现协议。

协议实用性的最佳例子之一是流模块，它实现了一种lazy的、可组合的、可枚举的抽象。通过流，可以组合各种可枚举的转换，然后只在需要时，通过将流输入 Enum 模块中的某个函数来生成结果。例如，下面的代码可以一次性计算出列表中所有正数的平方和：

<Code language="elixir">
{`list
|> Stream.filter(&(&1 > 0))
|> Stream.map(&(&1 * &1))
|> Enum.reduce(0, &(&1 + &2)) # Entire iteration happens here in a single pass`}
</Code>

在第 2 行和第 3 行中，操作已经组成，但尚未执行。结果是一个实现 Enumerable 协议的规范描述符。一旦我们将该描述符输入某个枚举函数（第 3 行），它就会开始产生值。除了支持协议机制外，Elixir 编译器没有提供特殊的lazy支持。

### Mix工具

最后一块重要的拼图是帮助我们管理项目的工具。Elixir 附带的Mix工具就能做到这一点。它的操作方式也非常简单，令人印象深刻。创建一个新项目时，磁盘上只会创建 7 个文件（包括 .gitignore 和 README.md）。这就是创建一个合适的 OTP 应用程序所需的全部过程。这是一个很好的例子，说明通过将必要的模板和官僚主义隐藏在通用抽象中，可以将事情简化到何种程度。

Mix工具还支持其他各种任务，如依赖关系管理。该工具还具有可扩展性，因此您可以根据需要创建自己的特定任务。

### 语法变化

Elixir 还为我们带来了许多其他好处。其中许多语法变化都来自 Erlang，例如支持变量重绑定、可选括号、隐式语句结尾、可归零性、短路操作符......

诚然，可选的括号会带来一些歧义，如本示例所示：

<Code language="elixir">
{`abs -1 + 5 # same as abs(-1 + 5)`}
</Code>

不过，我使用括号（宏和零 arg 函数除外），所以我不记得在实践中遇到过这个问题。

总的来说，我喜欢这里做出的许多决定。能写 if 而不强制写 else，这很好。我也很高兴不必有意识地考虑必须使用哪个字符来结束语句。

即使是可选的括号也很好，因为它们支持宏的 DSL 式使用，使代码不那么嘈杂。如果没有括号，我们就必须在调用宏时添加括号：

<Code language="elixir">
{`defrecord User, name: nil, age: 0 # without parentheses

defrecord(User, [name: nil, age: 0]) # with parentheses`}
</Code>

不过，我并不觉得这些增强功能有多重要。它们是很好的点睛之笔，但如果 Elixir 只能提供这些，我可能还是会使用纯 Erlang。

## 结束语

这篇文章已经说了很多，但我觉得 Elixir 的魔力还远未被完全捕捉。诚然，对语言的偏好是主观的，但我觉得 Elixir 确实在 Erlang 的基础上进行了改进。我用 Erlang 进行了三年多的生产级编码，而使用 Elixir 则有一年左右的时间。生成的代码看起来更紧凑，我可以更专注于解决我正在解决的问题，而不是与过多的噪音和模板搏斗。

出于类似的原因，我喜欢 EVM。底层的并发机制让我可以更轻松地处理高负载服务器端系统的复杂性，该系统必须不断提供服务并同时执行许多任务。

Elixir 和 EVM 都提高了抽象标准，帮助我更轻松地解决复杂问题。这就是为什么我总是将 Elixir/EVM 组合作为构建服务器端系统的首选工具。当然，具体情况具体分析。

为什么选择Elixir

上周末，在使用 Elixir 参加 "十亿条记录挑战"（[The One Billion Record Challenge](https://twitter.com/gunnarmorling/status/1741839724933751238)，1BRC）时，**我学到了很多东西**。我想与大家分享所有这些东西，但也许这最适合在演讲中分享。因此，在这篇文章中，我将只关注其中的一点：读取包含数百万条记录的巨大文本文件的性能。

## How did I get here?

我的 1BRC 解决方案的总体结构是这样的：

<Code language="elixir">
{`path
|> File.stream!() # Streams the lines of the file
|> Stream.chunk_every(@chunk_size) # Creates chunks of lines for processing
|> Enum.map(&Task.async(fn -> process_chunk(&1) end)) # Creates a task for each chunk
|> Enum.map(&Task.await(&1)) # Waits for each task to finish
|> Enum.reduce(%{}, &summarize_chunk_results/2) # Merges the results of all tasks
|> Enum.map(&stats/1) # Calculates the stats for each weather station`}
</Code>

在本文中，我们假设 @chunk_size 的值为 100_000。

为了优化性能，我对最初的（非常幼稚的）解决方案进行了多次迭代，但结果与我在[ Javaland 中看到的结果](https://github.com/gunnarmorling/1brc#results)相差甚远（当时约为 8 秒）。

然后，我使用 **fprof**、**erlgrind** 和 **qcachegrind** 对代码进行了剖析（请参阅[此处](https://blog.equanimity.nl/blog/2013/04/24/fprof-kcachegrind/)的基本说明），根据对结果的分析，我设法做出了一些相当不错的改进。这个过程我重复了几次，但最后我发现很多时间都花在了与流相关的操作上，这让我很恼火。

我怀疑仅仅读取文件就耗费了大量时间，事实也确实如此！下面是一张树形图，显示了我向程序输入 1000 万行数据时执行时间的分布情况。

![001](/images/blog/0037_001.webp)

**右边的大矩形**由 Enumerable.Stream 模块中的函数和 Enum.map/2 的调用组成。

让我们仔细想想：当我们调用 Enum.map/2（第 4 行）时，每次迭代都会向 Stream.chunk/2 生成的流请求新的行块。由于流是lazy地评估的，因此该流会向 File.stream!/1 生成的流请求足够多的行来填充一个块（或文件的最后一行，如果没有了）。这就是为什么 Enum.map/2 似乎要花费大量时间的原因。

但是......读取文件花费的时间几乎占总时间的一半！这可不好！一点都不好

在家里的办公室转了一会儿圈后，我输入了一个小程序来确认我的发现，并将其作为不同读取文件方法的基准。

<Code language="elixir">
{`path
|> File.stream!()
|> Stream.chunk_every(@chunk_size)
|> Enum.map(fn _ -> :ok end)`}
</Code>

我们的想法是测量读取文件和创建大段行所需的时间。

哦！在我们深入研究结果之前，我使用的机器是 MacBook Pro，配备苹果 M1 Max 芯片（10 个内核）和 32 Gb 内存。

那么，我们开始吧...

<Code language="shell">
{`| # records | size | time (sec) |
| ---------- | ------ |----------- |
| 1 M | 13 Mb | 0.19 |
| 10 M | 132 Mb | 1.58 |
| 100 M | 1.3 Gb | 15.47 |
| 1 B | 13 Gb | 156.39 |`}
</Code>

这太疯狂了！你不觉得吗？在这种情况下，我根本无法与 Java 解决方案相提并论！**仅仅读取一个 10 亿条记录的文件，我就要花 156 秒！**我必须承认，此时我感到非常失望和沮丧。我该怎么办呢？

![002](/images/blog/0037_002.webp)

然后我又想：在不使用流媒体的情况下读取整个文件需要多少钱？结果发现，对于 10 亿条记录的文件（13 Gb），答案是....🥁🥁🥁

<Code language="elixir">
{`iex(1)> Benchmark.measure(fn -> File.read!("measurements_1_000_000_000.txt") end)
4.87 secs `}
</Code>

有时需要更长的时间，但无论如何，也就 5 秒左右！那么，为什么以流式方式读取并创建 10_000 个数据块需要 156 秒？

于是我开始思考读取文件并从中汲取行数的不同方法。最后，我发现了其他 4 种不同的方法（在 Elixir 论坛的帮助下）。下面我将逐一向大家介绍，然后再向大家展示我的基准测试结果。

### 方案 1：使用 File.stream 逐行流式传输

这是最原始的方法。让我们给它起个代号：fstream。

### 方案 2：读取整个文件并形成行流

这意味着基本上要在 File.read!/1 返回的巨大二进制文件中创建一个行流。 由于我从未创建过行流，所以花了好长时间才成功实现。这种方法的代号是 :whole_read。

<Code language="elixir">
{`def lines_stream(path, :whole_read) do
 path |> File.read!() |> line_stream()
end

def line_stream(b) when is_binary(b) do
Stream.unfold(b, fn b ->
case String.split(b, "\n", parts: 2) do
[line, rest] ->
{line, rest}

 [""] ->
 nil
 end
end)
end`}
</Code>

### 方案 3：读取整个文件，创建一个 IO 设备，然后从中创建行流

在这种方法中，读取整个文件后，我们将整个二进制文件作为源文件创建一个 Erlang IO 设备，然后从中创建行流。我在论坛上发现了这种方法。代码名是 :whole_read_string_io。

<Code language="elixir">
{`def lines_stream(path, :whole_read_string_io) do
 {:ok, io_dev} = path |> File.read!() |> StringIO.open()
 IO.binstream(io_dev, :line)
end`}
</Code>

### 方案 4：创建大块二进制数据流，再从中创建产生行的数据流

那么，如果我们以大块（二进制模式）读取文件，并从中通过一个新的数据流产生行呢？这基本上就是每次读取 500_000 字节的数据块，然后从每个数据块中创建一个行列表，并将其输入到一个行流中。代码名为 :chunked_bin_read。

<Code language="elixir">
{`def lines_stream(path, :chunked_bin_read) do
 path |> File.stream!([], 500_000) |> line_stream_from_binary_stream()
end

def line_stream_from_binary_stream(bin_stream) do
bin_stream
|> Stream.transform("", fn chunk, acc ->
[last_line | lines] =
acc <> chunk
|> String.split("\n")
|> Enum.reverse()
{Enum.reverse(lines), last_line} # reverse is only needed if you care about original order of the lines
end)
end`}
</Code>

### 方案 5：读取整个文件，然后按二进制块、行进行流式处理

这与方案 4 类似，但我们不依赖 File.stream/3，而是一步读取整个文件。然后，我们创建一个读取大块二进制文件的流，再创建一个读取行的流。代码名为 :whole_read_chunked_bin。

<Code language="elixir">
{`def lines_stream(path, :whole_read_chunked_bin) do
 path |> File.read!() |> binary_stream() |> line_stream_from_binary_stream()
end

def binary_stream(b, chunk_size \\ 500_000) when is_binary(b) do
Stream.unfold(0, fn skip ->
case b do
<<_skipped::binary-size(skip), chunk::binary-size(chunk_size), _rest::binary>> ->
{chunk, skip + chunk_size}

 <<_skipped::binary-size(skip)>> ->
 nil

 <<_skipped::binary-size(skip), chunk::binary>> ->
 {chunk, skip + byte_size(chunk)}
 end
end)
end

def line_stream_from_binary_stream(bin_stream) do
# defined above
end`}
</Code>

## 请下注！

长话短说，这是我在改变输入大小（最多 10 亿条记录）的情况下，每种方法得到的结果：

<Code language="shell">
{`| size | fstream | whole_read_string_io | whole_read | chunked_bin_read | whole_read_chunked_bin |
| ----- | ------- | -------------------- | ---------- | ---------------- | ---------------------- |
| 1 M | 0.19 | 1.12 | 0.32 | 0.12 | 0.16 |
| 10 M | 1.54 | 10.90 | 2.76 | 0.87 | 1.09 |
| 100 M | 15.28 | 110.36 | 26.97 | 8.44 | 10.61 |
| 1 B | 152.69 | 1154.50 | 269.84 | 85.81 | 111.95 |`}
</Code>

可以看出，chunked_bin_read 是时间最短的解决方案。

这种方法的原理是，在使用 Enum.map(fn _ -> :ok end) 进行迭代时，每次迭代都会向输入的流请求一个字符串块，然后这个流会向 File.stream!([], 500_000) 返回的流请求下一个元素，结果是一个 500_000 字节的二进制元素，然后我们就会生成尽可能多的文本行。这样，通过一次 IO 读取操作，我们就能为一个数据块创建大量行。这就是所谓的缓冲读取。

![003](/images/blog/0037_003.webp)

## File.stream/3 中缺少的功能？

等等，有没有一种方法可以使用现有的标准库来实现这一功能，而不需要进行复杂的流操作？

很遗憾没有。File.stream/3 的文档指出

> The `line_or_bytes` argument configures how the file is read when streaming, by `:line` (default) or by a given number of bytes. When using the `:line` option, CRLF line breaks (`"\r\n"`) are normalized to LF (`"\n"`).

也就是说，你可以按行或按字节块读取数据。根本不存在 "请给我读几行，但要以缓冲方式从设备读取 "这样的说法。阅读 File.stream/3 的实现后，我证实了这一点。

至于这是否是一个缺失的功能，我们可以在正式版本中讨论，但回顾我刚才展示的基准测试，拥有这一功能岂不是非常有益？在我的使用案例中，执行时间几乎缩短了一倍。

## 我的 1BRC 最终结果

我的最终解决方案的执行时间分布如树形图所示。

![004](/images/blog/0037_004.webp)

右边的大矩形代表读取文件所花费的时间（约 14%），在我看来仍然很大，但这是我能得到的最好结果。

你可以看到中间顶部有两个大矩形。它们与 String.split/2 和 Float.parse/1 函数有关，我使用这两个函数来处理每条记录。我猜有一种更理想的方法，但我还没有在 Erlang/Elixir 中找到。

总之，仅仅读取文件中的记录（参见上面的基准测试）就需要 85 秒，这与某些人用 Java 编写的解决方案（尽管这些基准测试是在 64 核机器上进行的）🤷🏽‍️。

收获
- 参加 [1BRC](https://www.morling.dev/blog/one-billion-row-challenge/) 是一次非常有趣的学习经历。这个挑战看似简单，但却是一个从不同角度学习的绝佳机会：它将帮助你评估自己对所选平台和一般计算的了解程度，还将帮助你摸索出一套专注于优化的新技能，最后，它还将让你更好地了解不同平台在解决这个特定问题时是如何进行比较的。
- 如果你不知道如何剖析 Elixir 程序，我非常建议你学习如何剖析。在实际项目中、在改进 [Archeometer](https://gitlab.com/MachinesAreUs/archeometer) 的过程中，以及现在在这个富有洞察力的练习中，这些技术已经帮了我好几次了。
- 我对 Erlang IO 性能以及与存储操作相关的微妙之处知之甚少。我以前从未遇到过这种问题。我需要学习更多！

就到这里吧

欢迎提出任何意见或建议！

用 Elixir 处理超大文本文件

**Joe Armstrong**，Erlang最初的设计者和实现者，他也是Erlang OTP系统项目的首席架构师。他拥有瑞典皇家理工学院博士学位，是容错系统开发领域的世界级专家。Armstrong起初是一名物理工作者，在攻读物理学博士学位时因为用完积蓄而转向了计算机科学，找到一份研究员的工作，为英国人工智能领域奠基人之一的Donald Michie工作。在此期间，他成为英国机器人学会的创始成员并撰写了一些有关机器人视觉的论文。人工智能的资金来源枯竭，Armstrong又回到了物理学领域。开始时他在欧洲非相干散射科学协会工作，后来又到了瑞典空间研究中心，最后加入了爱立信计算机科学实验室，Erlang就是在那里发明的。

在现代语言的版图中，Erlang有点另类。同很多流行的语言相比，它既老又新。早在1986年，也就是Perl出现的前一年，Armstrong就已经开始了Erlang的工作，当时它只作为商用产品出售并且主要在爱立信公司内部使用。这种情况直到1998年Erlang作为开源项目发布后才发生变化，那时Java和Ruby已经问世3年了。当时Erlang设计初衷也相当明确，它针对的软件是类似于电话交换机那样的高可用性、高可靠性系统。

**世界上有上百种编程语言，有一些语言效率很高，也很简洁，但是它们从未真正流行起来。您认为一个语言背后的成功的关键是什么？**

> 一个新的语言必须极其擅长解决某一类问题。这类问题必须是人们想要解决的问题，而与其竞争的语言在解决这个问题的时候捉襟见肘。在商业成功上，必须有人能够通过使用这个语言挣到大钱。通过使用这种语言会带给你使用其他语言无法比拟的竞争优势。

**有哪些至关重要的因素让Erlang成为如今的Erlang?**

> Erlang的第一个机会来自于一个用其他语言编程的大项目的失败。我们通过用Erlang重新编程而拯救了这个项目。 第二个重要因素是1998年，Erlang被爱立信公司暂时禁用。于是当Erlang开源的时候引发了一系列的事件，一大批公司从此选择Erlang作为他们的主要技术。 最近的一次，WhatsApp被Facebook以190亿美元收购，此次收购成为有史以来最大的软件收购。WhatsApp就是用Erlang编写的，这个事实也吸引了很多注意力。

**您对Elixir的评价很高，您认为Erlang在未来的发展会受到Elixir的影响吗？**

> 是的，但是不单单是Elixir，Erlang也会被其他语言的发展所影响。

**未来Erlang将会如何演进？有什么要点可以和我们分享吗？**

> Erlang刚开发出来的时候，那时机器内存还只有几兆字节，所以我们决定仅仅允许同一个模块的两个版本同时存在。现在我们已经有千兆字节的内存，所以我们可以有上千个版本，然后让垃圾收集器把没用的版本移除。 在原始的Erlang实现里，同一台机器上的进程间的信息通过时间是恒定的。在多核计算机上，这点将改变，所以我们需要考虑在多核处理器上的物理位置排布。 在不远的将来，我们将会看到每个芯片上有几千个CPU的多核计算机的大量出现，其中的一些核会由于生产问题而无法使用，所以我们需要学会如何把Erlang进程分布在可用的核上。 我们还需要理解能量使用。从环境因素考虑，我们需要知道如何把性能最大化，同时让能耗最小化。大量多核可以在低压下运行，时钟频率可以用来让能耗最小化，但是我们仍需要很大的努力才能知道如何用编程来实现这些。

**你认为Erlang和Scala之间存在竞争关系吗？他们各自独特的优势在哪？**

> 他们确实是对手——但是Scala和JVM之间绑定地更紧密。Scala为Java程序员提供了一条迁移路径，但是Scala和Erlang运行时的特点完全不同。有很多Erlang擅长而Scala不擅长的问题，反之亦然。

**并发、并行、分布式的编程模式，Erlang更擅长哪一个？不擅长哪一个？为什么？**

> Erlang最擅长协调并行活动，处理故障，Erlang程序在运行多核的时候也可以很好地扩展。 Erlang在存储密集型的数值计算上并不擅长。这背后的原因在于容错系统和存储管理系统。为了实现高容错，我们必须在不同的地方存放数据拷贝，所以当进程崩溃的时候我们可以在其他的地方重启。所有这些复制都需要时间。高效的数值计算可以在内存中进行，不需要复制，但是它的代价就在于容错性低。 高容错性需要CPU时间和存储，所以如果你不需要容错和分布，那就不应该使用Erlang。

**如果可以重新来过，你希望对Erlang做哪些改动？**

> 有很多东西。但是这个语言也在缓慢地改变。我希望能看到几样东西。其中每样都是头等重要。但是比如说模块，它就不是头等重要的，我们不能轻而易举地把模块变成一系列的功能，或者把一系列功能变成一个模块。我们应当可以构建或解构任何Erlang对象。像协议这样的东西，虽然是隐式的，但是它们应该变成显式的。 Erlang分布式编程的编程模型需要扩展成“全球范围分布”。虽然现在我们可以在单独Erlang节点或节点集群上注册进程，但是离开了就不行，这样就无法让世界上的每台计算机都可以访问。

**XML语言似乎无法适应如今的大数据环境。新语言ML9应该具备什么样的特性才能保持XML的优势同时去除它的缺点？**

> ML9是一个实验，我现在已经不再维护了。XML可以用，但是不应被用来长期存储或传送大量数据。对于小结构文件，XML足以胜任。

**有很多Ruby, Java, Python程序员想要学Erlang，对他们你有什么建议吗？**

> 看我的书！

**你曾经提到过Dave Thomas给过你很多关于写作的建议，你从你的写作经历里学到了什么？对其他初出茅庐的作者你有什么样的建议？**

> 我学会了享受写作，通过不断地修改和重写来提高我的文字。我还找了一群不同背景的读者来读我的文字，然后他们会告诉我他们是否理解了。我很喜欢大量的反馈，如果人们不理解我写的东西，那我就要再多解释一些。没有反馈的话，我不会知道哪个部分更容易理解，哪个部分更艰涩。 曾经有很多年，我认为写作是件非常困难的事，在学校的时候我的数学很好，写作很糟，但是我努力克服了自己的缺点，Dave Thomas也给了我很多很好的建议，所以现在这件事对我来说不再困难了。 作为一位作者，最难的莫过于把自己置身于读者的位置上，而读者对你所了解的知识一无所知，所以你要想象他们即将遇到的问题，然后赶在他们遇到之前，把这些问题解决掉。

Joe Armstrong：关于Erlang，有很多东西我想改变

在过去的一年半里，我一直在全职使用 Erlang 进行编程。当涉及到复杂的分布式应用程序时，我认为没有任何其他语言或框架可以击败它。就我而言，它最大的优点是能够跟踪代码和消息的执行，甚至可以跨集群中的节点。

常规的代码单步调试对于简单的程序非常有用，但要让代码在具有多核的不同机器上每秒执行数千个任务是不可能的。在 Erlang 中进行跟踪可以让您查看在哪些进程中使用哪些参数调用了哪些函数，以及它们之间传递了哪些消息。此功能开箱即用，甚至可以在生产系统中使用（如果您小心的话！）。

尽管跟踪是内置在 Erlang 中的，但最好的入门方法是使用[eper](https://github.com/massemanet/eper)中的 Redbug 库。我发现通过示例来解释 redbug 更容易。首先要记住的主要事情是它是自我说明的。只需在控制台中输入：

<Code language="erlang">
{`> redbug:help().`}
</Code>

所以让我们开始吧。要跟踪任何 Erlang 进程中的函数调用，您可以使用如下内容：

<Code language="erlang">
{`1> redbug:start("lists:sort").
{30,2}
2> lists:sort([1,2,3,4]).
[1,2,3,4]

% 18:59:08 <0.32.0>({erlang,apply,2})
% lists:sort([1,2,3,4])
redbug done, timeout - 1
3>`}
</Code>

这将启动 redbug 进程，该进程将运行 15 秒，并将通知您对列表模块中的排序函数进行的任何调用。迅速自行关闭是 redbug 的优点之一。跟踪的工作原理是从运行与我们的请求匹配的代码的进程向您启动 redbug 的进程发送消息。如果您在运行数千个瞬态 Erlang 进程的系统中指定常用函数，事情可能会很快失控，甚至导致节点崩溃。

其他类似的跟踪函数调用的方法是：

<Code language="erlang">
{`% Trace multiple functions at once
 1> redbug:start(["erlang:term_to_binary", "lists:sort"]).
 % Trace only the version of this function that takes 2 parameters
 2> redbug:start("erlang:term_to_binary/2"]).
 % Trace any function in the lists module
 3> redbug:start("lists"). `}
</Code>

您还可以将跟踪限制为使用某些值作为参数调用的函数。例如：

<Code language="erlang">
{`% Only trace calls to lists:sort when it's passed the list [1,2,3]
 1> redbug:start("lists:sort([1,2,3]").`}
</Code>

Erlang 的模式匹配可用于仅匹配某些参数，或仅匹配参数的某些部分。这里只跟踪以 3 作为第一个参数的 lists:member 的调用：

<Code language="erlang">
{`10> redbug:start("lists:member(3,_)").
{30,1}
11> lists:member(3, [1,2]).

% 19:18:45 <0.32.0>({erlang,apply,2})
% lists:member(3, [1,2])
false
12> lists:member(4, [1,2]).
false`}
</Code>

您可以（并且应该！）对您的模式非常感兴趣。唉，redbug 目前不允许在二进制文件上进行匹配。但是你可以使用几乎任何你可以在 Erlang 函数中使用的守卫：

<Code language="erlang">
{`% Only match if the only argument is a binary of size 10
1> redbug:start("erlang:term_to_binary(B) when is_binary(B), size(B) == 10").
% Only if the argument is a list where the first element is greater than 9
2> redbug:start("lists:sort([A|_]) when A > 9").
% Only if the argument is a two tuple with 'tag' as the first element
3> redbug:start("erlang:term_to_binary({tag, _}).`}
</Code>

有时您想知道跟踪的函数返回什么，或者在执行时获取堆栈跟踪。或者两者兼而有之：

<Code language="erlang">
{`1> redbug:start("lists:max->return").
2> redbug:start("lists:max->stack").
3> redbug:start("lists:max->return;stack").`}
</Code>

如果你运行上面的例子并调用lists:max，你会看到它是一个递归函数。这意味着您可能会收到比预期更多的消息。幸运的是，redbug 会在收到一定数量的消息后自行关闭以保护您。您可以控制它的停留时间和它处理的最大消息数，如下所示：

<Code language="erlang">
{`% Process at most 1000 messages or
% stay up for 60 seconds, whatever happens first.
1> redbug:start(["lists->return", "erlang:term_to_binary/2->stack"],
 [{msgs, 1000}, {time, 60000}]).`}
</Code>

其他参数可让您以许多有用的方式自定义 redbug。只需查看 redbug:help 了解详细信息。您可以将输出重定向到一个文件，使用正则表达式对其进行过滤，省略传递给跟踪函数的参数值，更改消息的大小限制（如果使用大量参数跟踪函数调用，redbug 也会关闭）等等。

在稍后的文章中，我们可以探索有关 redbug 和 Erlang 中底层跟踪机制的更多细节。尽管 redbug 很有用，但很多时候您需要完全访问跟踪原语。这通常意味着你遇到了很多麻烦:)。

使用 Redbug 跟踪 Erlang

## 描述

redbug 是一个与 Erlang 跟踪工具交互的工具。当某些事件（例如特定函数被调用）发生时，它将指示 Erlang VM 生成所谓的“跟踪消息”。它使用跟踪功能的一个安全子集，如果感觉过载（例如如果它被跟踪消息淹没）则主动退出。它在后台运行，收集跟踪消息，直到达到其终止条件之一（消息数、文件大小或经过的时间）。

跟踪消息要么打印（即人类可读）到文件或屏幕上，要么写入 trc 文件。使用 trc 文件对系统的压力较小，但无法对消息进行计数（因此“msgs”选项被忽略），并且只能通过特殊工具（例如“bread”）读取文件。打印和 trc 文件不能合并。默认情况下（即如果未给出“文件”选项），则打印消息。

## 记录（Record）

记录（Record)与其他 Erlang 集合类型（列表、映射和元组）不同，因为它们是编译时构造的（在编译之前它们被转换为元组）。

因此，记录名称不是全局唯一的，而是每个模块唯一的。 redbug 通过允许使用语法“module#record”来指定记录处理这个问题。例如。像：

<Code language="erlang">
{`redbug:start("m:f(m#rec{a = b})").`}
</Code>

为了在返回值中打印记录字段名称，必须告诉 redbug 在哪些模块中查找记录。使用 \{records, [Module]\} 选项。

## DTOP

dtop 给出了系统的每个进程的视图。与 top 的相似之处在于它每 N（默认 2）秒提示一屏信息。每个screenful由一个header和每个process一行组成。

<Code language="shell">
{`-------------------------------------------------------------------------------
nonode@nohost size: 22.3M(2.6G), cpu%: 2(13), procs: 71, runq: 0, 18:21:19
memory: proc 5.9M, atom 442.6k, bin 1.0M, code 7.4M, ets 794.4k

pid name current msgq mem cpu
<0.10.0> erl_prim_loader erl_prim_loader:l 0 1.1M 1
<0.194.0> redbug_dtop redbug_dtop:prc_i 0 111.6k 1
<0.50.0> code_server code_server:loop/ 0 176.3k 0`}
</Code>

## PRINTER

默认情况下，printer函数会写入如下所示的标题行；

<Code language="erlang">
{`% 18:38:50 <0.188.0>({erlang,apply,2})`}
</Code>

时间戳、pid 和进程名称；如果存在则注册名称，否则为进程的 inti 函数。

一个函数调用是这样打印的：

<Code language="erlang">
{`% erlang:demonitor(#Ref<0.2419348116.2832203778.13012>)`}
</Code>

从这样的函数中返回；

<Code language="erlang">
{`% erlang:demonitor/1 -> true`}
</Code>

即 module:function/arity -> return value

## 例子

基本的call trace

<Code language="erlang">
{`1> redbug:start("erlang:demonitor").
{75,2}

% 18:27:21 <0.188.0>({erlang,apply,2})
% erlang:demonitor(#Ref<0.2419348116.2832203778.12948>)

% 18:27:21 <0.188.0>({erlang,apply,2})
% erlang:demonitor(#Ref<0.2419348116.2832203777.10938>, [flush])

% 18:27:21 <0.188.0>({erlang,apply,2})
% erlang:demonitor(#Ref<0.2419348116.2832203777.10939>, [flush])

% 18:27:21 <0.188.0>({erlang,apply,2})
% erlang:demonitor(#Ref<0.2419348116.2832203777.10940>, [flush])
redbug done, timeout - 4`}
</Code>

如上，打印返回值。返回值是单独的消息。

<Code language="erlang">
{`2> redbug:start("erlang:demonitor->return",[{msgs,2}]).
{75,2}

% 18:31:15 <0.188.0>({erlang,apply,2})
% erlang:demonitor(#Ref<0.2419348116.2832203780.10535>)

% 18:31:15 <0.188.0>({erlang,apply,2})
% erlang:demonitor/1 -> true
redbug done, msg_count - 1`}
</Code>

如上，还打印调用堆栈。请注意，并非调用链中的所有函数都在堆栈上，只有我们将返回的函数（这是尾调用优化的结果。）

<Code language="erlang">
{`4> redbug:start("erlang:demonitor->return,stack",[{msgs,2}]).
{75,2}

% 18:32:54 <0.188.0>({erlang,apply,2})
% erlang:demonitor(#Ref<0.2419348116.2832203778.13012>)
% redbug:block_a_little/0
% redbug:start/2
% erl_eval:do_apply/6
% shell:exprs/7
% shell:eval_exprs/7
% shell:eval_loop/3

% 18:32:54 <0.188.0>({erlang,apply,2})
% erlang:demonitor/1 -> true
redbug done, msg_count - 1`}
</Code>

跟踪 shell 进程收到的消息。

<Code language="erlang">
{`5> redbug:start('receive',[{procs,[self()]}]).
{1,0}

% 18:35:16 <0.188.0>({erlang,apply,2})
% <<< {running,1,0}

% 18:35:16 <0.188.0>({erlang,apply,2})
% <<< {io_reply,#Ref<0.2419348116.2832203778.13028>,150}

% 18:35:16 <0.188.0>({erlang,apply,2})
% <<< {io_reply,#Ref<0.2419348116.2832203778.13029>,
[{expand_fun,#Fun<group.0.90280613>},
{echo,true},
{binary,false},
{encoding,unicode}]}

% 18:35:16 <0.188.0>({erlang,apply,2})
% <<< {io_reply,#Ref<0.2419348116.2832203778.13030>,ok}`}
</Code>

如上所述，还跟踪来自 shell 进程发送的消息。请注意，在这种情况下，“print_pid”选项将隐藏有发送到组服务器的信息。

<Code language="erlang">
{`7> redbug:start([send,'receive'],[{procs,[self()]}]).
{1,0}

% 18:36:25 <0.188.0>({erlang,apply,2})
% <<< {running,1,0}

% 18:36:25 <0.188.0>({erlang,apply,2})
% <0.186.0>({group,server,3}) <<< {io_request,<0.188.0>,
#Ref<0.2419348116.2832203777.10998>,
{get_geometry,columns}}
redbug done, timeout - 2`}
</Code>

与函数头部匹配的调用跟踪。请注意，对 ets:tab2list/1 的第一次调用不会触发跟踪器。

<Code language="erlang">
{`8> redbug:start("ets:tab2list(inet_db)",[{msgs,2},print_pid]).
{30,1}
9> ets:tab2list(ac_tab),ok.
ok
10> ets:tab2list(inet_db),ok.
ok
% 18:38:50 <0.188.0>({erlang,apply,2})
% ets:tab2list(inet_db)
redbug done, timeout - 1`}
</Code>

如上所述，但使用“blocking”选项。 redbug:start/2 阻塞直到跟踪结束，并返回停止原因和跟踪消息列表。

<Code language="erlang">
{`11> spawn(fun()->receive after 2000->ets:tab2list(inet_db) end end),redbug:start("ets:tab2list(inet_db)",[blocking,{time,3000}]).
{timeout,[{call,{{ets,tab2list,[inet_db]},<<>>},
 {<0.273.0>,dead},
 {18,42,17,555959}}]}`}
</Code>

从文件中读取record定义

<Code language="erlang">
{`12> redbug:start("file:read_file_info->return",#{records=>[file]}), file:read_file_info("/").

% 14:43:06 <0.205.0>({erlang,apply,2})
% file:read_file_info("/")

% 14:43:06 <0.205.0>({erlang,apply,2})
% file:read_file_info/1 -> {ok,{file_info,
[{size,4096},
{type,directory},
{access,read},
{atime,{{2020,3,28},{11,51,5}}},
{mtime,{{2020,2,2},{11,42,36}}},
{ctime,{{2020,2,2},{11,42,36}}},
{mode,16877},
{links,22},
{major_device,64769},
{minor_device,0},
{inode,2},
{uid,0},
{gid,0}]}}
redbug done, timeout - 1`}
</Code>

使用 module#record 语法来指定匹配。

<Code language="erlang">
{`13> redbug:start("erlang:tuple_size(file#file_info{size = 666})->return",[arity]).
14> rr(file),tuple_size(#file_info{size=666}).

% 14:51:25 <0.205.0>({erlang,apply,2})
% erlang:tuple_size/1

% 14:51:25 <0.205.0>({erlang,apply,2})
% erlang:tuple_size/1 -> 14
redbug done, timeout - 1`}
</Code>

redbug使用指南

在本文中，我将展示使用 Homebrew 和 asdf 从头开始将 Erlang 和 Elixir 安装到 Apple Silicon Mac 的完美步骤。

## 1.升级macOS（如果是CPU芯片是M1）

对于 M1 Pro/Max，您可以跳过此步骤。

如果CPU芯片是 M1，预装的 macOS 是 Big Sur。 因此，首先，您需要将 macOS 升级到 Monterey 12.1。 但是，由于 Monterey 安装程序的缺陷，从预装的 macOS Big Sur 升级到 Monterey 会失败。 因此，您应该首先更新 Big Sur。 接下来，将其升级到 Monterey 12.0.1。 接下来，将其更新为 Monterey 12.1。

## 2.安装Xcode 13.2.1（可选）

如果您将使用 Homebrew 进行安装，也可以跳过此步骤。

通过 App Store 安装 Xcode 13.2.1。

## 3.安装Homebrew

1. 启动终端。
2. 根据官网安装 Homebrew。
3. 安装后运行输出结果中显示的命令。

上面提到的命令如下（sudo命令需要你输入登录密码）：

<Code language="shell">
{`/bin/bash -c "$(curl -fsSL https://raw.githubusercontent.com/Homebrew/install/HEAD/install.sh)"
echo 'eval "\$(/opt/homebrew/bin/brew shellenv)"' >> \${ZDOTDIR:-~}/.zprofile
eval "\$(/opt/homebrew/bin/brew shellenv)"`}
</Code>

请务必查看并使用官网的安装过程和安装后显示的命令。

## 4.通过 Homebrew 安装 Erlang 和 Elixir

在终端运行以下命令：

<Code language="shell">
{`brew update
brew install elixir`}
</Code>

这些命令安装最新版本的 Erlang 和 Elixir。 如果您只使用最新的版本，这些命令将是最简单的。

## 4′. 通过Homebrew 安装 Erlang

如果您只想安装 Erlang，请在终端运行以下命令：

<Code language="shell">
{`brew update
brew install erlang`}
</Code>

## 4”. 通过 asdf 安装 Erlang 和 Elixir

不幸的是，如果使用asdf进行安装，官网上的安装程序是不完整的：unlinked wx 和 odbc，缺少文件等。

## 4”-1. 通过 Homebrew 安装 asdf

根据官网通过 Homebrew 来安装 asdf。 运行的命令如下，但您应该查看官方网站确认：

<Code language="shell">
{`brew install asdf
echo -e "\n. $(brew --prefix asdf)/libexec/asdf.sh" >> \${ZDOTDIR:-~}/.zshrc
source \${ZDOTDIR:-~}/.zshrc`}
</Code>

## 4”-2. 通过 asdf 安装 Erlang

这一步是最重要的。 首先，安装事先准备好的必备库：

<Code language="shell">
{`asdf plugin add erlang https://github.com/asdf-vm/asdf-erlang.git
brew install wxwidgets
brew install openjdk
echo 'export PATH="/opt/homebrew/opt/openjdk/bin:\$PATH"' >> \${ZDOTDIR:-~}/.zshrc
source \${ZDOTDIR:-~}/.zshrc
brew install fop`}
</Code>

然后，设置环境变量 KERL_CONFIGURE_OPTION、CC 和 LDFLAGS 如下：

<Code language="shell">
{`export KERL_CONFIGURE_OPTIONS="--with-ssl=$(brew --prefix openssl@1.1) --with-odbc=$(brew --prefix unixodbc)"
export CC="/usr/bin/clang -I\$(brew --prefix unixodbc)/include" 
export LDFLAGS=-L\$(brew --prefix unixodbc)/lib`}
</Code>

如果您将安装 Erlang/OTP 24.2+ 并使用 OpenSSL 3，请安装 OpenSSL 3 并重置 KERL_CONFIGURE_OPTION：

<Code language="shell">
{`brew install openssl@3
export KERL_CONFIGURE_OPTIONS="--with-ssl=$(brew --prefix openssl@3) --with-odbc=$(brew --prefix unixodbc)"`}
</Code>

我通过引用此问题获得了链接 odbc 的解决方案：https://github.com/asdf-vm/asdf-erlang/issues/191

接下来，如果您要安装最新版本，请运行以下命令：

<Code language="shell">
{`asdf install erlang latest
asdf global erlang latest`}
</Code>

您可以获得可以安装的版本，如下所示：

<Code language="shell">
{`asdf list-all erlang`}
</Code>

不幸的是，某些特定的旧版本无法安装到 Apple Silicon Mac 中。

如果您要安装 OTP 22，请遵循以下问题：https://github.com/asdf-vm/asdf-erlang/issues/221

安装后，取消设置 CC 和 LDFLAGS：

<Code language="shell">
{`unset CC LDFLAGS`}
</Code>

## 4”-3. 通过 asdf 安装 Elixir

按照官网通过 asdf 安装 Elixir 插件。

<Code language="shell">
{`asdf plugin-add elixir https://github.com/asdf-vm/asdf-elixir.git`}
</Code>

接下来，如果您要安装最新版本，请运行以下命令：

<Code language="shell">
{`asdf install elixir latest
asdf global elixir latest`}
</Code>

您可以获得可以安装的版本，如下所示：

<Code language="shell">
{`asdf list-all elixir`}
</Code>

## 结束语

按照上述步骤，您将在 Apple Silicon 上获得 Elixir 和 Erlang。

将 Erlang 和 Elixir 安装到 Apple Silicon Mac 的完美步骤

## 介绍

许多编程语言会定期发布新版本，以添加或弃用功能、修复错误并引入重大更改。为了帮助开发人员轻松地在版本之间切换，一些语言社区都有版本管理器（例如用于 Node.js 的 NVM 或用于 Ruby 的 Rbenv）。但是，当您需要一次切换多种语言的版本时，ASDF 版本管理器可确保每个项目都有所需的环境。

这在需要 Erlang 运行时的 Elixir 项目中尤其重要。在本指南中，您将了解如何在 macOS 或 Linux 上使用 ASDF 版本管理器安装特定版本的 Elixir 和 Erlang/OTP。

## 安装 ASDF

[ASDF版本管理器](https://github.com/asdf-vm/asdf)是 GitHub 上提供的命令行工具。它使用curl并git安装各种语言。

### 安装先决条件

要安装curl和git实用程序，请运行：

<Code language="shell">
{`brew install coreutils curl git # on macOS with Homebrew
sudo apt install curl git # on Linux`}
</Code>

您可以在[此处](https://brew.sh/)了解有关 macOS 上 Homebrew 的更多信息。

### Clone ASDF

安装了先决条件后，现在克隆 ASDF 项目：

<Code language="shell">
{`git clone https://github.com/asdf-vm/asdf.git ~/.asdf`}
</Code>

如果您希望删除 ASDF，可以通过.asdf从主目录中删除并撤消下面描述的配置更改来实现。

### 配置你的Shell

最后，在你的 shell 配置中包含 ASDF。对于zsh，将以下内容添加到~/.zshrc：

<Code language="shell">
{`. $HOME/.asdf/asdf.sh`}
</Code>

或者，如果您使用oh-my-zsh，添加asdf到您的插件配置。要在使用不同的 shell 时将 ASDF 包含在您的配置中，请参阅[文档](https://asdf-vm.com/#/core-manage-asdf?id=install)。

## 安装插件

ASDF 使用插件系统来支持多种语言。对于典型的 Elixir 项目，您将需要 Elixir 和 Erlang 插件：

<Code language="shell">
{`asdf plugin add erlang
asdf plugin add elixir`}
</Code>

如果您的项目需要 Node.js，您也可以安装该nodejs插件。

## 安装 Erlang/OTP

安装 ASDF 及其插件后，您现在可以安装 Elixir 和 Erlang。如果您的项目有一个.tool-versions包含 和 条目的文件elixir，erlang您可以通过在项目内部运行以下命令来安装正确的版本：

<Code language="shell">
{`asdf install`}
</Code>

该.tool-versions文件很像.nvmrc和.ruby-version文件，只是它列出了多种语言的名称和版本。通常，此文件中的名称应与语言插件的名称匹配（例如nodejs，对于 Node.js）。

如果您还没有.tool-versions文件，或者想要全局安装 Elixir 和 Erlang，请使用以下命令查看所有可用 Erlang/OTP 版本的列表：

<Code language="shell">
{`asdf list-all erlang
# ...
23.2
23.2.1
23.2.2
# ...`}
</Code>

与其他版本管理器不同，ASDF 要求您指定要安装的语言的精确版本。要安装23.2.1Erlang 版本，请运行：

<Code language="shell">
{`asdf install erlang 23.2.1`}
</Code>

**警告**：从源代码编译 Erlang 时，此安装将需要一些时间。

Erlang 将根据您系统中可用的库编译模块。例如，某些功能（例如内置的观察者）需要wx库。您可能会在安装过程中看到有关省略模块的消息，这不会影响运行时的其余部分。

## 安装 Elixir

一旦安装了 Erlang 运行时，您就可以安装 Elixir。要查看所有可用版本的列表，请运行：

<Code language="shell">
{`asdf list-all elixir
# ...
1.11.2
1.11.2-otp-21
1.11.2-otp-22
1.11.2-otp-23
# ...`}
</Code>

请注意，每个 Elixir 版本都有多个使用不同主要版本的 Erlang/OTP 编译的版本。为了最大限度地提高 Elixir 和 Erlang 运行时之间的兼容性，请选择-otp-XY与您在上一步中安装的运行时的主要版本相匹配的版本。例如：

<Code language="shell">
{`asdf install elixir 1.11.2-otp-23`}
</Code>

安装 Elixir 比安装 Erlang/OTP 花费的时间要少得多。

## 设置版本

现在您已经安装了 Elixir 和 Erlang/OTP，您可以将选择的版本保存在项目中。从项目的根目录运行：

<Code language="shell">
{`asdf local erlang 23.2.1
asdf local elixir 1.11.2-otp-23`}
</Code>

将上述版本替换为您在安装过程中使用的版本。这将在您的项目中创建一个.tool-versions文件，该文件将指示 ASDF 使用哪些版本。如果您想设置全局或默认版本，请运行：

<Code language="shell">
{`asdf global erlang 23.2.1
asdf global elixir 1.11.2-otp-23`}
</Code>

这将在您的主目录中创建一个.tool-versions文件。只要项目没有指定自己的版本，ASDF 就会使用这些版本。

## 结论

ASDF 是 Elixir 项目的流行版本管理器，因为它同时管理 Elixir 和 Erlang 版本。在您的项目中包含一个.tool-versions文件，以帮助贡献者快速启动和运行，并且不要忘记利用-otp-XYElixir 的版本以获得最佳兼容性。

如果您想了解有关 Elixir 的更多信息以及它可以为您的下一个项目做什么，请在 Pluralsight 上查看[Elixir：The Big Picture](https://app.pluralsight.com/library/courses/elixir-big-picture/)。

使用 ASDF 安装 Elixir 和 Erlang

首先，我想谈谈 Erlang 在 2010 年被 KAZOO 选中的一些较高层次原因。即使你不是技术人员，我希望你能在阅读本文中找到一些价值。

## 一些 Erlang 的历史

Erlang 于 1986 年在爱立信开发，并于 1998 年开源。它旨在改进爱立信内部电话应用程序的开发。

Erlang 可以分为三个主要部分：

1. Erlang 语言 – 一种规则和语法相对较少的小语言（与其他现代语言相比）
2. 开放电信平台 (OTP) – 中间件、库和工具的集合
3. Erlang 虚拟机 (BEAM) – 执行已编译 Erlang 的指令（如果您熟悉Java的话，类似于 JVM）。

语言、OTP 的特性与运行 BEAM 相结合，提供了一个强大的平台，在该平台上构建需要容错性和面对错误时的弹性的系统。

## 一些 KAZOO/2600Hz 历史

了解现在 KAZOO 的主要途径源于Darren 和 Karl 运营电信基础设施的经验以及更广泛的社区经验。随着 2600Hz 就其电信基础设施咨询越来越多的公司，人们如何构建这些系统的模式和共同痛点出现了。KAZOO 旨在解决这些共性问题，同时还公开了允许运营商和经销商提供真正增值功能的功能。归根结底，大多数电信都是僵硬的、常规的和商品化的——连接两部电话或提供语音邮件不会赢得客户的心。

## 表面之下

客户甚至服务提供商的管理层可能不理解或不欣赏的是以下方面的所有复杂性和困难：

- 编写优雅地处理错误的软件
- 跨多个服务器扩展所述软件
- 跨多个数据中心扩展所述服务器集群

## 单服务器软件

大多数软件（包括电信）都是为在单个服务器上运行而编写的。随着服务器处理负载的增加，软件的应对能力下降，最终达到硬件本身的极限。

想象一个发展中的小镇，只有一家杂货店，居民没有办法开车去其他城镇——杂货店的过道会挤满人，结账排队的等待时间会很可怕（商店只能容纳这么多的店员和收银员） .

当商店出现问题（例如，鸡蛋掉在地板上）时，需要更长的时间才能修复，并且不相关的客户将受到影响。商店没有优雅地处理错误。

Erlang 提供了一种方法来管理这种复杂性并使各个客户（流程）彼此隔离。现在一位顾客掉下的鸡蛋不会影响其他任何人！一个客户的大订单不必把所有其他客户都挡在他们身后；寄存器可以动态地打开和关闭以适应需求（当然仍然受商店的空间限制 – 我们在这里没有违反物理定律！）。

但是，单个服务器上的软件是存在单点故障的(SPOF)！任何数量的事件——意外的、预期的或恶意的——都可能使服务器无法访问。

## 添加服务器

在某个时刻，很明显需要一家新商店。传统方法是添加新服务器（杂货店）并将工作（客户）直接添加到其中一个或另一个（这通常是运行负载平衡器的服务器）。负载均衡器引入了新的复杂性，因为工作单元（客户）并不相同。

## 平衡工作

可供选择的选项是使用像循环这样的“哑”负载共享算法，或者创建一个必须与底层服务器通信的“智能”负载平衡器，以了解哪个服务器有能力接受更多工作。

循环和类似策略的最大缺点是负载分担不平衡（一家杂货店吸引了所有有需要的顾客并陷入困境，而另一家商店则获得了所有只是“仅仅需要鸡蛋”的顾客，而商店仍然大部分是空的）。

当然，使用“智能”选项，这些智能需要由某人构建，现在您有第三台服务器进行通信（具有分布式系统的所有讨厌的东西）。

## 协调工作

不是为跨服务器运行而设计的软件的另一个问题是它们彼此之间不协调。在杂货店的类比中，如果 1 号商店的屠夫知道顾客在 9:00 左右来取一块特定的肉，那么屠夫可以为该顾客准备好（预热缓存），从而加快，为客户提供更愉快的体验（电话连接速度可能更快）。如果由于某种原因客户偏离并去商店#2，与之前的访问相比，该服务将是次优的。

软件通常通过使用共享数据库（通常在单独的机器上）来解决这个问题。而你现在又有了单点孤战（ SPOF）！如果无法访问数据库服务器，则服务器也将无法运行。所以现在你需要第二个数据库服务器和一些冗余。

## Erlang 使服务器间通信更容易

Erlang 为程序员提供了工具，使与其他服务器的进程（运行 BEAM 的副本）的对话和与本地 BEAM 及其进程的对话一样简单和透明。如果服务器无法访问，则可以设置现有服务器以接收这些事件并做出相应反应。应用在上个例子中，两家商店的屠夫都可以就客户的需求进行沟通，并且无论客户选择哪家商店，他们都做好了准备。

## 添加数据中心

既然软件有一个共享数据库并且已经解决了 SPOF，那么软件需要考虑通过更广域网 (WAN) 进行通信——这通常是公共互联网。看，开发人员对计算机如何相互通信做出假设——大​​多数人只是假设来自一台计算机的数据包将以快速有序的方式到达目的地。然后根据这些错误的假设编写软件。虽然软件在单个数据中心运行（通常使用非常好的网络电缆和设备），但这些假设似乎成立。

但即使是数据中心也可能无法访问。公用事业公司意外切断了光纤电缆，飓风淹没了数据中心，带宽提供商出现了中断——这些事件的发生比大多数人想象的要多！然后，软件以意想不到的方式中断，找出原因成为一场噩梦。

## 实际问题

既然软件必须通过不太可靠的网络（数据中心间、公共互联网）和收费的电路进行通信（通常网络内通信是免费的或非常廉价的），技术上的新问题（增加的延迟、带宽饱和、丢包/重传）和业务（更高的带宽成本、数据中心扩建、新数据中心的本地技术？）成为新的现实。

例如，可以对本地网络上的服务器进行编程，以定期同步它们的状态（它们各自的世界），以保持基本一致的观点。根据系统的不同，这可能会导致使用许多额外的兆字节、千兆字节甚至 TB 的带宽，只是为了同步！（这甚至没有计算用于处理实际工作的带宽）。该数据不会立即传输，也不会免费传输（Amazon EC2 的起价为 0.09 美元/GB）。想象一下，由于服务器占用带宽来同步它们的状态，电话呼叫被延迟或现有呼叫的音频断断续续！

## 技术问题

有大量的计算机科学致力于分布式计算以及不可靠通信带来的所有痛点。遗憾的是，大多数程序员不太可能处理过这些类型的系统，或者没有适当的工具和基础设施来构建处理这些分布式计算问题的系统。

Erlang 本身也不是灵丹妙药。默认的通信机制在不可靠的网络上效果不佳。然而，一些项目正在解决这一差距，包括[Lasp](https://github.com/lasp-lang/lasp)、[Partisan](https://github.com/lasp-lang/partisan)和[Riak 流程组](https://github.com/cmeiklejohn/riak_pg)等。也可以使用其他技术（如Kazoo 所做的[RabbitMQ](https://www.rabbitmq.com/)）来帮助解决这个问题。

要将这些基础设施组件与不是为其设计的软件一起使用，需要大量投资来重写软件，或者更常见的是，软件将尝试在软件本身内模拟功能（而且通常很差）。

## 大多数电信基础设施的问题

简而言之，目前的软件不是为跨地理分布的网络运行而设计的，也没有考虑通过不可靠的网络进行通信所固有的错误和问题。这些功能通常是在来自管理层的压力和分布式系统开发经验不足的团队的压力下设计的，因此通常实施不善，并且充斥着错误和效率低下。

然而，无论好坏，软件在很大程度上是因为底层基础设施是健壮的——这会滋生一种虚假的安全感，营销团队开始用“可靠性”和“冗余”来描述他们公司的产品。

然而，当事情确实出错时（正如墨菲定律所示，它们总是这样），代价是要付出很多倍的。“一点点的预防胜过无数的治疗”。

## 那么为什么选择 Erlang？

鉴于事情确实出错了，即使是最聪明的团队也无法预料到所有错误，所以工作是从最低级别开始优雅地处理已知和未知错误（容错）是理所当然的。

Erlang 有一个与工作单元相关的“任其崩溃（Let it crash）”的理念 – 如果数据错误，外部资源不可用，无论如何，让工作者进程崩溃（停止它）并让监督进程处理崩溃。这可能是重新启动一个新的工作者进程，将错误上升并响应，记录崩溃并继续，或者任何数量的所需策略。Erlang 和 OTP 的价值在于将这些问题放在首位和中心位置，并为程序员提供了有序处理它们的工具。

因为启动和停止工作进程是微不足道的，所以代码的架构受益于将“工作”与工作的“管理”和“监督”分开。结果，代码变得更小更简洁（在 Erlang 中，人们会说“快乐的编程”），这使得推理更容易，测试更容易，并且通常应该更快地生成更好的代码。

## 放到一起

Erlang 提供了用于构建容错、弹性系统的语言 (Erlang)、框架 (OTP) 和运行时 (BEAM)。拥抱“Let it crash”的理念产生的代码可以更优雅地处理错误，允许系统作为一个整体在出现这些错误时保持稳定。

在此基础上，构建了高可用性、容错系统。

在以后的文章中，我将更深入地探讨 KAZOO 在 Erlang 的基础上做出的一些架构决策，以及这些决策如何影响 KAZOO 集群在所有级别的错误面前运行的能力，即使各个数据中心运行的代码因飓风洪水而消失。

为什么选择Erlang

我以前听说过很多编程轶事声称，当您使用 Erlang 而不是 \[C++/其他语言\] 编写时，可以节省多少行代码。我很高兴地告诉大家，我现在有第一手经验和一些数据可以分享。

我最初是用 C++ 编写 Playdar（使用 Boost 和 Asio 库），从今年 2 月开始。我很幸运能与一些经验丰富的开发人员一起工作，是他们帮助我熟悉了 C++。直到几个月前，我们中的三个人经常对它进行黑客攻击，尽管对 C++ 来说相对较新，但我会说我们最终得到了一个考虑到所有因素的设计良好且健壮的代码库。

## 自鸣得意

我承认，我觉得让这一切都在 C++ 中通过使用 Boost 和 ASIO库而正常工作感到相当自鸣得意。让它在所有三个平台上构建并在运行时以跨平台的方式动态加载扩展（DLL 等）也非常令人满意。我学到了很多关于 C++、Boost、ASIO 和 CMake 的知识。但是，随着代码库的增长，我开始严重质疑我使用 C++ 的决定。

我最初选择 C++ 的原因有两个：

- 分发（Distribution）——发布 Erlang VM 听起来并不有趣
- [Taglib](http://developer.kde.org/~wheeler/taglib.html) —— 用于从音频文件（mp3、m4a、ogg 等）读取元数据的C++库。

事实证明，Playdar 自然非常适合 Erlang – 它并行执行许多操作，并且它执行的许多操作都是异步和基于事件的。即使你用 Boost 获得了所有的东西，但说的好听点，C++ 中的多线程中很多东西是不优雅的。

## SLOCed and Loaded

无论如何，几周前我坐下来用 Erlang 从头开始重新实现 Playdar。我在几天内彻底解决了它的内容，到本周末，我几乎拥有它与 C++ 代码库的 1:1 功能。还有一点： C++ 与 taglib 交互的代码。使用 SLOCcount 工具（SLOC=源代码行数）我计算了两个代码库中各个模块中的代码行数，结果如下：

|模块|Erlang 版本|C++ 版本|节约|
|:-- |:--       |:--    |:--|
|Core Daemon|1,100|4,491|75%|
|Library + Scanner|197 + 167.cpp|1,355|73%|
|LAN Resolver|105|427|75%|
|P2P|463|1,762|74%|
|TOTAL|2,032|8,035|75%|

**与 C++ 相比，使用 Erlang 来实现相同的东西减少了 75% 的代码行** 🙂 。第二次用 Erlang 编写时，我确切地知道我在构建什么，所以比较两个代码库的开发时间是不公平的，但是考虑到我的打字速度有多快，我认为我节省了敲击键盘输入代码的好几个小时（以及无数小时的调试：Erlang 往往第一次就正常工作，真的）。好吧，我不确定“已节省”是否是正确的词，考虑到它已经在 C++ 中工作，但这是我浪费的时间:)

如果您计算与两个代码库捆绑在一起的第三方代码（不包括 boost/asio！），那么 erlang 代码库可以节省高达 92% 的成本。然而，我对节省我必须编写的代码更感兴趣。

## 内存和 CPU 使用率

我已经对这两个项目进行了一些初步比较，在 CPU 和内存使用方面，这两个项目非常相似。目前，Erlang 代码库使用的内存比 C++ 略多，但我确信我可以将其降低到至少与 C++ 项目一样低。我从今年早些时候使用 Erlang进行的[Million-user comet experiment](http://www.metabrew.com/article/a-million-user-comet-application-with-mochiweb-part-1/)中学到了一些优化技巧。如果我学到任何新技巧，我会发布更多关于此的信息。

关于 Erlang 代码库，我意识到的一件事是，我使用进程来封装我并不真正需要的状态（特别是活动查询）。这在当时似乎是明智的，但它可能只是浪费内存。我将把它改成生成进程来完成工作（即运行查询的进程），但不一定只是为了维护状态。

## 分发到桌面
### C++

您只需要确保构建所有内容并附带 DLL，并在安装程序中检查所需的系统库（运行时 dll）。哦，请确保您不要更改主应用程序中的插件二进制接口，否则新插件在加载时会崩溃。添加一个检查，并小心用 mingw 编译 taglib 和其他东西，用 VC++ 编译其余的东西，否则事情可能会神秘地崩溃。我还听说了一个关于在插件代码中分配内存但在主应用程序中释放它的恐怖故事，当插件针对与主应用程序不同的 stdlib 编译时。这些都是标准课程，我寻求帮助的有经验的 C++ 开发人员没有遇到任何问题。**可安装包大小：2.5MB**

### Erlang

在 Erlang 代码库中编译和构建/加载插件在所有平台上都很简单，就像使用 VM 一样。我最初反对发布 Erlang VM，因为我认为这会很麻烦并且会大大增加下载大小。为桌面打包一个 Erlang 应用程序涉及获取已安装的 VM 目录结构并剥离所有文档、源代码和我们不使用的 Erlang 标准库的部分，然后将其与编译的 Playdar 代码一起打包。[CouchDB](http://couchdb.apache.org/)也做了类似的事情，并且[RabbitMQ](http://www.rabbitmq.com/)发布了 Erlang VM 而不剥离不需要的库。我们将进一步打包（适用于所有平台），但迄今为止[Max](http://twitter.com/mxcl)制作了一个包，其中包含 Erlang VM 的必要部分、一个用于在 OS X 上启动/停止守护进程的 Prefpane，以及所有**大小都小于 10MB 的已编译 Playdar 代码**。

我们很快就会组装一个大小可能大致相同的 Windows 安装程序。现在 10MB 的下载量还不错，我希望我们可以进一步优化打包过程。Linux 用户将在他们的包管理器中获得一个依赖于 erlang VM 的包。似乎将 Erlang 应用程序发布到桌面并不是那么难。

## 结论

使用 Erlang 重写了一个 C++ 应用程序：相同功能的代码行数减少了 75%。



重写 Playdar：从C++ 到 Erlang，编程效率提升

经过多年大致了解有关 Erlang（和 Elixir）的表面知识后，我最近一直在学习 Erlang（和 Elixir）。 现实世界中有很多教你如何编写 Erlang 或 Elixir 程序的东西，但在这里我想写一篇概念性的文章，我希望在开始之前阅读。 Erlang 以一种既简洁又经久不衰的方式结合了一组旧思想。

Erlang 的并发模型特别使用了我已经知道的三个概念：尾递归优化、轻量级进程和异步消息。

## 尾递归调用

尾递归调用是一种递归调用，不需要保留当前堆栈帧，因此可以通过运行时进行智能优化。 这是一个通过 Elixir 中的尾调用表示的无限循环示例（因为它对大多数人来说更容易阅读）。

<Code language="erlang">
{`def loop() do
 # do stuff
 loop()
end`}
</Code>

当这个程序在 BEAM VM 上运行时，它被优化为更像 C 程序员所识别的命令式循环，如“while(true)”或“for(;;)”。 这在 Erlang/Elixir 中变得很重要，因为这些递归函数运行了很长时间，并形成了大多数长时间运行的 erlang 进程的主循环。

## 异步消息传递

Erlang 进程可以相互发送消息，并且消息发送到邮箱中。 让我们再次回到那个循环：

<Code language="erlang">
{`def loop() do
 result = receive do
 {:hello, name } -> name
 _ -> "?"
 end
 loop()
end`}
</Code>

当此函数到达接收函数时，进程进入睡眠状态，直到其邮箱中有消息出现。 所以现在这个小东西开始有点像服务器了。

## 合并到一起

这些想法对我来说并不新鲜，但是 Erlang 从它们以及它们结合的方式中获得了很多东西。 回到我们的循环，让我们添加一个参数来存储我们想要在这个过程中保留的一些状态：

<Code language="erlang">
{`defmodule Counter do
 def loop(value) do
 next_value = receive do
 {:add, number} -> value + number
 {:subtract, number} -> value - number
 end
 IO.puts(next_value)
 loop(next_value)
 end
end`}
</Code>

要创建这些计数器进程之一并向其发送消息，您需要执行以下操作：

<Code language="erlang">
{`pid = spawn fn () -> Counter.loop(0) end
send pid, {:add, 12}
# prints 12
send pid, {:subtract, 11}
# prints 1`}
</Code>

现在我们有一个较小的计数器循环，客户端可以发送消息增加或减少它。 除了发送消息之外，没有其他方法可以获取内容，而 Erlang VM 可以一次创建数千个这些进程，因为它们不是您常用的 C++ 或 Java 的线程。

## 进程

Erlang 调度器与我遇到的其他任何东西都不一样。 Erlang 进程经常被抢占，VM 非常注意进程必须运行多少时间，我想这是因为 Erlang 在电话领域的起源。 它们也是超轻量级的，如果一个崩溃它不会对系统的其余部分造成问题。

在实践中，这意味着你在 Erlang 中启动了一个新进程来做一些很难在系统级的操作系统线程的事情。 大型 erlang 程序可以在一台机器上运行数百万个这样的进程，它们彼此不共享任何状态，并且它们都通过异步消息进行通信。 对单个进程进行推理很容易，因为这些循环只依赖于它们的参数，就像任何函数式程序一样。 此外，您不必担心共享内存或锁，并且更难创建数据竞争。

## 为什么这很有趣？

Erlang 从中得到的一个小例子是，我们唯一需要再次启动这个循环的就是计数器的值。 所以如果我们想在不关闭系统的情况下部署这个循环的新版本，系统可以启动一个新版本的函数并且知道它是安全的。 据我了解，这或多或少是 Erlang 著名的“热代码重载”功能的工作原理。

Erlang 使用进程的另一件我以前从未见过的事情是 Supervisors，它们是观察其他进程并在它们崩溃或遇到其他问题时重新启动它们的进程。 supervisor依赖于我在这里没有涉及的东西，称为process link。 在实践中，大型 Erlang 系统的工作人员会在工作中愉快地运行，一旦进入糟糕的状态就会崩溃。 这是一种非常不同的方式，我认为思考错误的方式要好得多。

Erlang 的核心概念

今天，我们将看一个相当古老且有些古怪的东西。 你们大多数人可能没有注意到的语言。

虽然 Erlang 不像某些现代编程语言那样流行，但它安静地运行着 WhatsApp 和微信等每天为大量用户提供服务的应用程序。

在这篇文章中，我将告诉你关于这门语言的更多事情、它的历史，以及你是否应该考虑自己学习它。

## 什么是 Erlang，它在哪里使用？

Erlang 是一种函数式的通用语言，旨在构建具有高可用性保证的可扩展、并发系统。

它于 1980 年代末在爱立信建造，用于处理电话交换机。 当时，电话交换系统是最复杂的系统之一，就像现在的互联网一样。 出于这个原因，用于对其进行编程的语言需要支持高并发和零停机时间。

在经历了多种现有的语言选择之后，公司的三个人—— Joe Armstrong, Robert Virding, and Mike Williams——决定创建自己的语言。 这导致了最酷的编程语言之一的产生，也许是我见过的最棒的语言营销视频。

那么，这种语言与其他所有语言的区别是什么？

## 面向过程

Erlang 与其他语言的主要区别在于其基于进程的计算模型。 它使用隔离的、轻量级的进程，这些进程通过消息相互通信。

这些进程可以接收消息，并响应消息，创建新进程，向其他进程发送消息，或修改它们的状态。 换句话说，Erlang 遵循Actor模型。 如果您在 JVM 上使用过 Akka，您会感到非常熟悉。

![001](/images/blog/0028_001.jpeg)

这些进程是隔离的，创建速度很快，并且只占用少量内存。 通过创建更多进程可以轻松扩展您的系统。 由于这些进程无法辨别其他进程是在同一个核心上还是在另一个地方，因此您可以轻松地水平扩展（通过添加更多机器）和垂直扩展（通过添加核心）。

## 函数式

人们通常将 Erlang 与 Scala 和 Haskell 等其他语言归为一门函数式编程语言（FP)。 FP的一些特征是：

- 经常使用纯函数
- 高阶函数
- 模式匹配

有关函数式编程的更多信息，您可以在[introduction to FP](https://serokell.io/blog/introduction-to-functional-programming)中找到。

## Erlang有什么长处

首先，当涉及跨网络的多个代理之间的消息传递时，Erlang 是一个不错的选择，因为它很好地映射了语言的基本结构。

它非常适合：

- **聊天应用**。消息应用程序，包括一些著名的例子，如微信和 WhatsApp，使用 Erlang 来处理大量并发用户。 Erlang 有一个很棒的消息传递平台，叫做 ejabberd，可以用来创建大型聊天应用程序。
消息队列系统。 RabbitMQ 是一个实现 AMQP 和其他协议的开源消息代理，对于 Erlang 来说是一个巨大的成功案例。
- **区块链**。 Aeternity 是一个用于可扩展、安全和去中心化 dapp 的区块链，它使用 Erlang 来实现其节点。
- **二进制操作**。从历史上看，Erlang 必须支持快速实现用于电信目的的二进制协议。因此，它具有使二进制操作更加舒适的功能，例如二进制文件的模式匹配。例如，您可以使用 Erlang 作为十六进制编辑器。
- **其他分布式高性能服务**。如果您需要处理来自金融科技项目中大量地方的交易或创建竞价/用户匹配平台，Erlang 也不是最糟糕的选择。
 
您可以在我们的 Elixir 和 Erlang 公司列表中查看 Erlang 的一些常见用例。

## 这看起来很复杂。 我可以在 Erlang 中构建 Web 应用程序吗？

是的。 总体而言，Erlang 非常适合创建快速且可扩展的 Web 应用程序。 如果你到达那里，这是非常有益的。 不过，有一些警告。

您的 Web 应用程序（以及任何其他使用 HTTP 的应用程序）的核心将是 Cowboy，但除此之外，您还需要了解 Web 应用程序的组成部分并分别为每一层选择您的工具。

现实中有很好的文档，但新手级别的介绍性材料相对稀少，而且你不会找到所有内容的教程。 它不是 JavaScript。

总而言之，如果您决定构建 Web 应用程序，使用 Elixir（一种基于 Erlang 构建的语言）可能是更好的选择。

## 为什么要在项目中使用 Erlang？

与其他编程语言相比，Erlang 具有三个显着优势，这主要源于该语言的独特构建方式。

- **并发**。 Erlang 虚拟机 BEAM 使用轻量级的执行线程（称为进程）。 它们是完全隔离的，在所有 CPU 上运行，并通过消息进行通信。 由于这一点以及语言的功能特性，在 Erlang 中编写并发程序并不难。
- **可扩展性**。 Erlang 非常适合现代计算和当今多核 CPU 的分布式特性。 Erlang 进程允许我们通过添加更多机器和向现有机器添加更多内核来轻松扩展系统。
- **可靠性**。 Erlang 有一个座右铭——“Let it crash”。 由于独特的容错方法，监督系统可以快速重启轻量级进程，从而帮助您构建自愈系统。 虽然这可能看起来不可靠，但它处理了大多数不是由于严重的实现错误引起的错误。

## Let it crash

在本节中，我将尝试深入了解 Erlang 应用程序的结构以及“Let it crash”的理念如何在现实生活中发挥作用。

实际上，Let it crash并不是为了用户或系统而崩溃。 这是 Erlang 极力避免的事情。 相反，它是在失败不可避免地发生时遏制失败，因为在生活中，事情有时确实会失败。 最差的情况发生了。 让我们看看 Erlang 是如何清理它的。

基本上，一个 Erlang 应用程序是一个进程树。

![002](/images/blog/0028_002.jpeg)

在树的底部叶子，我们有工作进程——那些做大部分工作的进程。 在他们之上，我们有主管，他们启动工人并检查他们。

监督者自己可以被监督； 我们可以在这里轻松地在树的顶部添加一个 Grand Supervisor。

![003](/images/blog/0028_003.jpeg)

如果进程崩溃，它会向其主管发送一条消息。 根据监管策略集，要么只重启进程，要么重启其主管下的所有进程。

如果在一段时间内重启连接的工作人员并没有解决问题给定的次数，主管将终止其所有子进程，然后终止自身。 此时，尝试处理问题的责任被向上推到下一个监督层。

![004](/images/blog/0028_004.jpeg)

只有当顶级主管失败时，它才会重新启动并且应用程序崩溃。

## Erlang vs. Elixir

Erlang 不是唯一在 BEAM 上运行的语言。 还有很多其他的。 主要的是Elixir。

Elixir是什么?

![005](/images/blog/0028_005.jpeg)

Elixir 由 José Valim 在 2010 年代初创建。 他采用 Erlang 并在其上增加了一个薄层，该层具有更现代的语法，类似于 Ruby。

由此产生的语言是对 Erlang 和 Ruby 的改进。 在 2015-2016 年，它的主要 Web 框架 Phoenix 发布时，它的受欢迎程度大幅上升。

您可以在我们对 Elixir 的介绍中了解更多关于 Elixir 和 Phoenix 的信息。

### Elixir 相对于 Erlang 的优势

Elixir 实际上并没有为 Erlang 添加很多新功能。你可以在 Elixir 中做的所有事情，你也可以在 Erlang 中做，并且可以相互调用两种语言。 Elixir 的大部分优势源于它具有更现代的、类似 Ruby 的语法这一事实，这导致它比 Erlang 更受欢迎。

下面是 Elixir 相对于 Erlang 的优势：

- **现代语法**。如果您已经用几乎任何其他流行的编程语言进行了编程，Elixir 的语法就会更容易理解。它删除了一些样板代码，可以提高开发人员的生产力。
- **较高的知名度**。 Elixir 在很长一段时间内一直是两者中更受欢迎的一种，因此有关 Elixir 的内容更加最新，而且还有更多内容。
- **构架**。如果您从事 Web 开发，Phoenix 是目前最好的框架之一，如果您想做 Web 开发和函数式编程，它绝对是最方便的。谈到框架，Elixir 也有 Nerves——一个很棒的嵌入式软件框架。如果这是你想走的路线，Elixir 是更好的选择。

## Erlang值得学习吗？

那么，为什么要学习这种语言呢？原因有以下三个：

- 您正在关注使用 Erlang 的特定领域的职位。例如您喜欢聊天应用程序，并且想在 WhatsApp 工作。这是合理的。
- 您想编写非常小的、可移植的程序，并且依赖尽可能少。 Erlang 实际上使您能够开箱即用地做很多事情。
- 你是一个真正好奇的人，想要发现新的编程方式，而不会对底线产生直接的好处。在这种情况下，我欢迎你加入 BEAM 的行列。

如果最后一个是真的，我实际上会为你指明通往 Elixir 的道路。虽然这两种语言都很好用，但 Elixir 似乎是最近更流行的一种。它会给你更多的工作机会，也会更容易学习。

之后，您可以学习 Erlang 以及它的成功之处。了解 Erlang 在 Elixir 下的功能将帮助您编写更好的 Elixir 代码，并使您更有可能被聘为 Elixir 开发人员。

无论如何，我认为你不会后悔学习 BEAM 的任何部分，即使它不全是阳光和彩虹（BEAM 语言有时会变得很奇怪）。如果您想知道从哪里开始，我会推荐Learn You Some Erlang for Great Good！或我们的 Elixir 初学者指南。

2021 年你需要知道的关于 Erlang 的一切

我回来了！ 让我们用一些有趣的 Erlang/OTP 知识来庆祝吧！

到目前为止，我一直在分享大量奇怪的或者令人困惑的关于 erlangers 信息。 我可能会在下周回到过去那个模式。 但是，在我收集所有这些故事的同一时期，我还发现了 Erlang/OTP 发行版附带的一些不错的代码和文档。 他们在很大程度上展示了语言是如何创建的以及它是如何演变的。 这是带着快乐的编程！ 这当然是我最喜欢的编码方式。

## 我们中间的外星人

首先，让我向您展示一个可以在 Erlang/OTP 中找到的非常好的实用程序：erlang tracer。 是的，当时 erlang_tracer 是一个很长的名字（见下文），所以它的作者称它为 et（外星人）。 当然，有了这样的模块，谁能错过创建这个功能的机会呢？

<Code language="erlang">
{`1> et:phone_home(1, from, to, msg, opts).
hopefully_traced
2>`}
</Code>

实际上，我不久前使用它编写了一个模块，并在推特上发布了它……

## 有趣的硬编码函数名

为函数选择合适的名称并不总是那么容易，因此有时您必须记录该名称背后的原因。 正如 Robert Virding 对 lists:zf/1 所做的那样：

<Code language="erlang">
{`%%
%% The name zf is a joke!
%%`}
</Code>

去年我有机会见到他，问他这是什么玩笑，他告诉我这是关于 Zermelo 和 Fraenkel的玩笑。 让我们看看这些先生们对这个笑话有什么看法……

## 此处禁止 Objective-C 开发者

如果您还记得我之前的一篇文章，那么您在 Erlang 中有多种列表类型。 在那篇文章中，我只列出了正确的列表（即代表有效列表的列表）。 Erlang 也允许您使用不正确的列表，但开发人员找到了一种防止开发人员这样做的好方法。 根据该页面中的注释：

> 以下内置列表类型也存在，但预计很少使用。 因此，它们的名称很长：

<Code language="erlang">
{`nonempty_maybe_improper_list() :: 
 nonempty_maybe_improper_list(any(), any())
nonempty_improper_list(Type1, Type2)
nonempty_maybe_improper_list(Type1, Type2)`}
</Code>

朋友们，这是实事！ 谁有时间使用这么长的类型名称，对吧？

## 神秘的关键词

经典的是，在 Erlang 中，关键字和原子都写成小写单词（嗯……原子也可以写在单引号内，但让我们暂时忘记这一点）。 大多数时候，这不是问题：你知道 if 是关键字，case 是关键字，my_function 不是，等等。

但是有一些保留字实际上不是关键字（在某种意义上你不能用它们构建表达式），但它们也不是原子。 它们只是为未来保留的。 不久前（在 OTP17 之前）放弃的是query。 从那时起，您终于可以编写一个名为 query 的函数，但仍然保留了另外 2 个神奇的关键字。 让我们看看您是否可以通过[保留字列表](http://erlang.org/doc/reference_manual/introduction.html#id69700)与[有效表达式列表](http://erlang.org/doc/reference_manual/expressions.html#id80678)进行比较来发现它们；）

希望你喜欢本文。 下周见，将会为你带来更多文章！

Erlang 复活节彩蛋

在FutureLearn MOOC 关于 [Erlang的课程](https://www.futurelearn.com/courses/functional-programming-erlang/)中担任导师时，我提出了一个人们喜欢的想法。事实上，这是我在教授 Erlang 时向人们介绍模式匹配的方式。这是一种编写测试的方法，让您可以自然地从中提取代码……听起来很熟悉？是的！这是**测试驱动开发（TDD)**！

## 过程

我在学习 Smalltalk 时学习了 TDD。这是一堂改变人生的课！Smalltalk 是学习它的最佳环境，因为TDD是为它而构建的。在 Smalltalk 中，我相信用不同的进程编写代码实际上更难。如果你还没有尝试过，你绝对应该尝试一下！跟随[埃尔南威尔金森](https://medium.com/u/8eea71cbc92?source=post_page-----5c0cca886acb--------------------------------)，他的公司 (10pines) 提供 Smalltalk 课程，您可以在其中向专家学习，以及其他一些很棒的东西。

无论如何，对于外行来说，TDD 的一般流程是……

![001](/images/blog/0026_001.png)

图中没有描述（特别是对于编译语言，如 Erlang），添加测试后，为了看到测试失败，您首先需要代码进行编译。乍一看，这似乎很困难。但这实际上是可能的，可以使用 Erlang 的一个很好的热代码加载功能。

让我们举个例子……

### 我们有额外的一天吗？

因此，假设您必须编写一个名为year的模块，其中具有单一的函数：is_leap/1。 正如您可能猜到的那样，这个想法是让该函数接收一个整数并返回一个布尔值，告诉您它是否是闰年。

#### 添加测试

第一步，我们已经使用了我上面提到的技巧。看看我们要写的模块……

<Code language="erlang">
{`-module year.
-export [test/0].
test() ->
 false = year:is_leap(1),
 ok.`}
</Code>

让我们剖析一下这件事……

前两行应该很明显。我们定义了 module 和 export test/0，这是我们将用来运行测试的函数。

然后我们编写test/0函数。该函数将像大多数测试函数一样包含一系列断言，指定我们函数的预期结果is_leap/1。

第一个断言说当入参为1时不是闰年。但请注意，即使我们最终要is_leap/1在同一个模块中定义，我们也使用它的完全限定版本 ( year:is_leap(…)) 而不是仅仅编写is_leap(1). 为什么？当然是因为代码热加载！

如果 Erlang 编译器发现对未定义的内部函数的调用，将会失败，它不会编译你的模块，因此它不会运行测试。除非……如果您使用完全合格的调用。因为由于[热代码加载背后的逻辑](https://erlang.org/doc/reference_manual/code_loading.html#code-replacement)，您可以在模块的更高版本中完全定义该功能。

这对我们非常有用，因为现在我们可以……

#### 见证测试失败

<Code language="erlang">
{`1> c(year).
{ok, year}
2> year:test().
** exception error: undefined function year:is_leap/1
 in function year:test/0 (year.erl, line 5)`}
</Code>

#### 编写代码

好吧，现在我们的测试告诉我们需要定义is_leap/1……所以我们照做了！

<Code language="erlang">
{`-module year.
-export [test/0].
-export [is_leap/1].
test() ->
 false = year:is_leap(1),
 ok.
is_leap(_) -> false.`}
</Code>

#### 运行测试

我们尝试以更简洁的方式编译和运行我们的测试，这样我们每次进入控制台时都可以使用向上箭头……哦，懒惰的开发者！

<Code language="erlang">
{`3> c(year), year:test().
ok.`}
</Code>

#### 清除然后重复

嗯……这很好！现在让我们在测试中添加更多断言……

<Code language="erlang">
{`-module year.
-export [test/0].
-export [is_leap/1].
test() ->
 % regular years are not leap
 false = year:is_leap(1),
 false = year:is_leap(1995),
 false = year:is_leap(1997),
 % multiples of 4 are leap…
 true = year:is_leap(1996),
 true = year:is_leap(2004),
 true = year:is_leap(2008),
 % …except if they're multiples of 100…
 false = year:is_leap(1800),
 false = year:is_leap(1900),
 false = year:is_leap(2100),
 % …except if they're also multiples of 400…
 true = year:is_leap(1600),
 true = year:is_leap(2000),
 true = year:is_leap(2400),
 ok.
is_leap(_) -> false.`}
</Code>

……然后运行……

<Code language="erlang">
{`5> c(year), year:test().
** exception error: no match of right hand side value false
 in function year:test/0 (year.erl, line 11)`}
</Code>

第 11 行是1996（如预期的那样）……我们现在针对这种情况修复我们的代码，再次运行测试……许多迭代经过……以此类推……

为简洁起见，我将跳到最终版本……

<Code language="erlang">
{`-module year.
-export [test/0].
-export [is_leap/1].
test() ->
 % regular years are not leap
 false = year:is_leap(1),
 false = year:is_leap(1995),
 false = year:is_leap(1997),
 % multiples of 4 are leap…
 true = year:is_leap(1996),
 true = year:is_leap(2004),
 true = year:is_leap(2008),
 % …except if they're multiples of 100…
 false = year:is_leap(1800),
 false = year:is_leap(1900),
 false = year:is_leap(2100),
 % …except if they're also multiples of 400…
 true = year:is_leap(1600),
 true = year:is_leap(2000),
 true = year:is_leap(2400),
 ok.
is_leap(Year) ->
 is_leap(Year rem 4, Year rem 100, Year rem 400).
is_leap(_, _, 0) -> true;
is_leap(_, 0, _) -> false;
is_leap(0, _, _) -> true;
is_leap(_, _, _) -> false.`}
</Code>

然后再次运行…

<Code language="erlang">
{`7> c(year), year:test().
ok`}
</Code>

## 更复杂的东西

当然，这种技术只适用于不应该投入生产的非常小的代码片段。您不希望测试代码弄乱您的发布！

但是如果你选择[Common Test](https://erlang.org/doc/man/common_test.html)作为你的测试框架，这个模块的套件看起来会非常熟悉……

<Code language="erlang">
{`-module year_SUITE.
-export [all/0].
-export [is_leap/1].
all() -> [is_leap].
is_leap(_) ->
 % regular years are not leap
 false = year:is_leap(1),
 false = year:is_leap(1995),
 false = year:is_leap(1997),
 % multiples of 4 are leap…
 true = year:is_leap(1996),
 true = year:is_leap(2004),
 true = year:is_leap(2008),
 % …except if they're multiples of 100…
 false = year:is_leap(1800),
 false = year:is_leap(1900),
 false = year:is_leap(2100),
 % …except if they're also multiples of 400…
 true = year:is_leap(1600),
 true = year:is_leap(2000),
 true = year:is_leap(2400),
 {comment, ""}.`}
</Code>

你怎么看？我说服你为 Erlang 使用测试驱动开发了吗？😉

在Erlang 中初步应用TDD

Erlang 是一种受信任且稳定的语言，用于在主要系统中运行核心程序，由 Ericsson 发明。Erlang（和 Elixir）被许多领域的许多行业使用，包括金融科技、安全、区块链和物联网。

公司之所以选择 Erlang 和 Elixir，是因为可以轻松编写可部署在分布式网络中的容错和可扩展程序。Erlang 和 Elixir 都是函数式语言，它们可以使用 Actor 系统来简化并发处理并使错误恢复成为可能。他们能够充分利用多核计算，从而事半功倍。我们现在也看到 Elixir 在生产中得到更广泛的采用，特别是对于那些更习惯于 Ruby 语法的公司。

以下是在其核心业务系统的日常运行中使用 Erlang 和/或 Elixir 的 10 家公司的列表。这只是一个快照，许多公司（250 多家）现在在他们的技术堆栈中使用 Erlang 和/或 Elixir。

## WhatsApp

仅 32 名工程师如何支持 4.5 亿用户？对于 WhatsApp，答案是 Erlang。

来自 WhatsApp 的 Anton Lavrik 将在 Code BEAM SF 2018 上谈论他们是如何做到这一点的。在[这里](https://codesync.global/speaker/anton-lavrik/)查看他的谈话详情。

## Pinterest

Elixir 在 Pinterest 用于管理 Ads API 速率限制的系统。它的响应时间约为 500 到 800 微秒。将他们的通知系统从 Java 迁移到 Elixir，意味着 Elixir 中的 10,000 行代码被缩减为仅 1000 行。他们的 Elixir 系统现在运行速度更快、更加一致，并且只需要一半的服务器。

在 Code BEAM SF 2018 上加入 Pinterest 开发人员和 Elixir 核心团队成员 James Fish，他将在那里发布 [Elixir 核心团队更新](https://codesync.global/speaker/james-fish/)。

## AdRoll

AdRoll 在其实时竞价系统的实时监控中使用 Erlang。这涉及实时监控在每秒接收 500K+ 投标请求的系统上可能出现的所有问题，并附带大量货币价值。在[此处](https://www.youtube.com/watch?v=qURhXHbxbDU&list=PLWbHc_FXPo2hAfi8bz65wpBrCjeKtncB-&index=43)了解更多信息。

来自 AdRoll 的 Miriam Pena 和 Mike Watters 将在 Code BEAM SF 2017 上发表演讲。Miriam 将发表主题演讲，BEAM 的无名英雄，在[此处](https://codesync.global/speaker/miriam-pena/)查看她的演讲详情。迈克将进行演讲，请在[此处](https://codesync.global/speaker/mike-watters/)查看他的演讲详情。

## Bet365

Bet365，使用 Erlang 和 Elixir 帮助其服务超过 2000 万用户，并满足高峰时段 10 万并发用户的需求。之所以选择 Erlang，是因为它在分布、并发性和弹性方面的优势。使用 Erlang，开发团队能够快速构建一个高度可扩展的平台，可以快速添加新功能。

## IBM Cloudant

Erlang 与 Scala 一起用于为 Cloudant 的全文搜索系统提供支持。该系统由两个互补项目 Clouseau 和 Dreyfus 提供支持。Dreyfus 是用 Erlang 编写的，处理插入现有的 CouchDB/Cloudant 集群技术。它管理 Clouseau 节点以提供全文搜索功能。Clouseau 和 Dreyfus 使用 Erlang 的外部术语格式进行通信（使用 Clouseau 端的 Scalang 库）。

## Goldman Sachs

高盛正在其 HF 交易平台中使用 Erlang。Goldman Sachs 平台是一个非常低延迟（微秒）的事件驱动市场数据处理、策略和订单提交引擎。它运行具有低延迟要求的交易算法，可以响应市场条件的变化。Erlang 被用作这个分布式交易系统的实时监控解决方案的一部分。

## Moz

领先的 SEO 分析公司 Moz Pro 放弃了 MySQL 数据库存储，采用由 Elixir 驱动的数据索引模型提供支持的无数据库架构。结果是，他们的新 API 为核心排名数据集提供服务的速度比以前的 API 快 20 倍，平均响应时间始终低于 50 毫秒，而之前为 800 多毫秒。

## Lonely Planet

这家著名的旅游公司需要每月为数百万的独立访客提供服务，将请求推送到 booking.com 和 HostelWorld 等网站。他们采用的部分解决方案涉及使用 Phoenix Web 框架的带有 API 子服务的 Elixir 微服务器。

## Grindr

Erlang 被用作 Grindr 系统的一部分，用于为每天超过 320 万活跃用户维护一个可靠、性能最佳且可扩展的系统栈。

## USwitch

USwitch 从 Elixir 开始，在 Elixir 中重写了他们的一个小型微服务。由于优秀的文档、有用的错误消息和非常有用的 Elixir 社区，转变很容易。


使用 Erlang 和 Elixir的成功公司

Erlang通常被称为“面向并发的编程语言”。

这个名字是怎么来的？80 年代为电信行业创建的语言现在如何帮助我们？

Erlang 或Erlang/OTP（开放电信平台）于 1986 年在爱立信构建，用于处理不断增长的电话用户群。它的设计目的是改进电话应用程序的开发。它非常适合构建分布式、容错和高可用性系统。

那么，80 年代建立的技术对我们有什么意义呢？事实证明，构建 Erlang 的所有原因对于当今的 Web 服务器都非常有用。我们需要快速可靠的应用程序——我们现在就需要它！幸运的是，Phoenix 可以做到这一点，它是建立在 Elixir（一种建立在 Erlang 之上的现代语言）之上的 Web 框架。它具有强大的功能，例如热代码交换和[实时视图](https://github.com/phoenixframework/phoenix_live_view)– 无需 JS！

这怎么可能？这主要是由于该语言是如何构建为自下而上并发的 – 这要归功于 Erlang VM BEAM。

在我们继续之前，让我们回顾一下 CS 101 中的一些概念 – 操作系统！

## 并发

为了理解为什么 Erlang VM 中的并发性如此特殊，我们需要了解操作系统如何处理指令/程序。CPU负责机器的工作。它的唯一责任是执行流程。现在一个进程是一个孤立的执行块。它们有自己的内存、上下文和文件描述符。然后，一个进程由许多线程或过度使用的定义“轻量级进程”组成。

![001](/images/blog/0024_001.png)

CPU 负责以最有效的格式执行这些进程。它可以一个接一个地执行进程。这被称为“顺序执行”。这是最基本和最古老的执行方法。今天对我们来说也没什么用——即使是我们今天使用的冰箱也可以做得更多！

![002](/images/blog/0024_002.jpeg)

您可能会认为，由于现代计算机允许您一次做不止一件事，CPU 正在并行执行进程。像这样的东西，

![003](/images/blog/0024_003.jpeg)

然而，这远非事实。我们离真正的并行性还很远。当我们尝试走这条路时，会出现大量的错误。

下一个最好的事情是并发。并发执行意味着将进程分解为多个微小位并在执行时在它们之间切换。这种情况发生得如此之快，以至于它给用户一种同时执行多个进程的错觉——同时巧妙地规避了并行性问题。

它看起来像这样，

![004](/images/blog/0024_004.jpeg)

您可以看到 CPU 在进程 1 和 2 之间切换。这称为上下文切换。这是一项相当繁重的任务，因为 CPU 需要在切换之前将进程的所有信息和状态存储到内存中，然后在需要再次执行时将其加载回来。然而，我们已经在这个问题上工作了这么多年，我们已经非常擅长它了。

*最后一件事 …*

程序执行的速度取决于 CPU 时钟周期。处理器越快，您的计算机就越快。摩尔定律指出，负担得起的 CPU 上的晶体管数量每两年就会翻一番。但是，如果您注意到，处理器在过去几年中并没有变得那么快。那是因为我们在路上遇到了困难。当我们意识到远高于 4GHz 非常困难且徒劳无功时，就会发生这种情况。光速居然成了约束！这是我们决定改为进行多核处理的时候。我们水平缩放，而不是垂直缩放。我们添加了更多核心，而不是让单个核心变得强大。好的，我知道我们在这里介绍了很多材料。但是你要记住的是上下文切换很繁重，我们现在已经转向多核处理。让我们看看 Erlang 有什么技巧使它成为**面向并发的语言**。

## 并发模型

在上一节中，我们推断并发是实现多处理的最佳方式。多年来，各种语言引入了不同的算法来实现并发。让我们看一下与我们讨论的主题相关的三个最重要的问题。

### 共享内存模型

这是 Java 和 C# 等流行编程语言中常用的模型。它涉及访问同一块内存的不同进程以进行存储和相互通信。它允许上下文切换不那么繁重。虽然这在理论上听起来不错，但当两个或多个进程尝试访问同一个共享内存块时，它会导致一些不友好的情况。它会导致死锁等情况。为了克服这个问题，我们有互斥锁、锁和同步。然而，这使得系统更加复杂并且难以扩展。

![005](/images/blog/0024_005.png)

### Actor模型

这是 Erlang 和 Rust 用来实现并发的模型。它取决于尽可能隔离进程并将它们之间的通信减少为消息传递。每个过程都称为一个参与者。参与者通过发送消息相互通信。消息可以随时发送并且是非阻塞的。然后将这些消息存储在接收参与者的邮箱中。为了读取消息，参与者必须执行阻塞读取操作。

![006](/images/blog/0024_006.png)

### CSP模型

这是 Go 使用的高效并发模型。它与参与者模型相似，因为它使用消息传递。然而，与仅接收消息被阻塞的参与者模型不同，CSP 要求两个动作都被阻塞。在 CSP 中，称为通道的单独存储用于传输传入和传出消息。进程之间不直接通信，而是通过通道层进行通信。

![007](/images/blog/0024_007.png)

### 深入了解Actor模型

让我们更深入地了解 Actor 模型。

actor是并发的一种原始形式。每个actor都有一个身份，其他actor可以使用它来发送和接收消息。收到消息后，它们将存储在actor邮箱中。actor必须明确尝试读取邮箱的内容。每个actor都与其他actor完全隔离，彼此之间不共享任何内存。这完全消除了对复杂同步机制或锁的需求。

一个actor在收到消息时可以做三件事，

1. 创建更多actor
2. 向其他actor发送消息
3. 指定如何处理下一条消息

前两个非常简单。让我们看一下它在代码级别上的表示。

![008](/images/blog/0024_008.png)

您可以在这里看到在 Elixir 中产生一个新进程 – 就是这样。与其他使用多线程方法处理并发的语言不同，Elixir 使用进程。

要记住的关键是，这些是 Erlang 进程，它们比它们的操作系统对应物轻得多。平均而言，Erlang 进程的轻量级是 OS 进程的[2000分之一](http://blog.plataformatec.com.br/2018/04/elixir-processes-and-this-thing-called-otp/)。一个系统中可能有数十万个 Erlang 进程，一切都会好起来的。

Erlang 线程也有一个附加到它们的 PID。使用此 PID，您可以提取有关它占用的内存、它正在运行的功能等等的信息。使用 PID，您还可以向进程发送消息并进行通信。

下面我们来看看一个actor的最终职责——指定。

![009](/images/blog/0024_009.png)

您可以在这里看到每个进程也有自己的内部状态。每次我们向进程发送消息时，它不会以默认值重新启动函数，而是能够保留正在运行的进程的状态信息。本质上，每个actor都能够访问它自己的内存集，并对其进行跟踪。

这三个属性允许 Erlang 进程非常轻量级。它消除了对复杂同步技术的需求，并且不会为进程间通信占用太多内存空间。所有这些都有助于实现高可用性。

BEAM VM 被构建为能够将Erlang/Elixir 文件编译成字节码 (.beam) 文件以及在 CPU 上调度 Erlang 进程。这种级别的控制为高效和并发运行的进程提供了巨大的优势。

当 VM 启动时，第一步是启动调度程序。它负责在 CPU 上同时运行每个 Erlang 进程。由于所有进程都由 BEAM 维护和调度，因此我们可以更好地控制进程失败时发生的情况（容错），并且能够更有效地使用内存并执行更好的上下文切换。

BEAM 还充分利用了硬件。它为每个可用的核心启动一个调度程序，允许进程自由高效地运行，同时仍然能够相互通信。

![010](/images/blog/0024_010.png)

## 其他特征

保持冷静，我们快结束了！

Erlang 并发很大程度上归功于 Actor 模型和 BEAM。但是，还有许多其他结构也可以确保稳定性。我将为您提供一些小提示，您可以参考它们以供进一步阅读。

### 监督树

有一个特殊的 Erlang 进程称为 Supervisor。它的目标是弄清楚当流程失败时该怎么做。它有助于将其重置为初始值，以便可以再次将其发送以进行处理。

### 容错性

Erlang 的创建者Joe Armstrong，曾说过这句著名的台词“Let it crash”。他设计容错语言的目的不是为了防止错误发生，而是为了构建处理错误场景的结构。

### 分布式

Erlang 使得构建分布式系统变得非常容易。每个 Erlang 实例都可以充当不同设备中的一个节点，并且可以像生成进程一样轻松地进行通信。

### 没有GIL

与其他解释性语言（最著名的是 Ruby 和 Python）不同，Erlang 不必担心全局解释器锁。GIL 确保 CPU 上每个进程只运行一个 Ruby/Python 线程。这对并发性是一个巨大的打击。像Passenger这样的应用服务器试图通过创建多个操作系统处理器并在多个内核上运行来克服这个问题。然而，正如我们之前看到的，操作系统线程的管理成本很高。

## 结论

Erlang 是一种结构精美且贯穿始终的语言。它确实经受住了时间的考验，并且在最近变得更加重要。



Erlang VM 中的并发性

Erlang 是一个先进的分布式软件平台，非常适合网络和多核计算。我相信它几乎已经为 Web 编程的“黄金时间”做好了准备，但至少有一个大问题阻碍了 Erlang 平台：Erlang语言不适合 Web 程序员面临的许多问题。例如：

- Erlang 很难重构
- 哈希映射没有内置语法
- 字符串操作很难

我将讨论一种规避这些问题的方法，即实现另一种语言以在 Erlang 平台上运行。如果您有野心，您可能会实现一种功能齐全的编程语言，但在这里我将讨论为简单的模板语言编写编译器。

## 了解你的目标

Erlang 平台是一个虚拟机。Erlang 代码被编译成称为 BEAM 的二进制代码（字节代码），但它在此过程中采用了一些中间形式。作为编译器编写者，您首先需要选择您的目标平台，它可以是以下之一：

- Erlang – 最高级别，程序员写什么
- Core Erlang – 较低级别，但程序员可读
- 中间代码– 甚至更低级别，您或我都无法阅读
- BEAM – 字节码

要针对 #2、3 或 4，您需要了解有关 Erlang 内部结构的更多信息。我对 Erlang 的内部了解不多，所以我将针对 #1，即 Erlang 语言。也就是说，我的编译器只是将模板文件转换为 Erlang 代码，然后调用标准的 Erlang 编译器。所以实际上，我们在作弊，但最终我们仍在生产编译模块，没有人知道我们作弊了。

## 编译器#0：语言

首先你需要选择一种语言来编译。如果有语言规范，它会有所帮助。我正在实现 Django 模板语言。没有真正的规范，但 Python 中有一个官方实现，所以每当我不确定某些事情时，我可以查阅它。

本教程的其余部分以我和 Roberto Saccon 的[ErlyDTL](https://github.com/erlydtl/erlydtl)项目为例。

## 编译器#1：扫描器

实现语言的第一步是编写一个扫描器。扫描器读入一个文件并决定什么是令牌。标记可以是字符串、括号、标识符、语言关键字或类似的东西。扫描器只返回一个标记的平面列表，其中包含有关每个标记所在行的一些信息。使用 Erlang，您可以使用名为 Leex 的程序来帮助您编写扫描器，或者您可以使用普通的 Erlang 编写扫描器。当我写扫描器的时候我不知道Leex，所以我们只是用老式的方式来做。

这是 ErlyDTL 的扫描器模块 ( [erlydtl_scanner.erl](https://github.com/erlydtl/erlydtl/blob/master/src/erlydtl_scanner.erl) ) 中的重要内容。首先是无聊的东西：

<Code language="erlang">
{`-module(erlydtl_scanner).
-export([scan/1]).`}
</Code>

scan/1将接收代表我们正在编译的源代码的列表。

<Code language="erlang">
{`scan(Template) ->
 scan(Template, [], {1, 1}, in_text).`}
</Code>

如您所见，它只是调用scan/4，其参数是：

1. 剩余待扫描字符列表
2. 到目前为止我们已扫描的令牌列表
3. 当前位置\{行，列\}
4. 当前状态

状态只是我们传递的一个原子，它告诉我们是否处于扫描过程中，例如我们是否在等待一个字符串关闭。这就像您的计算理论课程中的有限状态机中的状态。实际上，我们的扫描器将是一台有限状态机。每个函数子句都将定义一个转换规则。这是一个这样的规则：

<Code language="erlang">
{`scan("{{" ++ T, Scanned, {Row, Column}, in_text) ->
 scan(T, [{open_var, {Row, Column}, "{{"} | Scanned], {Row, Column+2}, {in_code, "}}"});`}
</Code>

这意味着“如果我们处于 in_text 状态并看到\{\{，那么：

1. 推入\{\{令牌列表
2. 将列位置增加两个字符
3. 让我们进入状态 in_code 等着看\}\}
4. 扫描输入的其余部分”

很酷，我们如何在两行 Erlang 中完成所有四件事。因为它是 Erlang 是非常好的扫描语言。以下是处理 和 之间的代码注释的一些扫描\{#规则#\}：

<Code language="erlang">
{`scan("{#" ++ T, Scanned, {Row, Column}, in_text) ->
 scan(T, Scanned, {Row, Column + 2}, {in_comment, "#}"});

scan([_ | T], Scanned, {Row, Column}, {in_comment, Closer}) ->
scan(T, Scanned, {Row, Column + 1}, {in_comment, Closer});

scan("#}" ++ T, Scanned, {Row, Column}, {in_comment, "#}"}) ->
scan(T, Scanned, {Row, Column + 2}, in_text);`}
</Code>

这里还有一些仅用于处理模板文件的非代码部分的扫描规则。

<Code language="erlang">
{`scan("\n" ++ T, Scanned, {Row, Column}, in_text) ->
 scan(T, append_text_char(Scanned, {Row, Column}, $\n), {Row + 1, 1}, in_text);

scan([H | T], Scanned, {Row, Column}, in_text) ->
scan(T, append_text_char(Scanned, {Row, Column}, H), {Row, Column + 1}, in_text);`}
</Code>

他们只是增加行和列的位置。注意使用append_text_char. 当前字符应该附加到前一个标记上，因此我们定义了一个函数来为我们跳过：

<Code language="erlang">
{`append_text_char(Scanned, {Row, Column}, Char) ->
 case length(Scanned) of
 0 ->
 [{text, {Row, Column}, [Char]}];
 _ ->
 [Token | Scanned1] = Scanned,
 case element(1, Token) of
 text ->
 [{text, element(2, Token), [Char | element(3, Token)]} | Scanned1];
 _ ->
 [{text, element(2, Token), [Char]} | Scanned]
 end
 end.`}
</Code>

以下规则处理在 Django 模板语言中具有特殊含义的字符：

<Code language="erlang">
{`scan("," ++ T, Scanned, {Row, Column}, {_, Closer}) ->
 scan(T, [{comma, {Row, Column}, ","} | Scanned], {Row, Column + 1}, {in_code, Closer});

scan("|" ++ T, Scanned, {Row, Column}, {_, Closer}) ->
scan(T, [{pipe, {Row, Column}, "|"} | Scanned], {Row, Column + 1}, {in_code, Closer});

scan("=" ++ T, Scanned, {Row, Column}, {_, Closer}) ->
scan(T, [{equal, {Row, Column}, "="} | Scanned], {Row, Column + 1}, {in_code, Closer});

scan(":" ++ T, Scanned, {Row, Column}, {_, Closer}) ->
scan(T, [{colon, {Row, Column}, ":"} | Scanned], {Row, Column + 1}, {in_code, Closer});

scan("." ++ T, Scanned, {Row, Column}, {_, Closer}) ->
scan(T, [{dot, {Row, Column}, "."} | Scanned], {Row, Column + 1}, {in_code, Closer});
`}
</Code>

有点冗长，但无论如何。这应该为您提供规则的主要思想。最后，当我们到达输入的末尾时，我们需要反转我们的标记列表并标记我们遇到的任何语言关键字。

<Code language="erlang">
{`scan([], Scanned, _, in_text) ->
 {ok, lists:reverse(lists:map(
 fun
 ({identifier, Pos, String}) ->
 RevString = lists:reverse(String),
 Keywords = [ "if", "else", "endif", "not" ], %many others too
 Type = case lists:member(RevString, Keywords) of
 true ->
 list_to_atom(RevString ++ "_keyword");
 _ ->
 identifier
 end,
 {Type, Pos, RevString};
 ({Type, Pos, String}) ->
 {Type, Pos, lists:reverse(String)}
 end, Scanned))};`}
</Code>

我们完成了。扫描器返回\{ok, Tokens\}。是时候将这些令牌发送到解析器了。

## 编译器 #2：解析器

解析器获取令牌列表并将它们排列成称为解析树的树结构。你可能在你的第一个 CS 课上做了类似的事情，你取“1+1”并制作一棵树，其中“+”作为父级，“1”和“1”作为子级。这里的想法相同。

我们以名为Yecc的解析器生成器的形式提供了一些帮助。Yecc 与 yacc 类似，但适用于 Erlang。我们将告诉它相邻的令牌是如何相互关联的，剩下的交给 Yecc。

我们的 Yecc 文件如下所示。它包含三个部分：非终结符列表、终结符列表和规则列表。非终端是您可以扩展为终端和非终端列表的东西。终端无法扩展。使用规则，我们将所有非终端扩展为终端。

这是我们的 Django 模板语言 Yecc 文件 ( [erlydtl_parser.yrl](https://github.com/erlydtl/erlydtl/blob/master/src/erlydtl_parser.yrl) ) 的子集，足以处理“if”语句。

<Code language="erlang">
{`Nonterminals
 Elements
 Literal
 Value
 Variable
 IfBlock
 IfBraced
 IfExpression
 ElseBraced
 EndIfBraced.

Terminals
close_tag
endif_keyword
if_keyword
else_keyword
dot
open_tag
not_keyword
text.

Rootsymbol
Elements.`}
</Code>

这是规则。格式为 \[要扩展的东西\] -> \[扩展的组件\] : \[将组件重新组合成列表或树的 Erlang 表达式\]。在最高级别，我们只是将事物放入一个列表中：

<Code language="erlang">
{`Elements -> '$empty' : [].
Elements -> Elements text : '$1' ++ ['$2'].
Elements -> Elements IfBlock : '$1' ++ ['$2'].`}
</Code>

嗯，这很有趣。一个IfBlock呢？

<Code language="erlang">
{`IfBlock -> IfBraced Elements ElseBraced Elements EndIfBraced : {ifelse, '$1', '$2', '$4'}.
IfBlock -> IfBraced Elements EndIfBraced : {'if', '$1', '$2'}.`}
</Code>

使用元组，我们构建了一棵树。所有这些非终端扩展到什么？

<Code language="erlang">
{`IfBraced -> open_tag if_keyword IfExpression close_tag : '$3'.
IfExpression -> not_keyword IfExpression : {'not', '$2'}.
IfExpression -> Value : '$1'.`}
</Code>

最后得到一些终端。for 的规则Value有点复杂，这里就不赘述了。

正如您在下面看到的，冒号后面的部分是严格可选的。在这种情况下，解析树中不会添加任何内容。

<Code language="erlang">
{`ElseBraced -> open_tag else_keyword close_tag.
EndIfBraced -> open_tag endif_keyword close_tag.`}
</Code>

我们确实需要将 Yecc 文件编译成 Erlang 代码。Yecc 是内置在 erlc 中的，所以你可以运行erlc -o src/ src/myfile.yrl它，它应该会输出一个 erl 文件。

ErlyDTL 的 Yecc 文件总共有大约 200 行，与扫描器的长度大致相同。400 行代码，我们完成了 2/3 的编译器！好样的。

## 编译器 #3：编译器

现在我们有一个解析树。我们要做的就是把它变成 Erlang 代码。实际上，我们将借助 Erlang 模块将其转换为抽象语法树erl_syntax（AST） 。然后我们可以调用一个特殊的函数将 AST 编译成字节码。构建一个 AST 而不是 Erlang ASCII 代码使我们的代码感觉更干净，更容易调试，尽管有时它看起来很冗长。

erl_syntax有一个对应于 Erlang 中每个句法结构的方法。如果你想构建一个原子，你调用erl_syntax:atom/1. 如果要构建函数调用，请调用erl_syntax:application/3. 等等。查看erl_syntax手册页了解详细信息。

编译器代码可以在[erlydtl_beam_compiler.erl](https://github.com/erlydtl/erlydtl/blob/master/src/erlydtl_beam_compiler.erl)中找到。

编译器最难看的部分是为已编译模块的骨架制作 AST。我们需要一个 AST 用于-module定义、-export语句和每个编译模板将具有的“渲染”函数。在 ErlyDTL 中，这是在一个名为 erlydtl_beam_compiler:forms/5 ( [source](https://github.com/erlydtl/erlydtl/blob/master/src/erlydtl_beam_compiler.erl#L482) ) 的函数中完成的，这可能会让您头疼。您可以根据自己的时间阅读。它的关键部分是对 的调用erl_syntax:revert，它将 AST 转换为称为“表单”的表示，然后您将其直接发送到compile:forms/2.

ErlyDTL 编译器最漂亮的部分也是最精妙的部分。它是一个名为body_ast/3( [source](https://github.com/erlydtl/erlydtl/blob/master/src/erlydtl_beam_compiler.erl#L544) ) 的函数，它查看解析树上的每个节点并将其转换为适当的 Erlang AST 节点，然后递归地对每个节点的子节点执行相同的操作。当我们向下解析树时，我们需要传递一些上下文，特别是当前范围内的所有变量。我们可能会在向下解析树时拾取一些范围，并在我们返回时将它们丢弃。

让我们看一下body_ast的片段。它所做的只是获取解析树的顶层并决定如何处理每个父节点。这是处理“if”语句的部分。

<Code language="erlang">
{`body_ast(DjangoParseTree, Context) ->
 lists:map(
 fun
%...
 ({'if', Variable, Contents}) ->
 ifelse_ast(Variable, body_ast(Contents, Context), empty_ast(), Context);
 ({'if', {'not', Variable}, Contents}) ->
 ifelse_ast(Variable, empty_ast(), body_ast(Contents, Context), Context);
 ({'ifelse', Variable, IfContents, ElseContents}) ->
 ifelse_ast(Variable, body_ast(IfContents, Context), 
 body_ast(ElseContents, Context), Context);
%...
 end, DjangoParseTree).`}
</Code>

那个代码是不是就像五月的清风一样？好吧，也许不是，但这样的代码是生活中简单的乐趣之一。这是递归下降编译器的基本结构。该函数处理每个节点并将子节点传递回body_ast. 对于此处的“if”语句，它调用一个函数，该函数ifelse_ast构建一个 AST 以测试是否Variable评估为真并运行适当的代码块。如果没有“else”块，那么它会传入一个空的 AST，这样如果变量为假，就不会运行任何代码。这是ifelse_ast：

<Code language="erlang">
{`ifelse_ast(Variable, IfContentsAst, ElseContentsAst, Context) ->
 % first resolve the variable to the right scope
 {Ast, VarName} = resolve_ifvariable_ast(Variable, Context),
 % now write an if statement
 erl_syntax:case_expr(erl_syntax:application(
 erl_syntax:atom(erlydtl_runtime), erl_syntax:atom(is_false), [Ast]),
 [erl_syntax:clause([erl_syntax:atom(true)], none,
 [ElseContentsAst]),
 erl_syntax:clause([erl_syntax:underscore()], none,
 [IfContentsAst])
 ]).`}
</Code>

现在好了，你应该对 ErlyDTL 编译器有了基本的了解。编译器部分重约 750 行。我们用一些编译模块所依赖的运行时代码作弊，所以我们的全功能模板编译器大约有 2000 行代码。不过是你可以在一个下午就能完成编码的东西，也不是一项艰巨的任务。

## 结束语

Erlang 几乎可以肯定是未来的服务器平台，但它需要一些创造性的想法才能让 Web 编程更愉快。实现模板语言是一个开始，但为什么不为模型和控制器也提供新的语言呢？他们说 Rails 之所以成为可能，是因为 Ruby 强大的元编程特性。如果有一个与 Erlang 等效的 Rails，这将是可能的，因为为 Erlang 平台编写编译器很容易。

为 Erlang 编写模板编译器

消息传递一直是 Erlang 的核心，虽然有合理的文档记录，但我们避免了过多的细节，以便在实现时给我们更多的自由。不过，没有什么能阻止我们在博客文章中描述它，所以让我们仔细看看吧！

Erlang 进程通过相互发送信号来相互通信 （不要与 Unix 信号混淆）。有许多不同的类型， 消息只是最常见的。实际上，涉及多个进程的所有事情都在内部使用信号：例如，该link/1功能是通过让所涉及的进程来回交互直到它们就链接达成一致来实现的。

这可以帮助我们避免大量的锁定，并且可以自己写一篇有趣的博客文章，但现在我们只需要记住两件事：所有信号（包括消息）在后台持续接收和处理，并且它们有一个[明确的顺序](https://erlang.org/doc/apps/erts/communication.html#passing-of-signals)：

两个进程之间的信号保证按照它们发送的顺序到达。换句话说，如果进程A发送信号1然后再发送2给进程 B，则信号1保证在信号之前到达2。

为什么这很重要？考虑请求-响应习惯用法：

<Code language="erlang">
{`%% Send a monitor signal to \`Pid\`, requesting a \'DOWN\' message
%% when \`Pid\` dies.
Mref = monitor(process, Pid),
%% Send a message signal to \`Pid\` with our \`Request\`
Pid ! {self(), Mref, Request},
receive
 {Mref, Response} ->
 %% Send a demonitor signal to \`Pid\`, and remove the
 %% corresponding \'DOWN\' message that might have
 %% arrived in the meantime.
 erlang:demonitor(Mref, [flush]),
 {ok, Response};
 {'DOWN', Mref, _, _, Reason} ->
 {error, Reason}
end`}
</Code>

由于死进程无法发送消息，我们知道响应必须在任何最终'DOWN'消息之前出现，但是如果没有保证顺序， 'DOWN'消息可能会在响应之前到达，我们不知道是否有响应到来，这会使得处理很烦人。

有一个明确的顺序可以为我们省去很多麻烦，而且成本也不高，但保证就到此为止了。如果多个进程向一个公共进程发送信号，即使您“知道”其中一个信号首先发送，它们也可以按任何顺序到达。例如，这一系列事件是合法的并且完全有可能：

- A发送信号1到B
- A发送信号2到C
- C响应信号2，发送信号3到B
- B接收信号3
- B接收信号1

幸运的是，很少需要全局订单并且很容易强加给自己（分布式案例之外）：只需让所有相关方与一个通用流程同步即可。

## 发送消息

发送消息很简单：我们尝试找到与进程标识符相关联的进程，如果存在，我们将消息插入其信号队列。

消息总是在被插入队列之前被复制。尽管这听起来很浪费，但它大大减少了垃圾收集 (GC) 延迟，因为 GC 永远不必超越单个进程。过去曾尝试过非复制实现，但结果证明它们并不适合，因为对于 Erlang 旨在构建的那种软实时系统来说，低延迟比纯粹的吞吐量更重要。

默认情况下，消息被直接复制到接收进程的堆中，但是当这不可能（或不希望 – 请参阅[message_queue_data](https://erlang.org/doc/man/erlang.html#process_flag_message_queue_data)标志）时，我们将消息分配到堆之外。

内存分配使这种“堆外”消息稍微昂贵一些，但对于接收大量消息的进程来说，它们非常简洁。我们在复制消息时不需要与接收者交互——​​仅在将消息添加到队列时——并且由于进程可以看到消息的唯一方法是在receive表达式中匹配它们，因此 GC 不需要考虑未匹配的消息，这进一步减少了延迟。

向其他 Erlang 节点上的进程发送消息的工作方式相同，尽管现在存在消息在传输过程中丢失的风险。只要节点之间的分发链接处于活动状态，就可以保证传递消息，但是当链接断开时，它会变得很棘手。

在远程进程（或节点）上使用monitor/2会告诉你什么时候发生这种情况，就像进程死了一样（因为no connection原因），但这并不总是有帮助：在收到消息并在另一个上处理后链接可能已经死了，最后我们所知道的是，在我们得到任何最终响应之前，链接就断开了。

与其他一切一样，没有免费的午餐，您需要决定您的应用程序应该如何处理这些[场景](https://en.wikipedia.org/wiki/Network_partition)。

## 接收消息

有人可能会猜测进程通过receive表达式接收消息，但在这里receive有点用词不当。与所有其他信号一样，该进程在后台连续处理它们，将接收到的消息从 信号队列移动到消息队列。

receive在消息队列中搜索匹配的消息（按照它们到达的顺序），如果没有找到则等待新消息。搜索消息队列而不是信号队列意味着它不必担心发送消息的进程，这大大提高了性能。

这种“有选择地接收”特定消息的能力非常方便：我们并不总是处于可以决定如何处理消息的环境中，并且不得不手动拖拽所有未处理的消息当然很烦人。

不幸的是，将消息搜索扫到地毯下并不会让它消失：

<Code language="erlang">
{`receive
 {reply, Result} ->
 {ok, Result}
end`}
</Code>

如果队列中的下一条消息匹配，则上述表达式会立即完成\{reply, Result\}，但如果没有匹配的消息，则必须在放弃之前遍历所有消息。当有大量消息排队时这很昂贵，这对于类似服务器的进程很常见，并且由于 receive表达式几乎可以匹配任何东西，因此几乎无法优化搜索本身。

我们目前做的唯一优化是当我们知道在某个点之前不存在消息时标记搜索的起点。让我们重温一下请求-响应惯用语：

<Code language="erlang">
{`Mref = monitor(process, Pid),
Pid ! {self(), Mref, Request},
receive
 {Mref, Response} ->
 erlang:demonitor(Mref, [flush]),
 {ok, Response};
 {'DOWN', Mref, _, _, Reason} ->
 {error, Reason}
end`}
</Code>

由于创建的引用monitor/2是全局唯一的，并且在所述调用之前不存在，并且receive唯一匹配包含所述引用的消息，因此我们不需要查看在此之前收到的任何消息。

即使在消息队列长得离谱的进程上，这也使该习惯用法变得高效，但不幸的是，在一般情况下，我们无法做到这一点。虽然您作为程序员可以确保某个响应必须在其请求之后出现，即使没有参考，例如通过使用您自己的序列号，编译器无法读取您的意图并且必须假设您想要任何匹配的消息.

目前，弄清楚上述优化是否已经启动是相当烦人的。它需要检查 BEAM 组件，即使那样，由于一些烦人的限制，您也不能保证它会正常工作：

- 我们一次只支持一个消息位置：一个函数创建一个引用，调用另一个使用此优化的函数，然后返回receive第一个引用，最终将搜索整个消息队列。
- 它只适用于单个函数子句：引用创建和 receive需要彼此相邻，并且您不能有多个函数调用公共receive帮助程序。

我们在即将发布的 OTP 24 版本中解决了这些缺点，并添加了一个编译器选项来帮助您发现它的应用位置：

<Code language="shell">
{`$ erlc +recv_opt_info example.erl`}
</Code>

<Code language="erlang">
{`-module(example).
-export([t/2]).

t(Pid, Request) ->
%% example.erl:5: OPTIMIZED: reference used to mark a
%% message queue position
Mref = monitor(process, Pid),
Pid ! {self(), Mref, Request},
%% example.erl:7: INFO: passing reference created by
%% monitor/2 at example.erl:5
await_result(Mref).

await_result(Mref) ->
%% example.erl:10: OPTIMIZED: all clauses match reference
%% in function parameter 1
receive
{Mref, Response} ->
erlang:demonitor(Mref, [flush]),
{ok, Response};
{'DOWN', Mref, _, _, Reason} ->
{error, Reason}
end.`}
</Code>

消息传递（Message passing）的注意事项

## 介绍

Erlang 在 17.0 版中引入了一个新的数据结构，即 map()。这种结构是从键（key）到值（value）的有限映射，具有扁平的内部表示：映射本质上是两个数组：一个排序的键数组和一个值数组。反过来，这种所谓的flatmap表示对于较小尺寸的map是有效的，但它们对于大尺寸的map表现不佳。

18.0 版将消除大尺寸map的问题。在 18.0 中，一旦map增长到足够大，map就会在内部切换为使用 HAMT（哈希数组映射树）。它是一种巧妙的数据结构，将哈希表的属性与（级别压缩的）trie 相结合，以提供快速查找和持久性。这与 Clojure、Scala 和 Haskell（无序容器）等数据结构语言使用的相同。它们是由现在已故的 Phil Bagwell 设计的，而 Erlang 变体依靠 Clojure 中 Rich Hickey 的工作。

然而，这种新结构需要测试。 Erlang 是一门以运行稳定性而不是执行速度而自豪的语言。因此，显然应该在 18.0 最终发布之前尝试广泛地测试 Erlang Maps。我决定通过为 Erlang 中的低级映射操作构建 Erlang QuickCheck 模型，然后针对当前的稳定版本以及 18.0-rc1 候选版本进行测试，看看我们能走多远。

这篇博文的目的是讲述有关当前 QuickCheck 模型的故事。模型中有多少行代码，以及通过生成测试开始测试所需的工作量有多少。它还作为如何在实际项目中使用 QuickCheck 的示例。它用于娱乐和教学——或者至少这是我的希望。

将有多个博客文章，因为将工作分成多个部分感觉是正确的。第一部分介绍如何生成数据和第一个简单的测试。后面的部分将讨论更复杂的模型，它使用状态机来驱动测试的生成。

## QuickCheck primer
QuickCheck[1] 类似于模糊测试。模糊器用险恶的输入轰炸系统以破坏它——这样人们就可以利用错误——QC模型通过随机执行命令来检查系统的内部一致性。关键的区别在于，虽然 fuzzer 是黑盒的，并且通常对程序的内部工作有相对简单的理解，但 QC 测试是一个模型。它知道在给定情况下应该发生什么，并确保它是这样的。这使 QC 模型更加精确，因为它可以利用先验知识来指导接下来应该发生的事情。这种额外功能的代价是首先必须提出一个合适的模型。

在完整的模型检查中，首先要生成被测系统 (SUT) 的模型——一种简化的正式描述。然后，模型检查器通过系统地尝试每个可能的状态来详尽地验证模型相对于 SUT 的正确性。这种操作的复杂性在于某些模型表现出无限的命令序列。为了处理这些问题，可能有必要证明一个人有一个稳定的“循环”，以便在无限序列上打结，可以这么说。

QuickCheck[1] 作为概率模型检查器运行，因为我们不会详尽地检查模型。相反，我们从模型中得出随机事件轨迹并验证它们是否正确。用 John Hughes 的话来说，我们不写测试；我们生成它们。通过简单的配置，我们可以通过生成更多测试来调整我们对测试的信心。花更多的时间让我们更接近令人筋疲力尽的模型检查算法。我们还可以决定我们对模型的哪些区域感兴趣。我们可以权衡系统，将事件偏向某些我们知道在系统中更难纠正的区域。

任何测试系统都有一个无法进一步观察的规格限制。甚至像 Coq 这样的证明辅助系统也无法验证不属于规范的属性。我们只是希望有足够的测试在主题上形成一个保护性的网络：数学、程序或硬件，使得错误极不可能持续存在。我们希望保护网内的任何偏差都能在整个网络中引起反响，以便我们最终发现错误。简而言之，

> Testing shows the presence, not the absence of bugs — Dijkstra, 1969

然而，事实证明 QuickCheck 在显示错误存在方面是有效的。 该方法倾向于在程序中发现非常细微的错误，这些错误后来被发现是恶意的而不是良性的。 这对于适度的额外编程工作。 虽然编写起来比单元测试慢，但一旦模型启动并运行，优势就会翻千倍。 能够在一夜之间运行几百万个测试，所有不同的测试通常会在代码库中发现问题。

Erlang QuickCheck 是 QuickCheck 理念的一个实现。 它定义了一种用于编写模型的领域特定语言。 然后它包含了针对真实世界代码运行这些模型的工具。

## 策略

必须做的第一件事是想出一个测试map的策略。我们立即将低级映射从与编译器有关的事物中分离出来。映射语法是特定于编译器的。但在测试符号之前，我们应该测试“map”模块是否正确。如果没有在较低水平上建立信心，测试一个没有什么意义。

其次，测试用例应该是无状态的还是有状态的。在无状态测试用例中，快速检查模型没有状态，因此在调用map之间没有知识（也就是说，它更接近于 fuzzer）。对于纯函数，这通常是一种足够的测试方法，但真正的程序很少是完全纯粹的。我们想利用关于“什么”和“什么时候”的知识：我们想知道map内任何时间点的内容，以便我们决定要做什么。例如，我们想检查我们是否可以删除map中的现有元素。为此，我们必须知道map中有哪些元素——即状态。同样要检查map中不存在的元素是否被删除，我们必须知道map中没有哪些元素——同样是状态。

此外，我们需要查看两种类型的数据生成：

一，我们需要生成随机的map key和map value，我们可以用来操作map。我们还需要能够快速生成随机map。也就是说，我们需要生成可以推送到我们在“map”模块中调用的函数的具体数据。第二，我们需要从“map”模块生成随机命令。这使我们能够避免命令总是相同的静态测试。我们将在每个测试中运行数十个（有时是数百个）命令，随机决定要做什么，以确保“映射”调用的任何组合都是稳定的。在 Erlang QuickCheck 中，我们有“eqc_statem”系统，它将测试编码为状态机。反过来允许有状态的命令生成。
对于状态机模型，我们可以利用同构。受某些约束的 K/V 对列表在任何时候都与映射同构。使用“maps”模块中的函数更改map对列表有相应的操作。这导致模型应该使用map的列表表示，然后验证map是否以正确的方式操作。这是 QuickCheck 建模的一个常见技巧：模型具有高级数据结构的简单表示。因此我们可以使用简单且未优化的模型来确保复杂且优化的结构是正确的。

注意：有人可能认为有必要让模型快速执行。这种情况很少发生，如果有的话。模型应该专注于清晰度和可读性。阅读高级数据表示比阅读简单表示要困难得多。此外，模型如何缩小对于生成最少的反例很重要。通常，这意味着您需要一个效率较低的模型，但这种牺牲会产生最小化的反例。

为了检查地图，我们使用了两个模型。一个是对映射的简单同构属性的简单无状态测试。另一种是使用上述 list(\{K, V\}) 表示的更高级的有状态测试。通过将模型一分为二，我们可以先剔除简单的属性。如果简单的无状态模型失败，通常更容易找到罪魁祸首。此外，一旦简单模型通过，它提供了一些可以替代更高级模型的信心。它可能不会以某些方式失败。

## 生成map数据

首先，我们需要解决如何生成map内容。 如果我们要针对map触发随机命令，我们需要能够为map生成参数。 假设我们要生成一个 maps:put/3 命令。 它被称为 maps:put(Key, Value, Map)，因此我们需要能够生成随机键、随机值以及随机映射。

我们定义映射键和值将使用相同的生成器：

<Code language="erlang">
{`%% Keys and values are map terms
map_key() -> map_term().
map_value() -> map_term().`}
</Code>

然后我们可以在 map_term() 函数中定义真正的map生成器：

<Code language="erlang">
{`map_term() ->
 ?SIZED(Sz, map_term(Sz)).`}
</Code>

我们在 QuickCheck 中使用标准技巧。 ?SIZED 宏允许我们通过将生成的内容放入显式变量 Sz 中来获取当前大小。 大小通常在运行中从 0 左右开始，然后在随机测试过程中增加到 40 左右。 通过访问大小，我们可以控制如何生成给定大小的map项：

<Code language="erlang">
{`map_term(0) ->
 frequency([
 {100, oneof([int(), largeint(), atom(), binary(),
 bitstring(), bool(), char(), evil_real()])},
 {10, oneof([function0(int()), function2(int())])},
 {10, eqc_gen:largebinary()}
 ]);
map_term(K) ->
 frequency([
 {40,
 map_term(0)},
 {1,
 ?LAZY(list(map_term(K div 8)))},
 {1,
 ?LAZY(?LET(L, list(map_term(K div 8)),
 list_to_tuple(L)))},
 {1,
 ?LAZY(eqc_gen:map(map_term(K div 8),
 map_term(K div 8)))}
 ]).`}
</Code>

这里有两种情况。 生成大小为 0 的map将始终创建一个标量值。 它将加重它的一代。 120 次中有 100 次将生成整数、原子、二进制文件、布尔值等。 120 次中有 10 次将生成一个包含 0 或 2 个参数的函数（它们是纯的、确定的并返回整数）。 120 个中有 10 个会生成一个大的二进制文件（65 字节到 64 KB 之间）。 现实是邪恶的：

<Code language="erlang">
{`evil_real() ->
 frequency([
 {20, real()},
 {1, return(0.0)},
 {1, return(0.0/-1)}]).`}
</Code>

如果有人想知道为什么这些很有趣，请考虑 erlang:phash2(0.0) 与 erlang:phash2(0.0/-1)…[2]。

如果生成大小为 K 的映射项，则 43 次中的 40 次会生成一个标量。 但有时会生成映射项列表、元组或映射项映射。 递归调用将大小除以很多，以确保下一代更小，并且我们最终会达到标量。 ?LAZY 参数避免生成递归复合变体，除非频率/1 组合器最终选择该分支。 如果我们不使用 ?LAZY，那么我们每次都会生成所有的树，然后在树中挑选。 有了这个，我们只在树中生成一个“路径”，这要快得多。 Haskell 程序员免费获得此功能，但在严格的语言中，需要明确说明何时需要延迟运行。

现在，我们可以查看生成键/值对列表：

<Code language="erlang">
{`gen_map() ->
 ?SIZED(Sz, resize(Sz * 15,
 list({resize(Sz, map_key()), resize(Sz, map_value())}))).

map_list() ->
gen_map().

map_map() ->
?LET(ML, map_list(), maps:from_list(ML)).`}
</Code>

gen_map() 使用 ?SIZED 宏来获取当前的生成大小。 然后我们将列表生成器调整为 15 倍，但对键和值保持正常。 这使我们可以默认生成非常大的列表，而无需进行更多调整。

Erlang 18.0 内部具有 HAMT 结构，其切换到 HAMT 的内部断点目前是 32 个元素。 因此，我们需要确保在该范围内很好地生成列表，以测试 HAMT 结构的行为是否符合预期。 此外，如果我们发现错误，拥有 400 个元素的列表也不是问题。 QuickCheck 通过查找可以从列表中删除的元素来缩小列表。 因此，我们很可能会找到一个小得多的列表作为反例。

使用 gen_map()，我们可以直接生成适合map的列表。 我们可以通过调用 map_list() 生成map，然后使用 maps:from_list/1 的输出来构建包含内容的map。

## 无状态测试

map支持函数 f = maps:from_list/1 和 g = maps:to_list/1。 这两个函数在 map(A,B) 的域 M 和 list(\{A, B\})[3] 的域 L 之间形成了结构同构。 我们可以利用这一点，因为如果 m 是 M 中的任何映射，则 f(g(m)) = m。 如果 l 在 L 中，则 g(f(l)) = l。 这建立了与数学范畴相同意义上的同构。

我们可以在两个 QuickCheck 属性中实现这些规则。 fg 变体如下：

<Code language="erlang">
{`prop_list_iso_fg() ->
 ?FORALL(M, maps_eqc:map_map(),
 begin
 List = maps:to_list(M),
 M2 = maps:from_list(List),
 equals(M, M2)
 end).`}
</Code>

它本质上是上述要求的实现。 运行 gf 路径的对应项涉及更多：

<Code language="erlang">
{`prop_list_iso_gf() ->
 ?FORALL(L, maps_eqc:map_list(),
 begin
 LD = dedup(L),
 M = maps:from_list(L),
 LD2 = maps:to_list(M),
 equals(lists:sort(LD), lists:sort(LD2))
 end).`}
</Code>

该变体必须从列表中删除重复键，以使 L 域以明确定义的方式与 M 同构。 并且必须对结果进行排序，以确保列表具有规范的表示。 Maps 可以以任何顺序返回 K/V 对。

在使用 18.0 之前，我们在当前稳定版本 17.4.1 上运行测试用例。 对这些中的每一个运行 100 次测试结果都很好：

<Code language="erlang">
{`4> eqc:quickcheck(maps_iso_eqc:prop_list_iso_fg()).
....................................................................................................
OK, passed 100 tests
true
5> eqc:quickcheck(maps_iso_eqc:prop_list_iso_gf()).
....................................................................................................
OK, passed 100 tests
true`}
</Code>

## Binary变体

map可以通过函数 term_to_binary/2 和 binary_to_term/1 进行转换。 这些函数用于序列化数据，是 Erlang 的核心。 分发协议使用这些的变体。 许多需要传输erlang项目的地方都受益于紧凑、压缩的二进制表示。 同样，它是一个同构，因为我们可以从一个映射来回转换。 如果有足够的耐心，我们还可以构建一个二进制文件，将其解码为一个映射项。 但通常这被忽略了，因为从头开始构建二进制文件并不容易。

term_to_binary/2 函数接受一个选项列表，我们可以在测试中对其进行编码：

<Code language="erlang">
{`opts() ->
 ?LET({Compressed, MinorVersion},
 {oneof([[], [compressed], [{compressed, choose(0,9)}]]),
 oneof([[], [{minor_version, choose(0,1)}]])},
 Compressed ++ MinorVersion).`}
</Code>

然后我们可以使用 opts() 生成器来生成真正的测试用例：

<Code language="erlang">
{`prop_binary_iso_fg() ->
 ?FORALL([Opts, M],
 [opts(), maps_eqc:map_map()],
 begin
 Binary = term_to_binary(M, Opts),
 M2 = binary_to_term(Binary),
 equals(M, M2)
 end).`}
</Code>

它的工作原理与 list_fg 的情况完全相同：在二进制表示之间来回翻转并验证是否相等。 我们在 Erlang 17.4.1（稳定版）上运行了 100 个测试用例：

<Code language="erlang">
{`13> eqc:quickcheck(maps_iso_eqc:prop_binary_iso_fg()).
....Failed! After 5 tests.
#{-3878269413 => hill,
 -1 => stone,
 #Fun<eqc_gen.133.121384563> => sand,
 <<3:2>> => 0.0} /= 
#{-1 => stone,
 -3878269413 => hill,
 #Fun<eqc_gen.133.121384563> => sand,
 <<3:2>> => 0.0}
Shrinking xxxx.x.xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx................................xxxxxxxxxxxxxxxxxxxxxxxxxxxx(x10)xxxxxxx(x1).x(35 times)

#{-1 => flower,2147483647 => flower} /=
#{2147483647 => flower,-1 => flower}
false`}
</Code>

啊哈！ 5次测试失败，看起来很可疑！ map的内部顺序突然颠倒了。 这违反了关于内部flatmap表示的假设。 事实上，Wolfram Alpha 报告说——除了是素数——2147483647 也是 2³¹-1。 当我报告它时，它引起了一些警钟[4]，并且一个更新的稳定版本的 Erlang 将有一个修复（OTP-12623 在当前的维护分支上，如果运气好的话，它将在 17.5 中）。

## 更进一步深入

稍后的文章将介绍用于检查map模块的状态机“maps_eqc”模型。 它验证“map”模块的每个命令并报告更多统计信息。 目前的工作正在进行中，我们正在使用这些模型从 Erlang 18.0 中清除错误，并获得信心，我们不会在新的 HAMT 实现中引入明显的错误。 在这里，我们还修复了我们发现的现有错误[5]。 该模型已经在候选版本 18.0-rc1 中证明了它的价值，并发现了错误。 但随着 OTP 团队在候选版本之上的最新补丁，这些模型不再引发错误。

如果您对完整模型感兴趣，它是在 Apache 2.0 许可下开源的（在撰写本文时，提交 ID 为 5a9523f98635。预计模型会随着时间而改变）：

Erlang maps深度测试

很久以前写过一篇[The Asymmetry of ++](https://medium.com/erlang-battleground/the-asymmetry-of-validations-1ccdf2457293)的文章，感谢Fede Bergero的发现。 让我们在不对称列表中添加更多…

> 注意：本文基于 OTP23。 该版本之后，许多事情都得到了改进。

## 介绍

最初，我想把这篇文章写成一个故事（就像我通常做的那样），但我突然掌握了太多的信息。 所以，我选择从table、cheatsheet开始。

该列表的目的是显示lists模块中的不同高阶函数在输入错误时如何反应，特别是在它们期望函数的参数中。 这个错误的输入可能是……

- 不是函数的东西（例如 lists:map(not_fun, [1,2,3]);
- 具有错误的参数数量的函数（例如 lists:map(fun() -> wat end, [a])

## 空列表

在我们开始之前，现在这里揭示一半的问题。让我向您介绍第一个不对称：

<Code language="erlang">
{`1> lists:map(something_wrong, [1,2,3]). % A non-empty list
** exception error: bad function something_wrong
 in function lists:map/2 (lists.erl, line 1243)
2> lists:map(something_wrong, []). % An empty list
** exception error: no function clause matching lists:map(something_wrong,[]) (lists.erl, line 1242)`}
</Code>

这发生在您将在下面看到的所有函数中：如果您使用错误的第一个参数和一个空列表调用这些函数，您将收到 function_clause 错误。 如果你用根本不是列表的东西来调用它们，也会发生同样的情况。 如果您使用非空列表调用它们，那么……继续阅读；）

至少，当 list 参数为空列表时，lists 模块会持续引发 function_clause 错误。 这是一件好事。

## 非空列表

当列表不为空时会发生什么？ 为了弄清楚这一点，我使用下面这个代码进行试验：

<Code language="erlang">
{`-module(a_module).

-format #{inline_clause_bodies => true,
inline_items => all,
paper => 100}.

-export([run/0]).

run() ->
Arity2 =
[all, any, dropwhile, filter, filtermap, flatmap, foreach, map, partition, search, sort,
splitwith, takewhile, usort],
Arity3 = [foldl, foldr, keymap, mapfoldl, mapfoldr],
Result =
[[fun_name(F, 2) | run2(fun lists:F/2)] || F <- Arity2]
++ [[fun_name(F, 3) | run3(fun lists:F/3)] || F <- Arity3],
format(Result),
Result.

fun_name(Name, Arity) -> io_lib:format("~p/~p", [Name, Arity]).

run2(Function) ->
[test(fun() -> Function(not_a_function, sample_list()) end),
test(fun() -> Function(fun wrong_arity/0, sample_list()) end)].

run3(Function) ->
[test(fun() -> Function(not_a_function, 1, sample_list()) end),
test(fun() -> Function(fun wrong_arity/0, 1, sample_list()) end)].

test(Fun) ->
try
Fun()
catch
_:{Err, _} -> Err;
_:Err -> Err
end.

wrong_arity() -> "no list function expects a 0-arity fun as a parameter".

sample_list() -> [{this, "is for keymap"}].

format(Result) ->
io:format("Function|No Fun|Bad Fun\n"),
io:format("--------|------|-------\n"),
lists:foreach(fun(Row) -> io:format("\`~s\`\t| \`~p\` | \`~p\`\n", Row) end, Result).`}
</Code>

这些是我得到的结果……

|lists 函数 | No Fun | Bad Fun|
|:-- | :-- | :-- |
|all/2|	badfun	|badarity|
|any/2|	badfun	|badarity|
|dropwhile/2|	badfun	|badarity|
|filter/2|	function_clause	|function_clause|
|filtermap/2|	badfun	|badarity|
|flatmap/2|	badfun	|badarity|
|foreach/2|	badfun	|badarity|
|map/2|	badfun	|badarity|
|partition/2|	badfun	|badarity|
|search/2|	badfun	|badarity|
|sort/2|	function_clause	|function_clause|
|splitwith/2|	function_clause	|function_clause|
|takewhile/2|	badfun	|badarity|
|usort/2|	function_clause	|function_clause|
|foldl/3|	badfun	|badarity|
|foldr/3|	function_clause	|function_clause|
|keymap/3|	badfun	|badarity|
|mapfoldl/3|	badfun	|badarity|
|mapfoldr/3|	function_clause	|function_clause|

## 从中得到的发现

因此，如您所见，如果您根本不使用函数，大多数函数会引发 badfun 错误，如果使用错误的函数 arity 一般会引发 badarity 错误，但其中一些也会引发 function_clause 错误。

关联上下文后，这就是每个错误在shell中的描述……

<Code language="erlang">
{`10> lists:foldl(not_fun, 1, [a,b,c]).
** exception error: bad function not_fun
 in function lists:foldl/3 (lists.erl, line 1267)
11> lists:foldl(fun() -> {wrong, arity} end, 1, [a,b,c]).
** exception error: interpreted function with arity 0 called with two arguments
 in function lists:foldl/3 (lists.erl, line 1267)
12> lists:foldr(fun() -> {wrong, arity} end, 1, [a,b,c]).
** exception error: no function clause matching lists:foldr(#Fun<erl_eval.45.79398840>,1,[]) (lists.erl, line 1279)
 in function lists:foldr/3 (lists.erl, line 1280)`}
</Code>

至少从我的角度来看，lists:foldl/3 的错误描述比 list:foldr/3 更清楚。 正如我之前告诉你的，当列表为空时，所有函数看起来都像 lists:foldr/3（即，它们会在每个糟糕的情况下引发 function_clause）。

## 这是问题吗？

从语义上讲，这不是问题。 到目前为止，所有这些功能都没有针对我所展示的场景进行定义。 因此，我们不应该依赖它们在使用不正确的值调用它们时产生的错误。

但是，如果您是 Erlang 新手或者您正在控制台上尝试一些东西，那么您不太可能错误地调用上述函数之一。 在这种情况下，function_clause 可能会非常令人困惑，而 badfun 或 badarity 可以更轻松地引导您找到问题的解决方案。

此外，如果出于某种原因，您需要编写代码来捕获这些错误并且您不想捕获任何错误（仅是您需要的特定错误），您必须始终小心处理 function_clause 以防您的 输入是一个空列表。

换句话说，这是个问题。

<Code language="erlang">
{`%% @doc similar to lists:all/2 but if the function has the wrong
%% arity it just returns false.
-spec my_all(fun((...) -> boolean()), [X]) -> boolean().
my_all(Pred, List) ->
 try lists:all(Pred, List)
 catch
 error:{badarity, _} -> false
 end.`}
</Code>

因为…

<Code language="erlang">
{`45> a_module:my_all(fun(X) -> true end, [a,b,c]).
true
46> a_module:my_all(fun() -> true end, [a,b,c]).
false
47> a_module:my_all(fun() -> true end, []).
** exception error: no function clause matching lists:all(#Fun<erl_eval.45.79398840>,[]) (lists.erl, line 1216)
 in function a_module:my_all/2`}
</Code>

所以我们不得不像这样来写

<Code language="erlang">
{`%% @doc similar to lists:all/2 but if the function has the wrong
%% arity it just returns false.
-spec my_all(fun((...) -> boolean()), [X]) -> boolean().
my_all(Pred, List) ->
 try lists:all(Pred, List)
 catch
 error:{badarity, _} -> false
 error:function_clause when List == [] -> false
 end.`}
</Code>

## 我想看到什么？

我认为理想的情况是上表中的所有函数都具有相同的错误行为：

- 如果他们收到的东西不是他们期望的功能，请提出 badfun，无论列表长度如何。
- 如果他们收到一个错误的函数，无论列表长度如何，都会提高 badarity。
- 如果列表或任何其他参数错误（例如，不是列表），请提出 function_clause。

基本上，行为类似于 lists:foldl/3 ，但不要将空列表视为特殊情况。

### 这是否可行？

是的！ 列表模块中的更改实际上并没有那么复杂。 以 lists:map/2 为例，我们“只”需要在此处添加这两个子句：

<Code language="erlang">
{`map(F, [H|T]) ->
 [F(H)|map(F, T)];
map(F, []) when is_function(F, 1) -> [];
map(F, []) when is_function(F) -> error({badarity, {F, []}});
map(_, []) -> error(badfun).`}
</Code>

### 这是否值得？

我不知道……也许吧？ 也许这是赌一下的好时机？ 🙃

Erlang中的list函数如何失败？

[Rebar3](https://rebar3.org/)带有许多新的和改进的功能。在接下来的几周内，我将在这里发布博文以介绍其中的一些功能。

## 本地安装和升级

Rebar 是一个 escript 包，这对其易用性来说是非常重要的，主要是因为它们让 Erlang 用户可以将单个文件作为可执行文件，而不管底层的 Erlang 安装如何，甚至可以提交到项目的存储库。

所以，rebar3 也是一个脚本。可以从 s3 下载预构建的 escripts：

<Code language="shell">
{`$ wget https://s3.amazonaws.com/rebar3/rebar3`}
</Code>

或clone并bootstrap git repo：

<Code language="shell">
{`$ git clone https://github.com/rebar/rebar3.git
$ cd rebar3
$ ./bootstrap`}
</Code>

但是，escripts 确实有其缺点。它们启动速度较慢，依赖于旧的 Erlang io 服务器，运行 shell脚本rebar3 shell的行为与erl不完全相同，并且可能导致 repos 将 escript 与代码一起存储，但却从不升级它。

因此，在 rebar3 中，我们引入了提取 escript 存档以及运行脚本的功能~/.cache/rebar3/，以及一个将从 s3 获取 rebar3 的最新 escript 版本并执行相同操作的命令。

该install命令将位于提供程序命名空间下，最初它位于 命名空间下unstable，该命名空间用于在不久的将来可能会更改并且尚未被认为是稳定的实验性功能，但现在位于local命名空间中：

<Code language="shell">
{`$ ./rebar3 local install
===> Extracting rebar3 libs to $HOME/.cache/rebar3/lib...
===> Writing rebar3 run script $HOME/.cache/rebar3/bin/rebar3...
===> Add to $PATH for use: export PATH=$HOME/.cache/rebar3/bin:$PATH`}
</Code>

按照说明将 rebar3 bin 目录添加到您的$PATH中，或者添加到shell的配置文件~/.bashrc或~/.zshrc中.

要升级 rebar3 使用rebar3 local upgrade它将获取最新的 escript 并提取它：

<Code language="shell">
{`$ rebar3 local upgrade`}
</Code>

我们希望这种安装、升级和运行 rebar3 的新方法能让人们在项目存储库中不再捆绑 rebar3，解决 rebar3 和替代 Erlang 构建工具之间的任何编译速度差异，并帮助每个人了解最新功能和错误修复。

## 依赖关系树

rebar3 tree是一个新命令，允许用户查看每个传递依赖项中提取的依赖项。这对于 rebar3 的“first wins”依赖解决策略特别有用。

感谢[Heinz N. Gies](https://github.com/Licenser/)推动此功能，灵感来自[leiningen](https://github.com/technomancy/leiningen)的命令lein deps :tree。

例如，我克隆了[chef-server](https://github.com/chef/chef-server/)并在src/oc_erchef目录下构建oc_erchef. 它是独一无二的，因为它既在src/中有顶级应用程序oc_erchef，也在apps/有其他项目应用程序。

此外，我还添加了_checkouts/erlware_commons以显示checkout dependencies（链接到 under 的应用程序），将其移动到顶层并标记为(checkout app)。并将lager切换到[hex package dependency](http://hex.pm/)，其余的是git sourced dependencies。

<Code language="shell">
{`$ rebar3 tree
├─ chef_db─12.1.2-6047c67 (project app)
├─ chef_index─12.1.2-6047c67 (project app)
├─ chef_objects─12.1.2-6047c67 (project app)
├─ chef_test─12.1.2-6047c67 (project app)
├─ depsolver─12.1.2-6047c67 (project app)
├─ erlware_commons─0.16.0 (checkout app)
├─ oc_chef_authz─12.1.2-6047c67 (project app)
├─ oc_chef_wm─12.1.2-6047c67 (project app)
└─ oc_erchef─12.1.2-6047c67 (project app)
 ├─ bcrypt─0.0.0+build.87.ref085eb59 (git repo)
 ├─ chef_authn─0.0.0+build.86.refe7850d0 (git repo)
 ├─ darklaunch─0.0.0+build.72.ref05881cb (git repo)
 │ └─ meck─0.8.3 (git repo)
 ├─ efast_xs─0.1.0 (git repo)
 ├─ ej─0.0.0+build.87.ref132a9a3 (git repo)
 ├─ envy─0.0.0+build.38.ref954c87a (git repo)
 ├─ eper─0.90.0 (git repo)
 ├─ folsom─0.0.0+build.335.ref38e2cce (git repo)
 │ └─ bear─0.0.0+build.32.ref1192345 (git repo)
 ├─ folsom_graphite─0.0.0+build.41.refd4ce9bf (git repo)
 ├─ gen_bunny─0.1 (git repo)
 │ ├─ amqp_client─0.0.0 (git repo)
 │ └─ rabbit_common─0.0.0 (git repo)
 │ └─ gen_server2─1.0.0 (git repo)
 ├─ ibrowse─4.0.1.1 (git repo)
 ├─ jiffy─0.0.0+build.131.reff661ee9 (git repo)
 ├─ lager─2.1.1 (hex package)
 │ └─ goldrush─0.1.6 (hex package)
 ├─ mini_s3─0.0.1 (git repo)
 ├─ mixer─0.1.1 (git repo)
 ├─ neotoma─0.0.0+build.125.ref760928e (git repo)
 ├─ opscoderl_folsom─0.0.1 (git repo)
 ├─ opscoderl_httpc─0.0.1 (git repo)
 ├─ opscoderl_wm─0.0.1 (git repo)
 │ └─ webmachine─0.0.0+build.526.ref7677c24 (git repo)
 │ └─ mochiweb─2.9.0 (git repo)
 ├─ pooler─0.0.0+build.159.ref7bb8ab8 (git repo)
 ├─ sqerl─1.0.0 (git repo)
 │ └─ epgsql─3.1.0 (git repo)
 ├─ stats_hero─0.0.0+build.73.refff00041 (git repo)
 │ └─ edown─0.2.4+build.66.ref30a9f78 (git repo)
 ├─ sync─0.1.3 (git repo)
 └─ uuid─1.3.2 (git repo)
 └─ quickrand─1.3.2 (git repo)`}
</Code>

## Overrides

当rebar.config中的依赖项有导致出现问题的设置时，您会怎么做？也许它包括在一般情况下不需要的依赖项，例如meckor edown。或者它可能设置了不准确的所需 OTP 版本并且您想要删除它。或者应用程序可能包含需要编译并依赖于 rebar2 的端口编译器的 C 代码。这些问题通常会导致项目分叉，这对任何人都不利，因此在 rebar3 中我们添加了一个名为overrides.

覆盖允许rebar.config比依赖项更高级别的任何内容替换或添加到较低级别的所有或单个应用程序的配置。

覆盖的类型规范如下所示：

<Code language="erlang">
{`{overrides, [{add, atom(), [{atom(), any()]}
 | {override, atom(), [{atom(), any()]},
 | {override, [{atom(), any()]} 
 ]}.`}
</Code>

Basho的[bitcask](https://github.com/basho/bitcask/)应用程序配置为使用 rebar2 构建，但用户无需分叉项目并修补配置，只需将以下覆盖部分添加到他们的rebar.config：

<Code language="erlang">
{`{overrides, 
 [
 {override, bitcask,
 [{deps, []},
 {plugins, [pc]},
 {artifacts, ["priv/bitcask.so"]},
 {provider_hooks, [{post, 
 [{compile, {pc, compile}},
 {clean, {pc, clean}}]
 }]}
 ]
 }
 ]
}.`}
</Code>

这些覆盖用于bitcask将其deps条目替换为空列表，这将删除meck仅在运行测试时才需要的依赖项和不需要的cuttlefish依赖项。另外，由于 rebar3 中删除了端口编译器功能，因此必须添加端口编译器插件并将其compile挂接clean到provider_hooks.

## Profiles

配置文件可以用任何原子命名，可以将新项目添加到配置中，或者为现有元素添加新选项，并且多个配置文件可以自己组合。

两个特殊配置文件是default和global。default是所有运行的配置文件，输出将转到_build/default/，除非除 . 之外还指定了另一个default。当多个配置文件一起使用时，输出目录是连接在一起的配置文件+，例如 runningrebar3 as test,prod &lt;task&gt;会产生_build/test+prod/，但是在该运行中使用的配置文件的实际组合是default,test,prod，在输出default中总是从开头删除，除非它是唯一的配置文件利用。

另一个关于配置文件如何决定输出写入位置的特殊情况global总是引用~/.cache/rebar3/.

提供者可以default使用. 附带的四个提供程序指定了一个配置文件：、use和uses 。\{profiles, [atom()]\}providers:create/1rebar3eunitctcovertestedocdocs

配置文件使用示例可以帮助您了解如何在项目中使用它们。

<Code language="erlang">
{`{profiles, 
 [{test, [{deps,
 [
 meck,
 {eunit_formatters, {git, "git://github.com/seancribbs/eunit_formatters", {branch, "master"}}}
 ]},

 {eunit_opts, [
 no_tty,
 {report, {eunit_progress, [colored, profile]}}
 ]}
 ]
},
....`}
</Code>

rebar2 中的另一个常见依赖项将包含在主依赖项列表中，因此即使在用作依赖项时也会被获取edown。使用运行的docs配置文件可以通过在配置文件下edoc移动来解决edown：

<Code language="erlang">
{`{profiles, [{docs, 
 [{deps, [
 {edown, {git, "git://github.com/uwiger/edown.git", {branch, "master"}}}
 ]}]
 }]
}.
`}
</Code>

dev_mode开发版本时，使用 relx并将其设置include_erts为 false很有用。但是在为生产构建版本时，您会想要相反的结果。在这种情况下，与测试和文档不同，需要指定要运行命令的配置文件。运行rebar3 release将默认运行，因此使用dev_mode为true 和include_erts为false，同时rebar3 as prod release从prod配置文件中提取设置，使dev_mode为false 和include_erts为true。

<Code language="erlang">
{`{relx, [...
 {dev_mode, true},
 {include_erts, false},
 ...
 ]}.

{profiles,
[{prod, [{relx, [
{dev_mode, false},
{include_erts, true}
]
}]
},`}
</Code>

该global配置文件特别用于用户在其个人中定义的插件rebar.config。例如，我运行rebar3 as global plugins upgrade以升级我在~/.config/rebar3/rebar.config中配置的两个插件：

<Code language="erlang">
{`{plugins, [rebar3_hex, rebar3_run]}.`}
</Code>

配置文件是 rebar 配置的重要补充，可简化开发和依赖关系管理。如果要成为一名优秀的 Erlang 公民，请将您的依赖项分离到适当的配置文件中，那些依赖您的应用程序的人会很感激。

Rebar3 功能介绍

在我对 rebar 的实验中，我制作了一个简单的示例应用程序来测试upgrades和releases。本文将引导您使用 rebar 创建应用程序、正确布局、打包和部署它，以及创建和安装新版本而无需停机。

本文随附的代码位于[github.com/RJ/erlang_rebar_example_project](https://github.com/RJ/erlang_rebar_example_project)的各个分支中。

> 注意：如果您想了解 Erlang 应用程序和版本的 OTP 方法概述，[OTP 设计原则文档](http://www.erlang.org/doc/design_principles/des_princ.html)是一个很好的起点。但是，rebar（还）不是 OTP 的一部分，因此请考虑背景阅读。rebar使事情变得更容易。

## 创建项目

构建rebar：

<Code language="shell">
{`$ cd ~/src
$ git clone https://github.com/basho/rebar.git
Initialized empty Git repository in /tmp/rebar/.git/
remote: Counting objects: 2651, done.
remote: Compressing objects: 100% (1344/1344), done.
remote: Total 2651 (delta 1540), reused 2227 (delta 1174)
Receiving objects: 100% (2651/2651), 622.99 KiB | 495 KiB/s, done.
Resolving deltas: 100% (1540/1540), done.
$ cd rebar && make
...snip....
==> rebar (compile)
Congratulations! You now have a self-contained script called "rebar" in
your current working directory. Place this script anywhere in your path
and you can use rebar to build OTP-compliant apps.`}
</Code>

现在我们将创建一个名为“dummy_proj”的项目目录，将 rebar 复制到其中，并使用 rebar 生成一个骨架应用程序：

<Code language="shell">
{`$ mkdir -p ~/src/dummy_proj/apps
$ cd ~/src/dummy_proj/
$ cp ../rebar/rebar .
$ cd apps
$ ../rebar create-app appid=dummy_proj
==> dummy_proj (create-app)
Writing src/dummy_proj.app.src
Writing src/dummy_proj_app.erl
Writing src/dummy_proj_sup.erl`}
</Code>

在骨架中，我添加了一个名为 dummy_proj_server 的基本 gen_server，它只是跟踪它被推动的次数，即它保持一些状态，用于演示目的。

我还将 dummy_proj_app.erl 重命名为 dummy_proj.erl，并添加了一个 start/0 函数，该函数在开发期间启动应用程序时很有用，而不是从生成的版本运行。

## 用rebar编译

你需要一个 rebar.conf，把它放在顶层项目目录中：

<Code language="erlang">
{`{sub_dirs, [
 "apps/dummy_proj",
 "rel"
 ]}.
{erl_opts, [debug_info, fail_on_warning]}.

{require_otp_vsn, "R14"}.`}
</Code>

现在你这样做，进行编译：

<Code language="shell">
{`$ ./rebar compile
==> dummy_proj (compile)
Compiled src/dummy_proj_sup.erl
Compiled src/dummy_proj.erl
Compiled src/dummy_proj_server.erl
==> rel (compile)
==> dummy_proj (compile)`}
</Code>

请注意，您现在在 apps/dummy_proj/ebin/ 中有 .beam 文件，并且 .app.src 为您生成了 apps/dummy_proj/ebin/dummy_proj.app 以及完整的模块列表。

> 注意：我做了一个简单的 Makefile 调用’rebar compile’，因为我太习惯于输入 make。可以在 git repo 中找到它。

## 运行您的应用程序（development）

以下是启动应用程序的方法（包含sasl，以便提供良好的错误报告）：

<Code language="shell">
{`$ erl -pa apps/*/ebin -boot start_sasl -s dummy_proj
...snip...
=INFO REPORT==== 16-Mar-2011::14:17:04 ===
Starting dummy_proj application...

=PROGRESS REPORT==== 16-Mar-2011::14:17:04 ===
supervisor: {local,dummy_proj_sup}
started: [{pid,<0.45.0>},
{name,dummy_proj_server},
{mfargs,{dummy_proj_server,start_link,[]} },
{restart_type,permanent},
{shutdown,5000},
{child_type,worker}]

=PROGRESS REPORT==== 16-Mar-2011::14:17:04 ===
application: dummy_proj
started_at: nonode@nohost
Eshell V5.8.1 (abort with ^G)
1> dummy_proj_server:num_pokes().
0
2> dummy_proj_server:poke(). 
{ok,1}
3> dummy_proj_server:poke().
{ok,2}
4> dummy_proj_server:num_pokes().
2
5> `}
</Code>

现在你有一个很好的结构合理的 Erlang 项目，你可以用 rebar 编译它。使用 q() 退出 VM。让我们使用 rebar 将其打包，这样您就可以将其部署到生产环境上。

## 生成您的第一个版本

当您使用 rebar 生成版本时，实际上如果您手动使用 erlang 工具（不推荐，期望使用 rebar工具），您最终会将整个 Erlang VM 和所需的库打包在一个目录下。

这意味着您拥有一个包含 Erlang、您需要的 OTP 库以及所有应用程序代码和依赖项的自包含环境。您可以将其打包，将其传送到另一台机器（具有相同架构，例如 GNU/Linux 64 位），然后在那里运行它

### 创建节点配置

使用 rebar 在 rel 子目录中创建默认节点配置：

<Code language="shell">
{`$ mkdir rel
$ cd rel/
$ ../rebar create-node nodeid=dummynode
==> rel (create-node)
Writing reltool.config
Writing files/erl
Writing files/nodetool
Writing files/dummynode
Writing files/app.config
Writing files/vm.args`}
</Code>

您需要稍微编辑一下 reltool.config；指向您的应用程序目录，并确保版本号与您的 .app.src 文件匹配。您还应该将 dummy_app 添加到作为发布的一部分启动的应用程序列表中。这是我的 [v1](https://github.com/RJ/erlang_rebar_example_project/blob/v1/rel/reltool.config) 标签中的 reltool.conf

### 生成发布

回到顶层目录，只需运行：

<Code language="shell">
{`$ ./rebar generate
==> rel (generate)`}
</Code>

现在看看 rel/dummynode。这是包含运行应用程序所需的所有内容的发布目录。

稍后我们将创建更多版本，因此将 rel/dummynode 重命名为 rel/dummynode_first，然后使用 rebar 为我们创建的便捷脚本启动它：

<Code language="shell">
{`$ cd rel/dummynode_first
$ ./bin/dummynode console
...snip...
Erlang R14B (erts-5.8.1) [source] [64-bit] [smp:8:8] [rq:8] [async-threads:5] [hipe] [kernel-poll:true
=INFO REPORT==== 16-Mar-2011::13:29:59 ===
Starting dummy_proj application...
Eshell V5.8.1 (abort with ^G)
(dummynode@127.0.0.1)1> 
(dummynode@127.0.0.1)1> dummy_proj_server:num_pokes().
0
(dummynode@127.0.0.1)2> dummy_proj_server:poke(). 
{ok,1}
(dummynode@127.0.0.1)3> dummy_proj_server:poke().
{ok,2}
(dummynode@127.0.0.1)4> dummy_proj_server:num_pokes().
2
(dummynode@127.0.0.1)5>`}
</Code>

当前的版本正在运行，我们再也不想重新启动它，所以打开另一个控制台，因为我们希望在处理版本 2 时保持它运行。

> 在生产环境中，您可以从“./bin/dummynode start”开始，以便它在后台运行，然后使用“dummynode attach”来获取控制台。

check github 上的“v1 分支”以获取到目前为止的代码。

## 升级到版本 2

将 poke_twice() 函数添加到 dummy_proj_server。

在 apps/dummy_proj.app.src 和 rel/reltool.conf 中将版本从“1”更改为“2”。

这是 v1…v2 之间的 github[差异](https://github.com/RJ/erlang_rebar_example_project/compare/v1...v2#diff-3)

Erlang 应用程序版本号可以是任何字符串——我倾向于使用带有字母的日期格式：“20110316a”，但你可以使用任何你想要的方案。我在 git 中使用与 erlang 应用程序相同的版本标记发布。为简单起见，我们在这里只使用“1”、“2”、“3”。

> 注意：如果您在 .app.src 中通过\{vsn, git\}使用版本，rebar 将从最近的 git 标签中获取版本字符串。

现在构建新版本：

<Code language="shell">
{`$ ./rebar compile
$ ./rebar generate`}
</Code>

所以现在你有了 rel/dummy_proj，其中包含版本 2 的完整版本（包括 VM）。如果你不关心在线升级，你可以杀死你的版本 1 VM，并从这个新的发布目录启动版本 2。

### 编写 .appup 升级说明

为了进行升级，您必须拥有一个有效的 .appup 文件。这告诉 erlang release_handler 如何在应用程序的特定版本之间升级和降级。

Rebar 有一个（相对较新的）命令，称为“generate-appups”。我将展示它是如何工作的，但最终我们将手动编写我们的 .appup，并将其保存在我们的项目目录中（在 git 中）。

<Code language="shell">
{`$ ./rebar generate-appups previous_release=dummynode_first
==> rel (generate-appups)
Generated appup for dummy_proj
Appup generation complete
$ cat ./rel/dummynode/lib/dummy_proj-2/ebin/dummy_proj.appup
%% appup generated for dummy_proj by rebar ("2011/03/16 13:37:43")¬ 
{"2", [{"1", [{update,dummy_proj_server,{advanced,[]}}]}], [{"1", []}]}.¬`}
</Code>

摆脱自动生成的文件，并在apps/dummy_proj/ebin/dummy_proj.appup 中手动创建appup 文件：

<Code language="erlang">
{`{"2", 
 %% Upgrade instructions from 1 to 2
 [{"1", [
 {load_module, dummy_proj_server} 
 ]}], 
 %% Downgrade instructions from 2 to 1
 [{"1",[
 {load_module, dummy_proj_server} 
 ]}]
}.`}
</Code>

此 .appup 包含在版本“2”和“1”之间升级和降级的说明。通常，降级说明与升级说明相反。由于我们只是在我们的服务器进程中添加了一个函数，没有改变任何内部状态，我们可以使用 load_module 指令。Appup Cookbook 深入解释了各种升级说明。

现在再次生成，覆盖之前的版本 2。这将确保 .appup 是发布目录的一部分：

<Code language="shell">
{`$ ./rebar generate -f`}
</Code>

现在，创建升级包：

<Code language="shell">
{`$ ./rebar generate-upgrade previous_release=dummynode_first
==> rel (generate-upgrade)
dummynode_2 upgrade package created`}
</Code>

generate-upgrade 命令将查找 rel/dummynode 作为当前版本，并查找 rel/dummynode_first 作为以前的版本。它应该在 rel 中创建了升级 .tar.gz：

<Code language="shell">
{`$ ls -lh rel/
total 15M
drwxr-xr-x 8 rj rj 4.0K 2011-03-16 13:42 dummynode
drwxr-xr-x 8 rj rj 4.0K 2011-03-16 13:29 dummynode_first
-rw-r--r-- 1 rj rj 14M 2011-03-16 13:45 dummynode_2.tar.gz
drwxr-xr-x 2 rj rj 4.0K 2011-03-16 13:11 files
-rw-r--r-- 1 rj rj 922 2011-03-16 13:36 reltool.config`}
</Code>

### 安装升级包

您仍然应该让虚拟机从 dummynode_first 运行。确保调用了 poke()，因此内部状态不是默认值。这将有助于说明升级工作无缝。

将升级包复制到正在运行的版本的releases目录下：

<Code language="shell">
{`$ cp rel/dummynode_2.tar.gz rel/dummynode_first/releases`}
</Code>

现在，在运行版本 1 的 Erlang 控制台中，我们使用 release_handler 检查当前可用的版本，并安装我们的新版本：

<Code language="erlang">
{`(dummynode@127.0.0.1)5> release_handler:which_releases().
[{"dummynode","1",[],permanent}]
(dummynode@127.0.0.1)6> release_handler:unpack_release("dummynode_2").
{ok,"2"}
(dummynode@127.0.0.1)7> release_handler:install_release("2").
{ok,"1",[]} 
(dummynode@127.0.0.1)8> dummy_proj_server:num_pokes().
2
(dummynode@127.0.0.1)9> dummy_proj_server:poke_twice().
{ok,4}
(dummynode@127.0.0.1)10> dummy_proj_server:num_pokes(). 
4
(dummynode@127.0.0.1)11> release_handler:which_releases().
[{"dummynode","2",
 ["kernel-2.14.1","stdlib-1.17.1","dummy_proj-2",
 "sasl-2.1.9.2","compiler-4.7.1","crypto-2.0.1",
 "syntax_tools-1.6.6","edoc-0.7.6.7","et-1.4.1","gs-1.5.13",
 "hipe-3.7.7","inets-5.5","mnesia-4.4.15","observer-0.9.8.3",
 "public_key-0.8","runtime_tools-1.8.4.1","ssl-4.0.1",
 "tools-2.6.6.1","webtool-0.8.7","wx-0.98.7","xmerl-1.2.6"],
 current},
 {"dummynode","1",[],permanent}]`}
</Code>

升级成功；您可以看到 num_pokes() 被保留，并且新的 poke_twice() 函数可用。

release_handler 将我们的版本 2 显示为“当前”，将原始版本 1 显示为“永久”。这意味着虽然版本 2 现在正在运行，但如果您重新启动 VM，版本“1”将启动。

如果您对升级感到满意，请将其永久化，这意味着如果您重新启动 VM，它将启动而不是版本 1：

<Code language="erlang">
{`(dummynode@127.0.0.1)12> release_handler:make_permanent("2").`}
</Code>

到目前为止，请check github 上的“v2 分支”以获取代码。

## 版本 3 及更高版本

从 v1 升级到 v2 很简单：我们只是在不更改内部 #state{} 记录的情况下添加了一个乐趣。

Erlang .appup 文件可以做各种聪明的事情，允许您在升级过程中重新连接正在运行的应用程序。

[Appup Cookbook](http://www.erlang.org/doc/design_principles/appup_cookbook.html)详细介绍了您可以在 .appup 中放入的各种命令。

让我们使用更复杂的应用程序进行升级 – 我们将更改 dummy_proj_server 进程中的#state 记录。

对于版本 3，我们将跟踪 prods 和 pokes，这将需要状态记录中的另一个字段。

这是 v2…v3 之间的 github[差异](https://github.com/RJ/erlang_rebar_example_project/compare/v2...v3#diff-2)。

查看此版本对 .appup 的补充：

<Code language="erlang">
{`{"3", 
 %% Upgrade instructions
 [{"2", [
 {update,dummy_app_server,{advanced,[from2to3]}}
 ]}], 
 %% Downgrade instructions
 [{"2",[
 {update,dummy_app_server,{advanced,[from3to2]}}
 ]}]
}.`}
</Code>

此 \{update..\} 指令将导致在 dummy_app_server 上调用 code_change 函数。code_change 的目的是将状态从旧的 (v2) 格式更改为新的 (v3) 格式。

虽然这不是绝对必要的，但我在 code_change 调用中将“from2to3”作为“Extra”字段传递。这可以进行模式匹配，并在您的 code_change 代码中明确说明预期的版本升级。

### 打包并升级到 v3

移动为 v2 生成的发布目录：

<Code language="shell">
{`$ mv rel/dummynode rel/dummynode_2`}
</Code>

为 v3 编译生成，然后创建升级包：

<Code language="shell">
{`$ ./rebar compile
$ ./rebar generate
$ ./rebar generate-upgrade previous_release=dummynode_2`}
</Code>

和之前一样，将升级包复制到正在运行的版本的releases目录下：

<Code language="shell">
{`$ cp rel/dummynode_3.tar.gz rel/dummynode_first/releases`}
</Code>

现在，在您将 v1 升级到 v2 的 Erlang 控制台中：

<Code language="erlang">
{`(dummynode@127.0.0.1)12> release_handler:unpack_release("dummynode_3").
{ok,"3"}
(dummynode@127.0.0.1)13> release_handler:install_release("3").
{ok,"2",[]}`}
</Code>

## 恭喜

现在您可以以正确的 OTP 方式部署热代码升级。非常适合更改内部状态或确实需要特殊升级的复杂、大型升级。阅读 Appup Cookbook 几次，并**在部署之前在测试环境中测试您的升级包**。您可以将实时环境 tar 打包并复制到您的测试环境箱，以获得生产系统的精确克隆以测试升级。

使用rebar生成releases和upgrades

Rebar3 是 Erlang 的构建工具和包管理工具。借助 [Rebar3](http://www.rebar3.org/)及其[Hex](https://hex.pm/)插件，创建和发布您的 Erlang 包非常简单。让我们做一个简单的“hello world”包，尝试一下吧！

## 下载 Rebar3

在此处下载最新版本：http://www.rebar3.org/ 。

<Code language="shell">
{`curl -O https://s3.amazonaws.com/rebar3/rebar3`}
</Code>

使用 chmod 为其添加执行权限，然后添加到环境变量 PATH中。

<Code language="shell">
{`chmod +x rebar3 
export PATH=$PATH:your-current-directory`}
</Code>

## 你的第一个 Erlang 应用

使用命令**rebar3 new**，将开始使用名为app的内置模板生成一个新项目。在此示例中，我们正在创建一个名为myapp的项目。其他可用模板有：release、lib、plugin、escript、cmake。

<Code language="shell">
{`$ rebar3 new app myapp
===> Writing myapp/src/myapp_app.erl
===> Writing myapp/src/myapp_sup.erl
===> Writing myapp/src/myapp.app.src
===> Writing myapp/rebar.config
===> Writing myapp/.gitignore
===> Writing myapp/LICENSE
===> Writing myapp/README.md`}
</Code>

你的代码放在src目录中。

<Code language="shell">
{`$ cd myapp
$ tree
.
├── LICENSE
├── README.md
├── rebar.config
└── src
 ├── myapp.app.src
 ├── myapp_app.erl
 └── myapp_sup.erl`}
</Code>

常见的是使用一个.app.src文件将您的应用程序定义为 OTP application，因为 Rebar3 仅处理[OTP 结构化项目](http://www.erlang.org/doc/design_principles/applications.html)。看起来很熟悉？该文件也是 Erlang代码。查看完整的[参考资料](http://www.erlang.org/doc/design_principles/applications.html#id73836)，看看它可以包含什么。

<Code language="shell">
{`$ cat src/myapp.app.src 
{application, 'myapp',
 [{description, "An OTP application"},
 {vsn, "0.1.0"},
 {registered, []},
 {mod, {'myapp_app', []}},
 {applications,
 [kernel,
 stdlib
 ]},
 {env,[]},
 {modules, []}
 ]}.`}
</Code>

src/myapp_app.erl中的代码非常简单。它只是确保您可以启动和停止您的 Erlang 应用程序：

<Code language="shell">
{`$ cat src/myapp_app.erl 
-module('myapp_app').
-behaviour(application).
-export([start/2, stop/1]).
start(_StartType, _StartArgs) ->
 'myapp_sup':start_link().
stop(_State) ->
 ok.`}
</Code>

Rebar3 使用一个名为rebar.config的文件来指定附加元数据，例如[依赖项](https://github.com/rebar/rebar/wiki/Dependency-management)。rebar.config可以包含很多字段。要查看它们，请查看[完整示例](https://github.com/rebar/rebar/blob/master/rebar.config.sample)。

<Code language="shell">
{`$ cat rebar.config 
{erl_opts, [debug_info]}.
{deps, []}.`}
</Code>

现在让我们使用 Rebar3 启动一个 Erlang shell，其中包含您的应用程序和路径中的依赖项。运行application:start(myapp).验证您的应用是否已正确加载。

<Code language="shell">
{`$ rebar3 shell
===> Verifying dependencies...
===> Compiling myapp
Erlang R16B03-1 (erts-5.10.4) [source] [64-bit] [smp:8:8] [async-threads:0] [hipe] [kernel-poll:false]
Eshell V5.10.4 (abort with ^G)
1> application:start(myapp).
ok
2> application:stop(myapp). 
ok
3> 
=INFO REPORT==== 29-Jun-2015::16:14:10 ===
 application: myapp
 exited: stopped
 type: temporary`}
</Code>

为了了解命令rebar3 shell，[Fred Hebert](https://github.com/ferd)（[《Learn You Some Erlang》](http://learnyousomeerlang.com/)的作者）在[这里](http://ferd.ca/rebar3-shell.html)写了一篇很好的文章。

## Erlang Packages

### 在你开始前

我们需要安装一个名为[rebar3_hex](https://github.com/hexpm/rebar3_hex)的插件，以便从Erlang/Elixir 包管理器[Hex.pm](https://hex.pm/)获取和安装 Erlang 包。只需将以下行添加到您的rebar.config文件中。（您需要 Erlang 版本 OTP 17.4 及以上）

<Code language="shell">
{`{plugins, [rebar3_hex]}.`}
</Code>

然后运行命令：rebar3 update以启用插件。

<Code language="shell">
{`$ rebar3 update
===> Fetching jsx ({pkg,<<"jsx">>,<<"2.6.1">>})
===> Fetching ssl_verify_hostname ({pkg,<<"ssl_verify_hostname">>,
 <<"1.0.5">>})
===> Fetching rebar3_hex ({pkg,<<"rebar3_hex">>,<<"0.6.0">>})
===> Compiling ssl_verify_hostname
===> Compiling jsx
===> Compiling rebar3_hex
===> Updating package index...`}
</Code>

如果您想在每次创建新的 Erlang 应用程序时避免此步骤，请将条目添加到全局rebar.config并将其放置在：

<Code language="shell">
{`~/.config/rebar3/rebar.config`}
</Code>

### 查找 Erlang 包

搜索命令可以让你找到在Hex.pm上发布的远程 Erlang 包。您可以在查询中使用正则表达式字符：

<Code language="shell">
{`$ rebar3 hex search cowboy
cloudi_service_http_cowboy
cowboy`}
</Code>

### 安装包

Rebar3 可以下载和安装 Erlang 包和任何必要的依赖项。将应用程序名称添加到rebar.config文件中的deps条目，然后运行命令：rebar3 compile。在这个例子中，我们尝试使用两个 Erlang 包，分别是cowboy和meck。

<Code language="shell">
{`{deps, [cowboy, meck]}.$ rebar3 compile
===> Verifying dependencies...
===> Fetching ranch ({pkg,<<"ranch">>,<<"1.0.0">>})
===> Fetching meck ({pkg,<<"meck">>,<<"0.8.2">>})
===> Fetching cowlib ({pkg,<<"cowlib">>,<<"1.0.1">>})
===> Fetching cowboy ({pkg,<<"cowboy">>,<<"1.0.0">>})
===> Compiling cowlib
===> Compiling ranch
===> Compiling meck
===> Compiling cowboy
===> Compiling myapp`}
</Code>

想要安装特定版本的 Erlang 包？在元组中写入应用程序名称和版本。您可以在Hex 主页浏览软件包的可用版本。

<Code language="shell">
{`{deps, [{cowboy, “1.0.2”}, {meck, "0.8.3"}]}.`}
</Code>

### 列出已安装的软件包

rebar3 deps命令显示本地安装的包：

<Code language="shell">
{`$ rebar3 deps
cowboy (locked package 1.0.0)
meck (locked package 0.8.2)`}
</Code>

### 卸载软件包

要卸载一个包，你必须先从 rebar.config文件中删除它，然后使用命令：rebar3 unlock。在这里，我们从列表中删除了meck包。

<Code language="shell">
{`$ rebar3 unlock
$ rebar3 deps
cowboy (locked package 1.0.0)`}
</Code>

使用 Rebar3 构建您的第一个 Erlang 应用程序

您是否有一个不再需要的 Erlang VM 并且您不知道如何处理它？不用担心，我的朋友，这只是给你的清单！系好你的安全带，进入你的旧冰箱……**我们会撞坏东西的**！

## 好的方法

有几种方法可以很好地关闭 Erlang VM……

### 1. q/0, c:q/0, init:stop/0

正如[文档](https://erldocs.com/current/stdlib/c.html?i=0&search=c:q#q/0)所说，最简单和最干净的方法是使用q/0或c:q/0（实际上是[同一件事](https://github.com/erlang/otp/blob/52c11d5afd18405eaa293bb881eddf23f408850f/lib/stdlib/src/shell_default.erl#L97)）……

> 此函数是 init:stop() 的简写，即它使节点以受控方式停止。

而且[init:stop/0](https://erldocs.com/current/erts/init.html?i=0&search=init:st#stop/0)是……

> 与 stop(0) 相同。

所以，基本上你最终会运行init:stop(0).要了解该命令的作用，让我们再次检查文档：

> 所有应用程序都被顺利关闭，所有代码都被卸载，并且在系统通过调用halt(Status)终止之前关闭所有端口。如果指定了命令行标志-heart，则heart程序在 Erlang 节点终止之前终止。有关详细信息，请参阅[heart(3)](https://erldocs.com/current/kernel/heart.html)。
> 为了限制关闭时间，init允许关闭应用程序的时间，使用命令行标志-shutdown_time。

所以，这可能是最干净的关机形式。但你也可以跳过所有干净的部分，直接跳到……

### 2. erlang:halt/0

正如您在[文档](https://erldocs.com/current/erts/erlang.html?i=0&search=erlang:ha#halt/0)中看到的那样，erlang:halt()与erlang:halt(0, [])。除去下面与erlang:halt/1,2相关的更多内容，现在erlang:halt()只是关闭虚拟机，并没有正确地终止应用程序和正确地关闭端口。

### 3. JCL模式
以前的方法依赖于你能够在 shell 中运行命令（或者远程shell，如果你使用分布式 Erlang的话）。如果你不能这样做，例如，你阻止了你的shell或其他什么？好吧，如果您在要关闭的节点的shell中，即使它没有接收到输入，您仍然可以按**Ctrl-g**（这会将您带到[JCL](http://erlang.org/doc/man/shell.html#id262896) 模式）。在那里，您可以使用命令**q**退出 Erlang shell。

这与效果类似erlang:halt(0).

顺便说一句，这是在不停止原始节点的情况下停止[remsh](http://erlang.org/doc/man/erl.html#id200918)节点的最佳方法。

### 4. BREAK模式
您可以按**Ctrl-c**而不是 **Ctrl-g** 。这将带您进入BREAK 模式，如下所示：

<Code language="shell">
{`BREAK: (a)bort (c)ontinue (p)roc info (i)nfo (l)oaded
 (v)ersion (k)ill (D)b-tables (d)istribution`}
</Code>

您可以做两件事来关闭那里的节点：

- 再次按Ctrl-c。
- 按a然后返回。

他们两个都会表现得像erlang:halt(0).

## 坏的方法

也许您确实想以一种不太好的方式退出系统并生成某种错误报告。这些是您的一些选择，然后……

### 5. erlang:halt/1,2

正如您在文档中看到的那样，有一些选项可以erlang:halt/1,2在输出时产生错误。您可以阅读文档上的选项，但关键部分是：

- 如果您想要一个具有正确退出状态的干净关闭，您可以使用一个整数。
- 如果要生成 erl_crash.dump，请使用字符串作为标语。
- 如果要生成核心转储，请使用原子 abort。

当然，无论您的选择如何，都不会正确终止任何应用程序，也不会正确关闭任何端口等。

### 6. 直接杀死进程

当然，Erlang VM 最终只是你操作系统中的一个进程。而且，如果您的操作系统类似于 UNIX，您可以通过向它们发送信号来终止进程。不同的信号对 Erlang VM 有不同的影响。通常的信号按预期工作：kill -SIGTERM会表现得像init:stop().并且kill -SIGKILL会表现得像erlang:halt(137).（谢谢[Tristan Sloughter澄清](https://medium.com/u/6f8a2f2f35?source=post_page-----7016bd593a5--------------------------------)kill -SIGTERM）。

但是您可以使用另外一个信号 kill -SIGUSR1，在这种情况下生成一个 erl_crash.dump:。在生成的故障转储中，停止原因将是Received SIGUSR1.

## 丑陋的方法

嗯……关闭虚拟机的乐趣在哪里？因为它们应该被关闭？让我们把它们**烧掉**，而不是……

### 7. 不要让它开始

当你启动一个 Erlang VM 时，你可以通过在命令行中指定它们在 shell 启动之前运行命令（例如$ erl -s your_app，即在启动 shell 之前运行your_app:start()）。但是，如果这些命令错误或损坏，会发生什么？💥 VM 崩溃并生成 erl_crash.dump。例如…

<Code language="shell">
{`$ erl -s something_that_doesnt_exist
Erlang/OTP 20 [erts-9.0] [source] [64-bit] [smp:8:8] [ds:8:8:10] [async-threads:10] [kernel-poll:false]
…
init terminating in do_boot ({undef,[{something_that_doesnt_exist,start,[],[]},{init,start_em,1,[]},{init,do_boot,3,[]}]})
Crash dump is being written to: erl_crash.dump...done`}
</Code>

### 8. Kill the Kernel

不管 Erlang 传奇的Let It Crash哲学（又名The Zen of Erlang）如何，Erlang VM 中有一个进程是不允许崩溃的：the application controller。所以，如果你杀了它……

<Code language="shell">
{`$ erl
Erlang/OTP 20 [erts-9.0] [source] [64-bit] [smp:8:8] [ds:8:8:10] [async-threads:10] [kernel-poll:false]
…
1> exit(whereis(application_controller), kill).
true
*** ERROR: Shell process terminated! ***
*** ERROR: Shell process terminated! ***
*** ERROR: Shell process terminated! ***
*** ERROR: Shell process terminated! ***
*** ERROR: Shell process terminated! ***
*** ERROR: Shell process terminated! ***
*** ERROR: Shell process terminated! ***
*** ERROR: Shell process terminated! ***
*** ERROR: Shell process terminated! ***
*** ERROR: Shell process terminated! ***
{"Kernel pid terminated",application_controller,killed}
Kernel pid terminated (application_controller) (killed)
Crash dump is being written to: erl_crash.dump...done`}
</Code>

### 9. 耗尽原子表

Erlang VM 中允许的原子数量巨大且可配置，但仍然有限。使用erlang:system_info/1我们可以确定该限制，当然，利用耗尽原子表您可以轻松生成的很大的 erl_crash.dump 之一（警告：生成 erl_crash.dump 可能需要**很长时间**）：

<Code language="shell">
{`$ erl
Erlang/OTP 20 [erts-9.0] [source] [64-bit] [smp:8:8] [ds:8:8:10] [async-threads:10] [kernel-poll:false]
…
1> [list_to_atom(integer_to_list(I)) || I <- lists:seq(erlang:system_info(atom_count), erlang:system_info(atom_limit))].
no more index entries in atom_tab (max=1048576)
Crash dump is being written to: erl_crash.dump...done`}
</Code>

### 10. 直接关掉你的电脑（哈哈哈）

呵呵，不是这样啦。耗尽进程列表将是我的第 10 种方法，但是当我在 Erlang/OTP 20.1 安装上尝试此方法时，我发现它并没有崩溃。发生了不一样的事情……

原子表并不是 Erlang VM 中唯一受限的东西。另一个是进程数（可+P在命令行上配置）。使用与上面类似的方法，您可以尝试通过创建过多的 Erlang VM 来使它们崩溃，但您会在那里发现一个惊喜……

<Code language="shell">
{`$ erl +P 1024
Erlang/OTP 20 [erts-9.0] [source] [64-bit] [smp:8:8] [ds:8:8:10] [async-threads:10] [kernel-poll:false]
…
1> [spawn(timer, sleep, [60000]) || I <- lists:seq(erlang:system_info(process_count), erlang:system_info(process_limit))].
…`}
</Code>

这不会使虚拟机崩溃，而是会产生无穷无尽的…

<Code language="shell">
{`=ERROR REPORT==== 29-Apr-2018::01:25:51 ===
Error in process <0.52.52> with exit value:
{system_limit,[{erlang,spawn_link,
 [erlang,apply,[#Fun<shell.1.98304428>,[]]],
 []},
 {erlang,spawn_link,1,[]},
 {shell,get_command,5,[{file,"shell.erl"},{line,300}]},
 {shell,server_loop,7,[{file,"shell.erl"},{line,230}]}]}
Eshell V9.0 (abort with ^G)
*** ERROR: Shell process terminated! ***
=ERROR REPORT==== 29-Apr-2018::01:25:51 ===
Too many processes`}
</Code>

机器没有崩溃，但是 shell 进程确实崩溃了，当它尝试重新启动时，嗯……它一次又一次地崩溃。但其他一切都在继续运行。

我希望你喜欢这份清单。如果您认为我错过了其他一些使 Erlang VM 崩溃的方法，请在下面的评论中告诉我！: )

停止 Erlang VM 的 10 种方法

作为用 Erlang 编写的网络模拟器的一部分，我通常会遇到很多关于由于对非常大的代码库维护不当而导致的性能和内存泄漏的问题。我们在一个 Linux 机器上启动了近 250 多个 Erlang 节点来模拟大约 500 到 1000 多个电信节点。

通过静态检查代码来查找内存泄漏是一项非常困难的任务。相信我，我发现在运行时本身很容易找到内存泄漏。

> 什么是内存泄漏? 从一般操作系统的角度来看，一些已分配但未使用的内存，就是内存泄漏。从 Erlang 的角度来看，Erlang 缺少内存，总是向操作系统请求内存（它应该很丰富）。如果分配的内存没有被 Erlang 正确使用，我们称之为内存泄漏。

## 内存分配

当应用程序运行时，它会从操作系统中获得足够的 RAM。运行应用程序的 erlang VM 同样负责在不使用时归还该内存。但并非每次都如此，尤其是大型代码库、大型应用程序且维护不善时。

## 识别内存泄漏

当您在 Erlang 节点上启动应用程序时，它通常会从操作系统消耗一些“x MB”的 RAM。您可以使用“top”命令查看 RAM 消耗，如下所示。

<Code language="shell">
{`top -p <beam PID>`}
</Code>

RSS 字段给出了驻留内存大小，即最小 RAM 消耗，而 Virt 字段给出了当前运行时 RAM 消耗。

如果您在用例执行之前和之后记录这些值。它应该几乎是一样的。当我说几乎时，这意味着您可以预期这些值会略有增加，因为您的用例可能会将一些值添加到 ETS 或 Mnesia(ram_copies) 中，这些值很可能存储在 RAM 中，并且可能会略微增加消耗。

## 分析

现在，即使在用例完成后，如果您发现 RAM 利用率有很大差异（在我的情况下 > 20MB）。让我们的冒险从这里开始：

使用 erlang:memory() 在用例运行前后获取RAM使用的快照。

> erlang:memory() 函数为您提供以字节为单位的内存利用率，如 ets、atom、binary、proc_memory 等，应检查每个数据类型在用例后是否增加。您可以立即怀疑 ETS、二进制、atom_table 和进程内存。

## 一些可能对我们有帮助的功能

要查找所有进程内存，请使用以下命令：

<Code language="erlang">
{`[io:format(“~p:~p: ~p~n”,[Pid,erlang:process_info(Pid,current_function),erlang:process_info(Pid,memory)])||Pid<-erlang:processes()].`}
</Code>

要查找所有 ets 表内存和条目，请使用以下命令：

<Code language="erlang">
{`[io:format(“~p -> ~p: ~p mem ~p ~n”,[E,ets:info(E,name),ets:info(E,size),ets:info(E,memory)])||E<-ets:all()],calendar:local_time().`}
</Code>

有时你可能需要查找 message_queue_len，使用如下：

<Code language="erlang">
{`[io:format(“~p:~p: Q:~p ~p~n”,[Pid,erlang:process_info(Pid,current_function),erlang:process_info(Pid,message_queue_len),erlang:process_info(Pid,memory)])||Pid<-erlang:processes()].`}
</Code>

我们还可以添加一些排序功能来对上述结果的结果进行排序。但我并不是保持一个干净的类型，我总是喜欢浏览整个结果以寻找更多线索。

在上述情况下，如果你仔细观察，我尝试将每个进程的当前函数连同内存一起打印出来。这个 current_function 很可能是高内存消耗进程的蜜罐，您可以从中开始调查。我可以很容易地向您保证，这种内存泄漏情况很可能就会在该函数周围。

> 快速解决方法：
> 在您发现/怀疑内存泄漏的代码中添加 erlang:garbage_collect(self()) 将是检查/修复内存泄漏的最快方法。
> 但这确实不是一个好的解决方法。更频繁地使用garbage_collect 会占用CPU。相反，我们应该尝试修复代码。

一些内存泄漏案例：

案例 1：如果您的应用程序中有自己的跟踪机制，并且您的应用程序总是为您格式化一个很好的跟踪信息，但仅在启用跟踪时才打印它们。这可能形成了内存泄漏。

案例2：假设我们有一个函数“A”，里面有一个接收循环，函数“B”有一个接收循环，如果你在函数“B”的接收循环中调用这个函数“A”。进入此接收循环的任何数据都无法找到进行garbage_collection 的方式。

案例 3：我还发现 gen_event 行为中的 fetch_msg 函数会保留一些内存，但我们只能在大块数据分配时看到。

在Erlang应用程序中查找内存泄漏

## 概述

在本教程中，我将介绍作为 Erlang 开发人员在日常生活中使用最多的工具。入选的所有或大部分工具都具有以下特征：

- 它们是专门为 Erlang 构建的（即没有文本编辑器，没有 git 等）。
- 它们不是为特定类型的应用程序量身定制的（即您可以使用它们来开发任何类型的 Erlang 应用程序）。

## 在Shell中工作

与许多其他语言一样，与 Erlang VM 交互的最常见方式是通过 Erlang shell。您可以使用它来测试代码、学习如何使用 Erlang 以及调试生产系统。Erlang shell 是一个强大的东西，但是您可以使用下面我将向您展示的三个工具来为其添加更多功能。

### 1. [user_default](http://erlang.org/doc/man/erl.html#id191234)

一般来说，要在 Erlang 中评估模块之外的函数，您必须在它们的名称前面加上相应的模块名称。例如，如果要汇总一个列表，则必须执行以下操作：

<Code language="erlang">
{`1> lists:sum([1, 2, 3]).
6
2>`}
</Code>

但是您会注意到，对于 shell 中的某些函数，您不需要显式定义。例如：

<Code language="erlang">
{`1> c(your_module).
{ok,your_module}
2> h().
1: c(your_module)
-> {ok,your_module}
ok
3> e(1).
{ok,your_module}
4>`}
</Code>

这些功能在哪里？它们在[shell_default](https://github.com/erlang/otp/blob/maint/lib/stdlib/src/shell_default.erl)模块中定义。您也可以添加自己的默认函数。为此，您必须创建并加载一个名为user_default. 例如，我喜欢在使用 Erlang shell 时运行 bash 命令；我不想只是为了复制文件就离开shell。Erlang/OTP 为您提供了一个函数来执行此操作：os:cmd/1，但这不会打印出您的命令的输出。相反，此命令将输出作为字符串返回。您必须打印字符串才能正确查看输出。

因此，使用user_default，我将以下行添加到我的user_default.erl文件中：

<Code language="erlang">
{`-module(user_default).
-export([cmd/1].

cmd(Cmd) -> io:format("~s~n", [os:cmd(Cmd)]).`}
</Code>

现在我可以在shell中运行、执行和打印os:cmd/1的结果：

<Code language="shell">
{`1> c(user_default).
{ok, user_default}
2> cmd("cat user_default.erl").
-module(user_default).
-export([cmd/1].

cmd(Cmd) -> io:format("~s~n", [os:cmd(Cmd)]).

ok
3>`}
</Code>

### 2. [~/.erlang](http://erlang.org/doc/man/erl.html#id191234)

但是，我必须在我打开的每一个shell中手动加载user_default。~/.erlang可以解决这种状况！~/.erlang是一个与bash中的~/.bashrc一样工作的文件。启动时，shell 读取~/.erlang并执行其中找到的每个表达式，就好像它们被输入到 shell 一样。

因此，我在该文件中添加了以下几行：

<Code language="shell">
{`UD = "/path/to/my/user_default".
2shell_default:c(UD).`}
</Code>

我的~/.erlang实际上比这个更复杂，但是shell_default应该给你了要修改的要点。现在，我打开的每个 shell 都支持cmd/1.

### 3. [erlang-history](https://github.com/ferd/erlang-history)
 Erlang shell 中最烦人的事情之一是它不能很好地跟踪命令历史。事实上，默认设置会在关闭 shell 时清除所有命令历史记录。我已经看到许多开发人员通过使用一个记录本来记录 erlang 表达式解决此限制，他们每次都从中复制并粘贴到控制台中。（他们中的一些人使用user_default and/or ~/.erlang。）

但是，这仍然不是一个真正的解决方案，对吧？为了正确解决这个问题，在安装新版本的 Erlang/OTP 之后，我安装了erlang-history。这是对 Erlang/OTP 发行版的一个非常微小的几乎看不见的 hack，其目的很简单：跟踪您以前在 Erlang shell 中的命令并让您重用它们。简单，但非常有用。

## 管理应用程序

一旦您跳过简单的示例并进入 OTP 应用程序的领域，使用可以帮助您组织代码、管理依赖项、构建版本、运行测试等的构建工具会更好。

使用 Erlang 时，您可以接受Makefile或尝试尽可能远离它。

### 4. [erlang.mk](https://erlang.mk/)

如果使用 Makefiles 构建和管理您的项目对您来说很自然，您可能会喜欢erlang.mk。erlang.mk基本上是一个大的 Makefile 脚本，您可以将其包含在您自己的 Makefile 中，例如：

<Code language="shell">
{`PROJECT=your_app
include erlang.mk`}
</Code>

这样，您就可以访问许多命令，例如

- $ make 构建你的项目
- $ make tests 运行你的测试套件
- $ make rel 生成发布

您可以使用$ make help找到整个列表，当然，您可以通过扩展您的 Makefile 来添加更多。

erlang.mk还提供了一个插件基础设施，您可以在其中添加构建工具，例如[hexer.mk](https://github.com/inaka/hexer.mk)或[elvis.mk](https://github.com/inaka/elvis.mk)。

更好的一点erlang.mk为构建几乎所有现有的 Erlang 库提供了必要的支持，无论库所有者使用什么工具来维护它。您可以在您的存储库erlang.mk中包含使用rebar、rebar3、erlang.mk（和预期的一致：P）、 ad-hoc Makefiles和其他构建的应用程序。您可以从github、hex.pm、bitbucket、您的本地文件系统和许多其他地方下载依赖。显然erlang.mk使 Erlang 更加通用。

### 5. [rebar3](http://www.rebar3.org/)

现在，如果 Makefile 不是你的菜，并且你更喜欢使用由 Erlang/OTP 团队赞助的官方构建工具（自 2016 年 3 月起），那么rebar3就是你的选择。

**rebar3完全用 Erlang 编写**，其想法是您可以在不向项目中添加任何 Makefile 的情况下使用它。

将其安装到系统中后，您应该在项目的根文件夹中添加一个rebar.config文件。一个最小化范例看起来像这样（尽管下面的选项也是可选的）：
<Code language="erlang">
{`{deps, []}.
{erl_opts, [debug_info]}.
{cover_enabled, true}.`}
</Code>

您可以在此处找到您可以指定的所有选项的列表。然后，您可以在 shell 中运行如下命令：

- $ rebar3 compile 获取 deps 并构建您的项目
- $ rebar3 ct 运行你的测试
- $ rebar3 release 生成发布

当然，$ rebar3 help会为您提供所有可用命令的列表。而且，就像erlang.mk,rebar3也可以通过plugins进行扩展。

最好的事情之一是，rebar3通过使用rebar.lock，它提供了可重复的构建。这样，一旦您确定您的项目按预期工作，您就可以确保无论您编译多少次或在多少个不同的地方编译它，它都会按预期工作。

## 确保代码质量

我个人已经在网上（在[采访](https://www.functionalgeekery.com/functional-geekery-episode-43-brujo-benavides/)和博客文章中）多次说过保持高质量代码的重要性（尤其是在你从事开源项目的情况下）。Erlang 附带了几个工具可以帮助你解决这个问题。Erlang 工具甚至可以帮助您检测在运行时可能会发现的错误……无需运行您的系统！

### 6. [dialyzer](http://erlang.org/doc/man/dialyzer.html)
**Dialyzer**是一个静态分析工具，可以帮助您识别代码中的类型不一致，例如，当您将 binary()作为参数传递给需要string()的函数时。这曾经是一个非常非常慢的工具，但它已经被高度优化，现在运行流畅，特别是如果你经常运行它。此外，它还集成在[rebar3](https://www.rebar3.org/docs/commands#dialyzer)和[erlang.mk](https://erlang.mk/guide/dialyzer.html)。

如果您使用dialyzer( dia.erl)，您将看到如下所示的结果。

<Code language="shell">
{` Checking whether the PLT dia.plt is up-to-date... yes
 Proceeding with analysis...
 compile (+0.09s): 0.02s ( 1 modules)
 clean (+0.00s): 0.00s
 remote (+0.00s): 0.18s
 order (+0.00s): 0.00s
 typesig (+0.12s): 0.01s ( 3 SCCs)
 order (+0.00s): 0.00s
 refine (+0.00s): 0.01s ( 1 modules)
 warning (+0.00s): 0.00s ( 1 modules)
 (+ 0.71s)

dia.erl:5: Function bad/0 has no local return
dia.erl:5: The call lists:flatten(<<_:168>>) will never return since it differs in the
1st argument from the success typing arguments: ([any()])
done in 0m1.16s
done (warnings were emitted)`}
</Code>

在这个例子下，dia.erl的第5行，我们使用 168 位长的二进制 ( &lt&lt_:168&gt&gt)对lists:flatten/1进行调用，而该函数需要一个列表 ( [any()]) 作为其参数。这个警告不是在编译时引发的，但是使用dialyzer你可以在它运行时发生错误之前找到它。

### 7. [xref](http://erlang.org/doc/man/xref.html)

Erlang/OTP 发行版中包含的一个更简单的工具是xref. xref是一种交叉引用工具，可以分析您的代码并查找对不存在的函数、已弃用的函数和其他类似事物的调用。它不像dialyzer那样深入搜索，但它会立即发现明显的错误。

xref还与[rebar3](https://www.rebar3.org/docs/commands#xref)和[erlang.mk](https://erlang.mk/guide/xref.html)（文档还没有，但它用[xref_runner](https://github.com/inaka/xref_runner)检查您的代码）集成。

xref可以找到如下错误 

<Code language="shell">
{`…
===> Running cross reference analysis...
===> Warning: your_module:your_function/1 calls undefined function this_function:doesnt_exist/1 (Xref)
…`}
</Code>

xref检测到我们正在调用一个不存在于代码中的函数your_module:your_function/1。同样，这是编译器不会警告您的事情。

### 8. [elvis](https://github.com/inaka/elvis)
除了使用xref、dialyzer分析代码查找错误外，您还可以确保项目中的代码是可维护的。elvis是一个命令行工具（以及 Erlang 应用），您可以使用它来验证您的代码是否符合您在elvis.config文件中预先定义的某些样式规则。分别存在对应[rebar3](https://github.com/project-fifo/rebar3_lint)和[erlang.mk](https://github.com/inaka/elvis.mk)的插件。 您还可以[在线使用elvis](http://elvis.inakalabs.com/)来检查您的 github 拉取请求。

它的输出如下所示：
<Code language="shell">
{`Loading files...
Loading src/dia.erl
Applying rules...
# src/dia.erl [FAIL]
- no_tabs
 - Line 33 has a tab at column 0.`}
</Code>

在这种情况下，elvis 正在检测用于缩进的制表符的使用，这是在项目elvis.config文件中指定为无效的内容。

## 调试

下一组工具假设您已经创建了应用程序，将其打包为一个release，并将其部署到某个服务器。还假设该应用程序已经运行了一段时间，但已经开始出现异常行为。所以你需要调试它。

首先，您使用[远程 shell](http://erlang.org/doc/man/erl.html#id186912)连接到您的服务器（请参阅-remsh命令的链接）。然后，您使用 Erlang 的[dbg](http://erlang.org/doc/man/dbg.html)。

唉，**dbg**不是一个非常直观、简单的调试工具。它真的很强大，但是手头的任务有更简单的工具。我将在下面向您展示其中的 2 个。

### 9. [redbug](https://hex.pm/packages/eper)
redbug是一个调试应用程序，它与dbg非常相似，但具有更直观的界面。它与eper一起提供，但老实说，redbug是eper中我唯一用过组件。您可以将跟踪模式指定为字符串，并且每次运行与该模式匹配的函数调用时，它将在控制台中打印一条消息。它看起来像这样：
<Code language="erlang">
{`1> redbug:start("your_module:your_private_function->return").
{156,1}
2> your_module:your_public_function().
% 19:55:12 <0.1.0>({erlang,apply,4})
% your_module:your_private_function(some, parameters)

% 19:55:12 <0.1.0>({erlang,apply,4})
% your_module:your_private_function/2 -> ok
ok
3>`}
</Code>

我实际上倾向于在开始使用redbug时总是使用相同的选项。您可以使用redbug:help()检查可用的启动选项。因此，我已将此启动代码添加到我的[user_default](https://www.pluralsight.com/guides/10-essential-erlang-tools-for-erlang-developers#1-a-href-http-erlang-org-doc-man-erl-html-id191234-target-_blank-user_default-nbsp-span-class-glyphicon-glyphicon-new-window-aria-hidden-true-style-font-size-10px-span-a-) 中（不要在生产中这样做，孩子们！！）

<Code language="erlang">
{`redbug(What) ->
 catch redbug:stop(),
 timer:sleep(100),
 redbug:start(What, [{time, 9999999}, {msgs, 9999999}, {print_msec, true}]).`}
</Code>

现在我可以轻松上手redbug了。

<Code language="erlang">
{`4> redbug("your_module:your_private_function->return").
{156,1}
5> your_module:your_public_function().
% 19:59:13 <0.1.0>({erlang,apply,4})
% your_module:your_private_function(some, parameters)

% 19:59:13 <0.1.0>({erlang,apply,4})
% your_module:your_private_function/2 -> ok
ok
6>`}
</Code>

### 10. [recon](https://hex.pm/packages/recon)

但是跟踪函数调用只是检查 Erlang 服务器健康状况的众多方法之一。Fred Hebert在处理这个问题积累了大量经验，产出了一本很棒的书（ [Stuff Goes Bad: Erlang In Anger](https://www.erlang-in-anger.com/)）和一个很棒的工具：[recon](https://ferd.github.io/recon/)。

使用**recon**你可以做很多事情，你可以：跟踪函数调用（就像redbug），恢复编译模块的源代码，检查应用程序内存消耗，计算消息队列长度，清理二进制内存，查找泄漏等等。我强烈建议您阅读这本书并尝试使用其中recon描述的不同工具。如果您的服务器开始出现异常行为，您将需要牢记它们。

## 奖励曲目

现在有些并不真正适合上面的列表，但无论如何都值得一提。

### 11. [Meta Testing](https://github.com/inaka/katana-test)

如果你使用 TDD（即使你只是使用[通用测试](http://erlang.org/doc/man/common_test.html)来测试你的 Erlang 应用程序并且你有兴趣使用我上面提到的工具来维护你的[代码质量](https://www.pluralsight.com/guides/10-essential-erlang-tools-for-erlang-developers#ensuring-code-quality)），你必须应用[katana-test](https://github.com/inaka/katana-test)。使用下面的代码，你会在每次运行测试时都对代码进行dialyzer、xref和测试。

<Code language="erlang">
{`-module(your_meta_SUITE).

-include_lib("mixer/include/mixer.hrl").
-mixin([ktn_meta_SUITE]).

-export([init_per_suite/1]).

init_per_suite(Config) -> [{application, your_app} | Config].`}
</Code>

我称之为Meta Testing，我已经写了两篇关于它的博客文章。在这里和这里查看它们。

### 12. 社区

如果不向背后的伟大开发者社区大声疾呼，任何关于Erlang的伟大的事物列表都是不完整的。如果您打算在 Erlang 上工作，或者即使您只是接触该语言并且想知道它的全部内容，那么您必须与 erlangers交流。

有几种方法可以做到这一点：

- erlang-questions 邮件列表是最流行的，可以说是社区的官方交流媒介。是的，它是一个邮件列表。它不会像垃圾邮件一样填满您的收件箱。
- 我们在freenode上也有一个IRC 房间，在 Slack 上有一个服务器，我们经常在那里交流。
- 你也可以在ErlangCentral上找到我们中的一些人。

如果您对 Erlang 开发很认真，请密切关注这些平台并与我们保持联系以获取更新和其他机会！

### 13. [Guidelines](https://github.com/inaka/erlang_guidelines)

最后，我想提一下 Inaka在 github 上发布的 [Erlang 指南](https://github.com/inaka/erlang_guidelines)。正如我在第一次谈论它们时在[邮件列表](http://erlang.org/pipermail/erlang-questions/2014-September/080935.html)中所说的那样：

> [erlang_guidelines](https://www.pluralsight.com/guides/10-essential-erlang-tools-for-erlang-developers)是我们（在 Inaka）在我们的 Erlang 代码中强制执行的一组标准。 …… 它只会反映在 Inaka 工作的〜8 erlangers 的想法。我们接受贡献，因为我们喜欢良好和建设性的辩论，但我们不希望任何人……喜欢我们的[指导方针](https://www.pluralsight.com/guides/10-essential-erlang-tools-for-erlang-developers)🙂

换句话说，关于那个 repo 的指导方针不需要成为你的指导方针，但你应该有自己的指导方针。fork那个 repo，然后根据你的想法调整它的内容可能是一个很好的开始方式。其他人已经这样做了。正如[Iñaki](https://twitter.com/iraunkortasuna)曾经解释的那样：

> 代码格式、间距、布局和 “使代码看起来不错”**并不是**制定指南的目标。类似地，这个想法不是要参与其中每个人都被迫做他们不想做的事情的束缚计划，而是要有一个秩序和商定条款的基线。 达成共识并遵循它的目的是**释放能量**，而不是消耗它来支持定义不明确或主观的目标，例如“看起来更好”。让每个人制定他/她自己的规则“而该死的”就像强迫每个人遵守严格的指导方针一样反社会，这些指导方针规定了逗号或空格的放置位置。纪律为团队提供了自由，因为一旦你在一件事情上达成共识，处理他人过犯的努力比防止自己过犯的努力更大。 行长限制等问题是达到目的的一种手段：它们使代码更容易更改、调试和扩展，以更快地响应需求更改。要同意这一点，必须承认编程是一项社会活动，并且适用于群体行为。此时为您编写可能更容易，但其他人将不得不阅读它。这是代码指南的唯一目标。

希望本指南能够解决您可能遇到的有关基于 Erlang 的应用程序开发的一些问题，并激发您对创建 Erlang 应用程序的兴趣！感谢您的阅读。

Erlang 开发者必备的 10 个工具

## 对防御性编程风格的思考

正确的 Erlang 用法要求您不要编写任何类型的防御性代码。这称为意图编程（intentional programming）。您为预期代码采用的意图控制流路径编写代码。而且您不会为您认为不可能的路径编写任何代码。此外，您不会为数据流编写代码，这不是程序的意图。

## 这是一个愚蠢的效果

如果 Erlang 程序出错，它就会崩溃。假设我们正在打开一个文件。我们可以像这样进行文件打开调用：

<Code language="erlang">
{`{ok, Fd} = file:open(Filename, [raw, binary, read, read_ahead]),`}
</Code>

如果文件不存在会怎样？好吧，这个过程崩溃了。但请注意，我们不必为该路径编写任何代码。Erlang 的默认设置是在匹配无效时崩溃。我们收到错误匹配错误，原因是我们无法打开文件。

进程崩溃不是问题。该程序仍在运行和监督（Erlang 中一个重要的容错概念），将确保我们稍后再试一次。假设我们偶然在文件打开时引入了竞争条件。如果它很少发生，即使文件打开不时失败，程序仍然会运行。

您经常会看到如下代码：

<Code language="erlang">
{`ok = foo(...),
ok = bar(...),
ok = ...`}
</Code>

然后断言这些调用中的每一个都运行良好，如果控制和数据流不是预期的，确保代码崩溃。

请注意这完全缺乏错误处理。我们不写以下代码

<Code language="erlang">
{`case foo(...) of
 ok -> case bar(...) of ... end;
 {error, Reason} -> throw({error, Reason})
end,`}
</Code>

并且我们也不会落入 Go 编程语言的陷阱，并写下如下代码：

<Code language="go">
{`res, err := foo(...) 
if err != nil { 
 panic(...) 
} 
res2, err := bar(...) 
if err != nil { 
 panic(...) 
}`}
</Code>

因为这也很愚蠢，写起来既乏味又麻烦。

关键是我们在 Erlang 解释器中有一个崩溃效果，我们可以调用它，如果出现问题，默认是崩溃进程，并清理另一个进程。好的 Erlang 代码尽可能多地使用了这个事实。

## 故意的？

注意故意这个词。在某些情况下，我们确实希望调用失败。所以我们只是像其他人一样处理它，但是由于我们可以在 Erlang 中模拟 sum-types，我们可以比没有 sum-type 概念的语言做得更好：

<Code language="erlang">
{`case file:open(Filename, [raw, read, binary]) of
 {ok, Fd} -> ...;
 {error, enoent} -> ...
end,`}
</Code>

在这里，我们写下了该文件可能不存在的意图。然而：

- 我们**只**担心文件不存在。
- 如果我们在eaccess上崩溃，这意味着由于权限导致的访问错误。
- eisdir 、enotdir、enospc 也是如此。

## 为什么？

更精简的代码，这就是原因。

我们可以跳过很多防御性代码，这些代码通常会使项目的代码大小减少一半以上。需要维护的代码要少得多，因此当我们重构时，我们也需要操作更少的代码。

我们的代码没有与“正常”代码流无关的乱七八糟的东西。这使得阅读代码和确定发生了什么变得容易得多。

Erlang 进程崩溃会在某些东西死亡时提供大量信息。对于正确的 OTP 进程，我们会在进程死亡之前获取进程的状态以及发送给它的触发崩溃的消息。在大约 50% 的情况下，这样的转储就足够了，您只需查看故障转储即可重现错误。实际上，这消除了许多愚蠢的日志记录代码。

## 数据流防御性编程

另一种弄乱 Erlang 程序的常见方法是通过模式匹配来破坏传入的数据。像下面这样的东西：

<Code language="erlang">
{`convert(I) when is_integer(I) -> I;
convert(F) when is_float(F) -> round(F);
convert(L) when is_list(L) -> list_to_integer(L).`}
</Code>

该函数会将“任何东西”转换为整数。然后你继续使用它：

<Code language="erlang">
{`process(Anything) -> I = convert(Anything), ...I...`}
</Code>

这里的问题不在于流程功能，而在于流程功能的调用点。每个调用点对该代码中传递的数据有不同的看法。这导致每个子系统都处理此类转换的情况。

这种反模式有几种伪装。这是另一种味道：

<Code language="erlang">
{`convert({X, Y}) -> {X, Y};
convert(B) when is_binary(B) ->
 [X, Y] = binary:split(B, <<"-">>),
 {X, Y}.`}
</Code>

这是字符串化编程，其中所有数据都被推入一个字符串，然后在每个调用者处手动解构。这会导致很多丑陋的代码，以后几乎没有扩展性。

与其尝试处理不同的类型，不如在 api 早期强制执行不变量：

<Code language="erlang">
{`process(I) when is_integer(I) -> ...`}
</Code>

然后永远不要在子系统内部测试正确性。dialyzer擅长推断I作为整数的用途。**使用is_integer守卫**进行测试会搞乱你的代码，并且不会带来任何好处。如果你的子系统有问题，代码会崩溃，你可以去处理错误。

这里有一些关于静态类型的东西要说，它会让你很容易地离开这个统一的世界。在静态类型语言中，我仍然可以获得相同的东西，但是我必须按照 (* Standard ML code follow *) 的方式定义一些东西。

<Code language="erlang">
{`datatype anything = INT of int
 | STRING of string
 | REAL of real`}
</Code>

像这样，很快就变得难以为其编写模式匹配，因此人们只在真正需要时才定义任何类型。（Gilad Bracha 认为对值（value）进行运行时检查是部分正确的，但他忽略了一个事实，即程序员应避免昂贵的运行时检查——一次又一次，Gilad ☺）。

## 未定义（undefined）造成的祸害

另一个重要的坏代码味道是未定义值。通常的场景是使用 undefined 编写 Option/Maybe monad。也就是说，我们有类型

<Code language="erlang">
{`-type option(A) :: undefined | {value, A}.`}
</Code>

[静态化地看待这个问题：Erlang确实有一个基于成功类型的类型系统来找出错误，上面就是这样一种类型定义]

将反射/具体化定义为这些的异常效果很简单。Jakob Sievers [stdlib2](https://github.com/cannedprimates/stdlib2/blob/master/src/s2_maybe.erl) 库已经做到了这一点，并定义了称为**do**的 monadic 助手（尽管 monad 是Error-Type而不是Option）。

但我见过以下代码：

<Code language="erlang">
{`-spec do_x(X) -> ty() | undefined
 when X :: undefined | integer().
do_x(undefined) -> undefined;
do_x(I) -> ...I....`}
</Code>

这导致复杂的代码。您需要 100% 控制哪些值可以失败，哪些值不能。像上面这样的结构会默默地传递 undefined 。这有它的用途——但是当你看到这样的代码时要小心。未定义的值本质上是NULL。这些是 C.A.R Hoare 犯下的十亿美元级的错误。

问题是上面的代码是可以为空的。Erlang 的默认设置是你永远不会有类似 NULL 的值。再次引入它们应该谨慎使用。您将不得不仔细考虑，因为一旦一个值可以为空，您就需要一直检查它。这往往会使代码错综复杂。最好预先测试这些东西，然后尽可能将其排除在代码库的主要部分之外。

## “开放”的数据表示

每当您拥有数据结构时，就会有一组模块了解并操作该数据结构。如果只有一个模块，您可以模拟标准 ML 或 OCaml 的通用模式，其中具体的数据结构表示对于大多数程序来说是抽象的，并且只有一个模块可以对抽象类型进行操作。

这在 Erlang 中并不完全正确，任何人都可以内省任何数据。但是保持这种错觉对于可维护性很方便。

可以操作数据结构的模块越多，更改该数据结构的难度就越大。将记录放入头文件时请考虑这一点。可能的问题有两个级别：

- 您将record定义放在src的头文件中。在这种情况下，只有应用程序本身可以看到记录，因此它们不会泄漏。
- 您将record定义放在头文件的include中。在这种情况下，记录可能会从应用程序中泄露出来，而且经常会泄露出去。

一个很好的例子是 HTTP 服务器cowboy，它的请求对象通过**cowboy_req**模块进行操作。这意味着内部表示可以改变，同时保持其他地方在模块 API 上的稳定。

在某些情况下，导出record是有意义的。但在这样做之前请三思。如果一条记录由多个模块操作，那么通过重新考虑程序的结构，您很可能会收获更多。

## true、false和原子类型

最后一点，我经常看到这样的代码：

<Code language="erlang">
{`f(X, Y, true, false, true, true),`}
</Code>

这很难阅读。由于这是 Erlang，您可以为真值（true）和假值（false）使用更好的名称。只需选择一个有意义的原子，然后生成该原子。如果参数被意外交换，它还具有尽早捕获更多错误的优势。另请注意，您可以通过传递元组将信息绑定到结果。关于布尔盲的概念有很多话要说，在典型的程序中意味着过度依赖 boolean() 值。问题是，如果你得到一个真实的说法，你不知道为什么它是真的。你需要关于其真实性的证据。这可以通过在一个元组中传递这个证据来实现。例如，我们可以有这样的函数：

<Code language="erlang">
{`case api:resource_exists(ID) of
 true -> Resource = api:fetch_resource(ID), ...;
 false -> ...
end.`}
</Code>

但我们也可以用更直接的方式来写它：

<Code language="erlang">
{`case api:fetch_resource(ID) of
 {ok, Resource} -> ...;
 not_found -> ...
end.`}
</Code>

从长远来看，这不太容易出错。我们不能偶然调用fetch_resource函数，如果我们查找资源，我们也会获得资源是什么的证据。如果我们真的不想使用资源，我们可以把它扔掉。

## 结束语

经验法则有被打破的情况。所以某些情况下，他们必须被打破。但是，如果您碰巧来到这里，我希望您学到了一些东西或者不得不停下来思考一些事情。成为一个更好的程序员的方法是学习别人的风格。

Erlang 和代码风格

像我这样谈论 Dialyzer 这样出色的工具的缺点或局限性不太寻常。 尽管如此，今天我还是发现了一些非常死板的代码块，它们通过了Dialyzer的类型分析。

所以，既然万圣节快到了，让我们从它的坟墓里拿出一些死代码吧！

## Dialyzer 产生警告的时候

在以前我见过这样的代码……

<Code language="erlang">
{`warn(X) ->
 {just, X};
warn(6) ->
 {six, 6}.`}
</Code>

可以触发如下所示的编译器和 Dialyzer 的警告……

<Code language="shell">
{`===> Compiling my_app
src/el.erl:8: Warning: this clause for warn/1 cannot match because a previous clause at line 6 always matches
===> Dialyzer starting, this may take a while...
…
src/el.erl
Line 8: The pattern 6 can never match since previous clauses completely covered the type any()`}
</Code>

非常好！ 该函数中的第二个子句显然是死代码（即，它永远不会被运行），因为 6 匹配 X，因此当作为输入提供时会通过第一个子句进行匹配。 这是我最喜欢的Dialyzer警告之一。 它清晰且可操作。 它提供了包含行号和其他内容的适当上下文。 这非常棒。

## Dialyzer 不产生警告时的时候

但是今天我发现了一段非常非常相似的死代码（dead code），然而Dialyzer 和 Compiler 都对它完全保持沉默。 让我演示给你看…

<Code language="erlang">
{`warn(X, X) ->
 {just, X};
warn(6, 6) ->
 {six, 6}.`}
</Code>

你看出区别了吗？
让我再给你看一个例子……

<Code language="erlang">
{`warn(X, Y) ->
 {just, X and Y};
warn(6, 6) ->
 {six, 6}.`}
</Code>

这确实会产生预期的警告……

<Code language="shell">
{`===> Compiling my_app
src/el.erl:8: Warning: this clause for warn/2 cannot match because a previous clause at line 6 always matches
===> Dialyzer starting, this may take a while...
…
src/el.erl
Line 8: The pattern <6, 6> can never match since previous clauses completely covered the type <_,_>`}
</Code>

## 这到底是怎么回事呢？

嗯……似乎不是每个无法匹配的子句都可以被编译器或 Dialyzer 检测到。 可悲的是，那些包含有界变量（如 warn/2 中的第二个 X）或守卫或任何其他语义结构的变量超出了这些检测工具的范围。

所以，如果你有这样的功能，编译器和 Dialyzer 就不会检测到你的死代码，它最终可能会像幽灵一样生活很长很长一段时间。

好吧，在那种情况下，你会呼叫谁呢？

当然是测试覆盖率（**Test Coverage**）！

如果您制定了良好的测试覆盖率政策（也许像Inakos有我们要求 100% 覆盖所有地方的地方，也许是稍差的一个），你应该立即看到没有测试可以覆盖这些条目。 然后，您可以删除它们。

## 奖励

在撰写本文时，我检查了其他几个场景，看看哪些是可检测的，哪些是不可检测的。 您可以在下面看到我编写的模块…

<Code language="erlang">
{`-module(el).

-export([warn/2, warn_case/1]).
-export([clean/2, clean_case/1]).

warn(X, Y) ->
{just, X and Y};
warn(6, 6) ->
{six, 6}.

warn_case(X) ->
{_, X} =
if X == 6 ->
{six, 6};
is_integer(X) andalso X == 6 ->
{also_six, 6};
true ->
{other, X};
true ->
{yet_another, X}
end,
case X of
_ ->
{just, X};
6 ->
{six, 6};
X ->
{other, X}
end.

clean_case(X) ->
case X of
X ->
{just, X};
X when X == 6 ->
{six, 6};
6 ->
{still_six, 6};
X when X == 6 ->
{six_again, 6};
X ->
{other, X}
end.

clean(V, V) ->
{same, V};
clean(X, Y) when X == Y ->
{also_same, X};
clean(6, 6) ->
{six, 6};
clean(X, Y) ->
case {X, Y} of
{V, V} ->
{same, V};
{X, Y} when X == Y ->
{also_same, X};
{6, 6} ->
{six, 6};
{X, Y} ->
{other, X, Y}
end.`}
</Code>

这些是我得到的唯一警告……

<Code language="shell">
{`===> Analyzing applications...
…
===> Compiling lapp
src/el.erl:8: Warning: this clause for warn/2 cannot match because a previous clause at line 6 always matches
src/el.erl:19: Warning: this clause cannot match because a previous clause at line 17 always matches
src/el.erl:25: Warning: this clause cannot match because a previous clause at line 23 always matches
src/el.erl:27: Warning: this clause cannot match because a previous clause at line 23 always matches
===> Dialyzer starting, this may take a while...
…
src/el.erl
Line 8: The pattern <6, 6> can never match since previous clauses completely covered the type <_,_>
Line 19: The pattern <> can never match since previous clauses completely covered the type <>
Line 25: The pattern 6 can never match since previous clauses completely covered the type any()
Line 27: The variable _ can never match since previous clauses completely covered the type any()`}
</Code>

如果您发现更多值得一提的场景，请在下面写下关于它们的评论。

Erlang的万圣节👻（ Dialyzer 无法找到的dead code）

## 如何进行诊断

几天前，NextRoll 发布了 rebar3_hank，这是一个“强大而简单的工具，可以检测 Erlang 代码库周围的死代码”。在他们的原始帖子中，作者提到了 rebar3_hank 和 Erlang LS 提供的一些功能之间的重叠，例如检测未使用的包含文件。

对这个新工具很感兴趣，我决定深入研究它，检查 rebar3_hank 是否可以与 Erlang LS 中的诊断框架集成，以避免在 Erlang 社区内重复工作。

rebar3_hank 和 Erlang LS 都基于源代码创建诊断，但有一些区别。例如，rebar3_hank 作用于整个项目的代码库，而 Erlang LS 作用于单个 Erlang 模块及其严格的依赖关系。此外，rebar3_hank 旨在通过 rebar3 插件用作 CLI，而 Erlang LS 是通过 LSP 协议与您的 IDE 集成的服务器。

很明显，两个工具之间的集成需要一定程度的重构。不过，rebar3_hank 的想法非常有趣，其中大部分都可以在 Erlang LS 中轻松实现。因此，我决定移植其中一个，检测未使用的宏，并借此机会解释为 Erlang LS 贡献一个新的诊断后端的过程。

### 目标

给定一个 Erlang 模块，如果定义了宏但未使用，我们希望收到警告通知。

![001](/images/blog/0011_001.png)

我们怎样才能做到这一点？

### 添加新的诊断后端

我们需要做的第一件事是定义一个新的 Erlang 模块来实现 els_diagnostics 行为。 按照惯例，所有诊断模块都命名为 els_[BACKEND]_diagnostics.erl，在我们的例子中，[BACKEND] 将是未使用的宏。 因此，模块的最终名称将是 els_unused_macros_diagnostics.erl。 让我们打开一个新的文本文件并添加以下内容：

<Code language="erlang">
{`-module(els_unused_macros_diagnostics).
-behaviour(els_diagnostics).`}
</Code>

els_diagnostics 行为需要实现三个回调函数：

<Code language="erlang">
{`-callback is_default() -> boolean().
-callback source() -> binary().
-callback run(uri()) -> [diagnostic()].`}
</Code>

因此，让我们将以下导出添加到模块中。 我们将在一秒钟内实现所有功能。

<Code language="erlang">
{`-export([ is_default/0
 , source/0
 , run/1
 ]).`}
</Code>

#### 回调函数：is_default/0

is_default/0 回调用于指定是否应默认启用当前后端。 在我们的例子中，我们希望默认启用新的后端，所以我们说：

<Code language="erlang">
{`is_default() -> true.`}
</Code>

如果最终用户决定禁用此后端，她可以在她的 erlang_ls.config 中添加以下选项：

<Code language="yaml">
{`diagnostics:
 disabled:
 unused_macros`}
</Code>

#### 回调函数：sources/0

现在让我们实现我们的第二个回调函数，source/0。 此函数返回后端的人性化名称，由 IDE 呈现（请参见上面屏幕截图中的 UnusedMacros 文本）：

<Code language="erlang">
{`source() -> <<"UnusedMacros">>.`}
</Code>

#### run/1函数

我们需要实现的最后一个回调函数是有趣的事情发生的地方。

run/1 函数采用单个参数，即运行诊断的 Erlang 模块的 Uri。 默认情况下，诊断计算是 OnOpen（当模块首次在 IDE 中访问时）和 OnSave（当模块从 IDE 中保存时）。

该函数以 LSP 协议指定的格式返回将由 IDE 呈现的模块的诊断列表。 诊断可以有四种类型：

- Hint
- Info
- Warning
- Error

暂时，让我们返回一个空列表。

<Code language="erlang">
{`run(_Uri) -> [].`}
</Code>

### 注册后端

在我们可以在 Erlang LS 中使用我们的后端之前，我们还需要做一件事。 我们需要在可用的后端中注册它。 我们可以通过在 els_diagnostics 模块的可用诊断列表中添加一个条目来做到这一点：

<Code language="erlang">
{`available_diagnostics() ->
 [ <<"compiler">>
 , <<"crossref">>
 , <<"dialyzer">>
 , <<"elvis">>
 , <<"unused_includes">>
 , <<"unused_macros">> %% Here is our new shiny diagnostics backend!
].`}
</Code>

### 使用测试驱动开发 (TDD) 方法

此时，我们可以开始执行 run/1 函数的主体。 然后，为了尝试事情是否按预期工作，我们可以：

- 将我们的 Erlang LS 版本重建为 escript
- 在我们的 IDE 中打开一个新文件
- 重启 Erlang LS
- 在我们的新文件中添加一个未使用的宏
- 保存文件
- 确保在保存时产生警告
- 检查 Erlang LS 日志，看看为什么事情没有按我们预期的方式工作
- 清除并重复

这种方法效果甚微，它会大大减慢我们的反馈循环，并且会使为 Erlang LS 做出贡献的整个体验变得痛苦。

幸运的是，有一个更好的方法：从测试用例开始。 毕竟，如果我们打算贡献我们的新后端，无论如何我们都需要添加一个测试用例。

但是，我们如何为这样的功能实现测试用例呢？ 这听起来像很多工作，我们不知道从哪里开始。 这就是 Erlang LS 测试框架发挥作用的地方。

我们需要做的第一件事是向 Erlang LS 测试应用程序添加一个最小示例（由于历史原因，它被命名为 code_navigation，应该重命名）。 您可以在项目的 priv 目录中找到它。

我们的最小示例可能如下所示：

<Code language="erlang">
{`$ cat priv/code_navigation/src/diagnostics_unused_macros.erl
-module(diagnostics_unused_macros).

-export([main/0]).

-define(USED_MACRO, used_macro).
-define(UNUSED_MACRO, unused_macro).

main() ->
?USED_MACRO.`}
</Code>

在上面的代码中，我们定义了两个宏，我们只使用了其中一个。 因此，我们希望在第 6 行发出UNUSED_MACRO警告。

我们还需要将我们的最小示例注册到 Erlang LS 测试框架中。 为此，我们在 els_test_utils 模块的源列表中添加一行：

<Code language="erlang">
{`sources() ->
 [ ...
 , diagnostics_unused_macros
 , ...
 ]`}
</Code>

现在，我们可以专注于实际的测试用例。 由于它是一个诊断测试，我们可以扩展已经存在的 els_diagnostics_SUITE 模块。 测试套件利用了 Erlang/OTP 中的 Common Test 框架，如果不熟悉请参考官方文档。

首先，我们导出新的测试用例，我们称之为unused_macros：

<Code language="erlang">
{`-export([ ...
 , unused_macros/1
 . ...
 ])`}
</Code>

然后，我们可以实现新测试用例的主体：

<Code language="erlang">
{`unused_macros(Config) ->
 Uri = ?config(diagnostics_unused_macros_uri, Config),
 els_mock_diagnostics:subscribe(),
 ok = els_client:did_save(Uri),
 Diagnostics = els_mock_diagnostics:wait_until_complete(),
 Expected = [ #{ message => <<"Unused macro: UNUSED_MACRO">>
 , range =>
 #{ 'end' => #{ character => 20
 , line => 5
 }
 , start => #{ character => 8
 , line => 5
 }
 }
 , severity => ?DIAGNOSTIC_WARNING
 , source => <<"UnusedMacros">>
 }
 ],
 ?assertEqual(Expected, Diagnostics),
 ok.`}
</Code>

这里发生了很多事情，所以让我们一起来看代码，从头开始：

<Code language="erlang">
{`Uri = ?config(diagnostics_unused_macros_uri, Config),`}
</Code>

在这里，我们从 Common Test Config 中获取包含我们最小示例的 Erlang 模块的 Uri。 这感觉有点神奇，因为我们从未在任何地方填充该变量。 这是怎么回事？

还记得我们在上面的 sources/1 函数中注册了我们的新测试模块吗？ 这导致 Erlang LS 测试框架不仅索引该文件，还创建了几个方便的变量，可以在编写测试用例时使用。 [MODULE_NAME]_uri 是这些变量之一。 另一个是 [MODULE_NAME]_text，其中包含模块的实际源代码。 但是现在让我们继续我们的测试用例：

<Code language="erlang">
{`els_mock_diagnostics:subscribe(),`}
</Code>

由于我们想测试一个新的诊断后端，我们订阅诊断流，以便我们可以拦截和验证它们。 同样，我们使用 Erlang LS 测试框架提供的实用功能。

<Code language="erlang">
{`ok = els_client:did_save(Uri),
Diagnostics = els_mock_diagnostics:wait_until_complete(),`}
</Code>

然后，我们模拟 IDE 保存文件并等待诊断（异步计算）完成。

<Code language="erlang">
{`Expected = [ #{ message => <<"Unused macro: UNUSED_MACRO">>
 , range =>
 #{ 'end' => #{ character => 20
 , line => 5
 }
 , start => #{ character => 8
 , line => 5
 }
 }
 , severity => ?DIAGNOSTIC_WARNING
 , source => <<"UnusedMacros">>
 }
 ],
?assertEqual(Expected, Diagnostics),
ok.`}
</Code>

在这里，我们验证我们的后端是否生成了一条警告消息（注意 source 属性）。 警告消息预计在第 6 行，字符 8 和 20 之间（对应于宏名称的位置）。

?DIAGNOSTIC_WARNING 宏定义在 erlang_ls.hrl 头文件中，所以让我们将它包含在导出列表下方：

<Code language="erlang">
{`-include("erlang_ls.hrl").`}
</Code>

现在让我们执行我们的测试用例并检查结果。 请注意我们需要如何为测试用例指定一个组，因为所有 Erlang LS 测试都可以针对两个 LSP 支持的传输（TCP 和 stdio）运行。

<Code language="shell">
{`$ rebar3 ct --suite els_diagnostics_SUITE --case unused_macros --group tcp
===> Verifying dependencies...
===> Analyzing applications...
===> Compiling erlang_ls
===> Running Common Test suites...
%%% els_diagnostics_SUITE:
[...]
expected: [#{message => <<"Unused macro: UNUSED_MACRO">>,
 range =>
 #{'end' => #{character => 20,line => 5},
 start => #{character => 8,line => 5}},
 severity => 2,source => <<"UnusedMacros">>}]
got: []
line: 582`}
</Code>

不出所料，测试用例失败了，因为我们还没有实现 run/1 函数，但是我们返回了一个硬编码的空列表。 让我们现在解决这个问题。

### 查找未使用的宏

我们终于可以跳到本教程的有趣部分，实现未使用宏的检测机制。 像往常一样，让我们先看看整个代码，然后解释它的行为。

<Code language="erlang">
{`run(Uri) ->
 {ok, [Document]} = els_dt_document:lookup(Uri),
 UnusedMacros = find_unused_macros(Document),
 [make_diagnostic(Macro) || Macro <- UnusedMacros].`}
</Code>

首先，我们通过 Uri 查询 Erlang LS 数据库。 然后，我们在返回的文档上调用 find_unused_macros/1 函数——我们仍然需要实现它。 对于每个已识别的宏，我们以 LSP 协议预期的格式生成诊断。 同样，我们仍然需要实现我们的 make_diagnostic/1 函数。

现在让我们关注 find_unused_macros/1 函数。 该函数的目标是识别给定文档中未使用的宏： 

<Code language="erlang">
{`find_unused_macros(Document) ->
 Definitions = els_dt_document:pois(Document, [define]),
 Usages = els_dt_document:pois(Document, [macro]),
 UsagesIds = [Id || #{id := Id} <- Usages],
 [POI || #{id := Id} = POI <- Definitions, not lists:member(Id, UsagesIds)].`}
</Code>

同样，这里发生了很多事情，所以让我们逐行浏览代码。

首先，我们识别所有的宏定义，由define 键识别：

<Code language="erlang">
{`Definitions = els_dt_document:pois(Document, [define]),`}
</Code>

然后，我们识别所有的宏用法，通过macro key识别：

<Code language="erlang">
{`Usages = els_dt_document:pois(Document, [macro]),`}
</Code>

您可以参考 Erlang LS 中的 els_parser 模块，了解有关 POI（兴趣点）和可用键的详细信息。

对于每个宏用法，我们提取各自的 id 并返回没有相应用法的宏定义列表：

<Code language="erlang">
{` UsagesIds = [Id || #{id := Id} <- Usages],
 [POI || #{id := Id} = POI <- Definitions, not lists:member(Id, UsagesIds)].`}
</Code>

最后缺少的位是 make_diagnostic/1 函数，它将每个 POI 转换为诊断：

<Code language="erlang">
{`make_diagnostic(#{id := Id, range := POIRange} = _POI) ->
 Range = els_protocol:range(POIRange),
 MacroName = atom_to_binary(Id, utf8),
 Message = <<"Unused macro: ", MacroName/binary>>,
 Severity = ?DIAGNOSTIC_WARNING,
 Source = source(),
 els_diagnostics:make_diagnostic(Range, Message, Severity, Source).`}
</Code>

该函数本质上是实用函数 els_diagnostics:make_diagnostic/4 的包装。 让我们详细分析一下。

<Code language="erlang">
{` Range = els_protocol:range(POIRange),`}
</Code>

这里我们使用 Erlang LS 提供的辅助函数将 POI 的范围（未使用的宏定义）转换为 LSP 协议所需的格式。

<Code language="erlang">
{` MacroName = atom_to_binary(Id, utf8),
 Message = <<"Unused macro: ", MacroName/binary>>,`}
</Code>

然后，我们使用有问题的宏的 id（名称）构建诊断消息。

<Code language="erlang">
{` Severity = ?DIAGNOSTIC_WARNING,`}
</Code>

我们将指定为消息的严重程度为警告。

<Code language="erlang">
{`Source = source(),`}
</Code>

我们调用 source/0 函数来指定诊断的来源（用于 IDE 中的渲染目的）。

<Code language="erlang">
{`els_diagnostics:make_diagnostic(Range, Message, Severity, Source).`}
</Code>

最后，我们使用构造的参数调用 els_diagnostics:make_diagnostic/4 函数来生成诊断。

应该是这样的。 让我们再次尝试执行测试用例：

<Code language="shell">
{`$ rebar3 ct --suite els_diagnostics_SUITE --case unused_macros --group tcp
===> Verifying dependencies...
===> Analyzing applications...
===> Compiling erlang_ls
===> Running Common Test suites...
%%% els_diagnostics_SUITE:
All 1 tests passed.`}
</Code>

成功！ 现在测试通过了，我们能够识别 Erlang LS 中未使用的宏！

### 完整的后端

下面是后端的完整实现，供参考：

<Code language="erlang">
{`-module(els_unused_macros_diagnostics).
-behaviour(els_diagnostics).

-export([ is_default/0
, source/0
, run/1
]).

-include("erlang_ls.hrl").

is_default() -> true.

source() -> <<"UnusedMacros">>.

run(Uri) ->
{ok, [Document]} = els_dt_document:lookup(Uri),
UnusedMacros = find_unused_macros(Document),
[make_diagnostic(Macro) || Macro <- UnusedMacros].

find_unused_macros(Document) ->
Definitions = els_dt_document:pois(Document, [define]),
Usages = els_dt_document:pois(Document, [macro]),
UsagesIds = [Id || #{id := Id} <- Usages],
[POI || #{id := Id} = POI <- Definitions, not lists:member(Id, UsagesIds)].

make_diagnostic(#{id := Id, range := POIRange} = _POI) ->
Range = els_protocol:range(POIRange),
MacroName = atom_to_binary(Id, utf8),
Message = <<"Unused macro: ", MacroName/binary>>,
Severity = ?DIAGNOSTIC_WARNING,
Source = source(),
els_diagnostics:make_diagnostic(Range, Message, Severity, Source).`}
</Code>

当然，上面的实现非常简单，可以在很多方面进行改进，但是此时您应该了解为 Erlang LS 实现新的诊断后端意味着什么。

## 结论

上面的后端已经集成在 Erlang LS 中，但作为一个可选的后端。 您可以在[以下位置](https://github.com/erlang-ls/erlang_ls/pull/867/files)查看全部贡献：

为开源做贡献可能是一种令人生畏的经历，尤其是当您没有无限的可用时间时。 我希望这个小教程可以帮助你朝这个方向发展，我期待着你能为 Erlang LS 做出贡献。

玩得开心！

Erlang LS指南（五）

## 启动调试会话
### VS Code

选择 Run and Debug 面板，从下拉列表中选择 Existing Erlang Node 并按下播放按钮：

![001](/images/blog/0010_001.png)

打开一个新终端并使用 curl 命令触发我们的新断点。

<Code language="shell">
{`curl -i http://localhost:8080

HTTP/1.1 200 OK
content-length: 12
content-type: text/plain
date: Fri, 09 Jul 2021 13:35:01 GMT
server: Cowboy

Hello world!`}
</Code>

执行将在断点处暂停。 然后，您可以使用标准的 VS Code 控件来控制执行：

![002](/images/blog/0010_002.png)

在左侧，可以探索调用堆栈和变量绑定。 例如，我们可以逐步扩展 Cowboy 输入请求的绑定并验证 User Agent 标头的值：

![003](/images/blog/0010_003.png)

底部的调试控制台可用作 REPL，并提供当前的变量绑定：

![004](/images/blog/0010_004.png)

左侧的Watch列表可用于跟踪特定变量的值（例如，Opts 变量）：

![005](/images/blog/0010_005.png)

以及用于操作这些值的调试控制台：

![006](/images/blog/0010_006.png)

VS Code 提供了广泛的调试功能。 更多信息请参考官方 VS Code 文档。

### Emacs

打开 src/toppage_h.erl 并运行：

<Code language="emacs">
{`M-x dap-debug`}
</Code>

系统将提示您输入配置模板。 选择现有的 Erlang 节点。

打开一个新终端并使用 curl 命令触发我们的新断点。

<Code language="shell">
{`curl -i http://localhost:8080

HTTP/1.1 200 OK
content-length: 12
content-type: text/plain
date: Fri, 09 Jul 2021 13:35:01 GMT
server: Cowboy

Hello world!`}
</Code>

执行将在断点处暂停。 然后，您可以使用标准 Emacs 控件来控制执行：

![007](/images/blog/0010_007.png)

在右侧，可以探索调用堆栈和变量绑定。 例如，我们可以逐步扩展 Cowboy 输入请求的绑定并验证 User Agent 标头的值：

![008](/images/blog/0010_008.png)

您还可以使用当前可用的变量绑定打开 REPL：

<Code language="emacs">
{`M-x dap-eval`}
</Code>

dap-mode 包提供了广泛的调试功能。 更多信息请参考官方文档。

## 特殊断点类型

DAP 协议描述了可以在不同情况下使用的多种断点类型：

- 条件断点
- Logpoints
- Hitpoints

### 条件断点

仅当给定条件评估为真时才会触发条件断点。 例如，我们可能希望仅当客户端传递的 Host 标头的值包含字符串 pigeon 时才中断执行：

### VS Code

要设置条件断点，请右键单击行号旁边并选择添加条件断点…选项。 添加以下表达式：

<Code language="shell">
{`maps:get(<<"host">>, maps:get(headers, Req0)) =:= <<"pigeon">>`}
</Code>

![009](/images/blog/0010_009.png)

### Emacs

要添加条件断点，请移动到现有断点，然后运行：

<Code language="emacs">
{`M-x dap-breakpoint-condition`}
</Code>

并添加以下表达式：

<Code language="emacs">
{`maps:get(<<"host">>, maps:get(headers, Req0)) =:= <<"pigeon">>`}
</Code>

设置了上述条件断点后，以下请求不会导致执行中断：

<Code language="shell">
{`curl -i http://localhost:8080`}
</Code>

但以下将会触发断点：

<Code language="shell">
{`curl -H "Host: pigeon" -i http://localhost:8080`}
</Code>

## Logpoints

日志断点是一种特殊类型的断点，它不会导致执行中断，但它们会导致在调试控制台中打印出一条日志消息。

### VS Code

要记录每个请求的 Host 标头，请右键单击行号旁边并选择 Add logpoint… 选项。 添加以下日志消息：

<Code language="shell">
{`maps:get(<<"host">>, maps:get(headers, Req0))`}
</Code>

让我们用不同的（或默认的）主机头触发一些请求：

<Code language="shell">
{`curl -i http://localhost:8080
curl -H "Host: pigeon" -i http://localhost:8080`}
</Code>

然后我们可以在调试控制台中跟踪日志断点：

![010](/images/blog/0010_010.png)

### Emacs

要记录每个请求的 Host 标头，请移动到现有断点，然后运行：

<Code language="emacs">
{`M-x dap-breakpoint-log-message`}
</Code>

添加以下日志消息：

<Code language="shell">
{`maps:get(<<"host">>, maps:get(headers, Req0))`}
</Code>

让我们用不同的（或默认的）主机头触发一些请求：

<Code language="shell">
{`curl -i http://localhost:8080
curl -H "Host: pigeon" -i http://localhost:8080`}
</Code>

要跟踪日志断点，请运行：

<Code language="shell">
{`M-x dap-go-to-output-buffer`}
</Code>

![011](/images/blog/0010_011.png)

## Hitpoints

Hitpoints是一种特殊的断点，每 N 次触发一次。

### VS Code

选择一个现有断点并从下拉列表中选择 Hit Count 选项。 指定一个数字 N。相应的断点将每第 N 次触发一次。

### Emacs

导航到现有断点。 运行：


<Code language="emacs">
{`M-x dap-breakpoint-hit-condition`}
</Code>

指定一个数字 N。相应的断点将每第 N 次触发一次。

## 故障排除

如果某些事情没有按预期工作，请查看 Erlang LS DAP 日志。 他们很可能会指出问题的根本原因。 日志可在以下位置获得：

<Code language="shell">
{`[USER_LOG_DIR]/[PROJECT_NAME]/dap_server.log`}
</Code>

其中 [USER_LOG_DIR] 是以下输出：

<Code language="shell">
{`filename:basedir(user_log, "els_dap").`}
</Code>

例如，在 Mac OS 上，hello_world 项目的 DAP 日志将位于：

<Code language="shell">
{`/Users/[USERNAME]/Library/Logs/els_dap/hello_world/dap_server.log`}
</Code>

如果 DAP 日志没有帮助，请随时在 GitHub 或 Slack 上联系。

使用 Erlang LS 进行愉快的调试！

## 如何进行Code Lenses

在我们之前的教程中，我们学习了如何为 Erlang 语言服务器实现诊断后端。 这次我们将深入了解 Code Lenses 的世界。

### 目标

给定一个包含许多函数定义的 Erlang 模块，我们希望在其各自定义之上显示对每个函数的引用数。 这是code lenses在 VS Code 中的外观。

![012](/images/blog/0010_012.png)

在本教程结束时，您将：

- 知道什么是code lenses
- 学习如何在 Erlang LS 中实现code lenses
- 离成为 Erlang LS 贡献者更近一步

事不宜迟，让我们开始吧。

### 到底什么是 Code Lens？

Wade Anderson 将 Code Lens 定义为：

> 散布在您的源代码中的可操作的上下文信息

这是一种非常奇特的说法，即code lenses是出现在 IDE 中的位于您的代码旁边的任意一段文本。 文本通常会提供有关部分代码的见解，就像我们刚刚在上面看到的示例一样。

code lenses也可以是可操作的。 用户可以通过单击lenses或使用键盘快捷键来激活lenses以执行操作。 触发的动作可以是任何东西。 这是一个 Emacs code lenses，它允许用户执行给定的 Common Test 测试用例：

![013](/images/blog/0010_013.png)

code lenses是上下文相关的，这意味着它们知道周围的上下文。 在上面的例子中，运行测试lenses知道点击时应该执行哪个特定的测试用例。

现在我们了解了什么是code lenses，让我们在 Erlang LS 中实现一个。

### 实现新的 Code Lens 后端

Erlang LS 提供了一个框架，使code lenses的开发尽可能简单。 要创建我们的新的code lenses，我们需要做的第一件事是为其命名并创建一个新的 Erlang 模块来实现 els_code_lens 行为。 让我们将新代码称为lens function_references。

<Code language="erlang">
{`-module(els_code_lens_function_references).
-behaviour(els_code_lens).`}
</Code>

els_code_lens 行为需要实现三个回调函数：

<Code language="erlang">
{`-callback is_default() -> boolean().
-callback pois(els_dt_document:item()) -> [poi()].
-callback command(els_dt_document:item(), poi(), state()) -> els_command:command().`}
</Code>

稍后我们将看到每个回调函数应该做什么。 现在，让我们将以下函数导出添加到我们的 els_code_lens_function_references 模块中：

<Code language="erlang">
{`-export([ is_default/0
 , pois/1
 , command/3
 ]).`}
</Code>

现在我们可以专注于每个单独的回调函数。

#### 回调函数：is_default/0

is_default/0 回调用于指定是否应默认启用当前后端。 在我们的例子中，我们希望默认启用新的后端，所以我们说：

<Code language="erlang">
{`is_default() -> true.`}
</Code>

如果最终用户决定禁用此后端，她可以在她的 erlang_ls.config 中添加以下选项：

<Code language="yaml">
{`lenses:
 disabled:
 function_references`}
</Code>

#### 回调函数：pois/1

在 Erlang LS 行话中，POI 代表兴趣点。 该术语指的是作为代码库一部分的有兴趣的点位。 兴趣点由 Erlang LS 索引并存储在内存数据库中。 POI 可以指代函数定义、宏定义、记录用法，应有尽有。 Erlang LS 提供了一组实用程序，可以轻松搜索和操作兴趣点。

pois/1 函数接受一个参数，即当前文档。 它的返回值是应该为其激活lenses的 POI 列表。 在我们的例子中，我们希望我们的lenses在每个函数定义旁边都是可见的。 因此，我们写：

<Code language="erlang">
{`pois(Document) ->
 els_dt_document:pois(Document, [function]).`}
</Code>

#### 回调函数：command/3

我们需要实现的最后一个强制回调是 command/3 之一。 回调接受三个参数：当前文档、特定 POI 和状态。 为了本教程的目的，我们将忽略状态并仅关注前两个参数。

#### The Command

该函数需要返回一个命令。 命令是一个 LSP 数据结构，它包含：

- The title – 每个选定 POI 旁边呈现的文本
- A Command Id – 单击时执行的命令的标识符
- Command Args – 传递给命令的参数列表

Erlang LS 提供了一个辅助函数来创建这样的数据结构： els_command:make_command/3 函数。 然后，我们的 command/3 函数将如下所示：

<Code language="erlang">
{`command(Document, POI, _State) ->
 Title = title(Document, POI),
 CommandId = command_id(),
 CommandArgs = command_args(),
 els_command:make_command(Title, CommandId, CommandArgs).`}
</Code>

我们现在将详细描述每个参数并学习如何计算它们，从标题开始。

##### The title

标题是我们想要在文本编辑器中显示的文本，位于我们的兴趣点（又名 POI）旁边。 在我们的例子中，我们想要显示以下文本：

Used [N] times

为了能够计算数字 N，我们需要知道有多少对当前函数的引用分布在我们的代码库中。 因此，我们可以通过 els_dt_references:find_by_id/2 辅助函数查询 Erlang LS 数据库：

<Code language="erlang">
{`title(Document, POI) ->

%% Extract the module name from the current document
#{uri := Uri} = Document,
M = els_uri:module(Uri),

%% Extract the function name and arity from the current POI
#{id := {F, A}} = POI,

%% Query the Erlang LS DB for references to the current function
{ok, References} = els_dt_references:find_by_id(function, {M, F, A}),

%% Calculate the number of references
N = length(References),

%% Format the title for the code lens
unicode:characters_to_binary(io_lib:format("Used ~p times", [N])).`}
</Code>

els_dt_references:find_by_id/2 函数有两个参数：我们正在寻找的引用类型（在我们的例子中是函数）和当前兴趣点的完全限定 ID。 对于函数定义，完全限定标识符是 \{M, F, A\} 元组，代表模块、函数名称和函数的 Arity。 如上所示，我们可以从 Document 中提取模块 M，从当前 POI 中提取 F 和 A。

##### CommandId and CommandArgs

CommandId 是当用户点击我们的code lenses时我们想要运行的命令的任意标识符。 在我们的例子中，这个动作将是一个空操作，但我们仍然需要为我们的命令选择一个名称。 我们称之为函数引用：

<Code language="erlang">
{`command_id() -> <<"function-references">>.`}
</Code>

由于我们的命令是无操作的（如果用户点击lenses，我们不希望发生任何事情），我们的命令不需要任何参数：

<Code language="erlang">
{`command_args() -> [].`}
</Code>

我们基本上完成了。 为了完整起见，这是我们完整的 els_code_lens_function_references 模块：

<Code language="erlang">
{`-module(els_code_lens_function_references).

-behaviour(els_code_lens).
-export([ is_default/0
, pois/1
, command/3
]).

is_default() ->
true.

pois(Document) ->
els_dt_document:pois(Document, [function]).

command(Document, POI, _State) ->
Title = title(Document, POI),
CommandId = command_id(),
CommandArgs = command_args(),
els_command:make_command(Title, CommandId, CommandArgs).

title(Document, POI) ->
#{uri := Uri} = Document,
M = els_uri:module(Uri),
#{id := {F, A}} = POI,
{ok, References} = els_dt_references:find_by_id(function, {M, F, A}),
N = length(References),
unicode:characters_to_binary(io_lib:format("Used ~p times", [N])).

command_id() ->
<<"function-references">>.

command_args() ->
[].`}
</Code>

### 注册Code Lenses

在使用新的code lenses之前，我们还需要做一件事：我们需要告诉 Erlang LS 它的存在。 这可以通过将我们的新的code lenses添加到 els_code_lens 模块中的 available_lenses 列表中来实现：

<Code language="erlang">
{`available_lenses() ->
 [ ...
 , <<"function-references">>
 ].`}
</Code>

就这样。

### 添加测试

此时我们的code lenses应该可以正常工作，但在为它编写测试之前我们无法确定！ Erlang LS 提供了一个可用于此目的的测试框架。 在本节中，我们将假设您已经对 Erlang LS 测试框架有所了解。 如果您想更温和地介绍 Erlang LS 中的测试，请参阅之前的诊断教程。

#### 创建测试模块

让我们在 code_navigation 测试应用程序中创建一个名为 code_lens_function_references 的测试模块：

<Code language="shell">
{`$ cat apps/els_lsp/priv/code_navigation/src/code_lens_function_references.erl
-module(code_lens_function_references).

-export([ a/0 ]).

-spec a() -> ok.
a() ->
b(),
c().

-spec b() -> ok.
b() ->
c().

-spec c() -> ok.
c() ->
ok.`}
</Code>

#### 注册新的测试模块

只需打开 els_test_utils 模块并将新模块添加到源列表中。 这将确保新模块被正确索引并且一些辅助函数可用。

<Code language="erlang">
{`sources() ->
 [ ...
 , code_lens_function_references
 , ...
 ].`}
</Code>

#### 编写测试用例

然后让我们打开 els_code_lens_SUITE 模块并添加一个测试用例，我们在其中检查新的code lenses在新模块中是否按预期工作。

<Code language="erlang">
{`function_references(Config) ->
 Uri = ?config(code_lens_function_references_uri, Config),
 #{result := Result} = els_client:document_codelens(Uri),
 Expected = [ lens(5, 0) # First lens on line 5, 0 references
 , lens(10, 1) # Second lens on line 10, 1 reference
 , lens(14, 2) # Third lens on line 14, 2 references
 ],
 ?assertEqual(Expected, Result),
 ok.`}
</Code>

在上面的测试用例中，我们通过利用 Erlang LS 测试框架来获取新添加的测试模块的 Uri。 然后，我们使用 els_client 为给定的 Uri 调用 document_codelens 方法，最终确保我们收到预期的code lenses列表。 lens/2 是一个辅助函数，它构造了 LSP 协议所期望的数据结构如下：

<Code language="erlang">
{`lens(Line, Usages) ->
 Title = unicode:characters_to_binary(
 io_lib:format("Used ~p times", [Usages])),
 #{ command =>
 #{ arguments => []
 , command => els_command:with_prefix(<<"function-references">>)
 , title => Title
 }
 , data => []
 , range =>
 #{ 'end' => #{character => 1, line => Line}
 , start => #{character => 0, line => Line}
 }
 }.`}
</Code>

让我们运行测试并确保它通过。

<Code language="shell">
{`$ rebar3 ct --suite apps/els_lsp/test/els_code_lens_SUITE --case function_references --group tcp
[...]
===> Running Common Test suites...
%%% els_code_lens_SUITE: .
All 1 tests passed.`}
</Code>

看起来我们在这里完成了。

##### 回调函数：init/1

init/1 回调允许我们对每个文件执行一次计算，并将计算值以 State 的形式传递给后续回调函数（还记得我们在 command/3 回调中忽略的 State 参数吗？）。 例如，在建议规范code lenses中使用它来为每个 Erlang 模块运行一次 TypEr，并且仍然能够为每个函数显示一个lens。

##### 回调函数：precondition/1

precondition/1 回调允许我们只为特定类型的文档启用给定的lens。 例如，以下实现仅对 Common Test 套件启用 ct_run_test lens，由 ct.hrl 文件的 include_lib 指令标识：


<Code language="erlang">
{`precondition(Document) ->
 Includes = els_dt_document:pois(Document, [include_lib]),
 case [POI || #{id := "common_test/include/ct.hrl"} = POI <- Includes] of
 [] ->
 false;
 _ ->
 true
 end.`}
</Code>

## 结论

此时，您应该可以尝试新的code lenses。 上面的code lenses已经在 Erlang LS 中可用。 您可以在[以下位置](https://github.com/erlang-ls/erlang_ls/pull/947)查看全部贡献。我希望本教程能帮助您更好地理解code lenses以及如何在 Erlang LS 中实现code lenses。 期待您将实施的精彩lens！

Erlang LS指南（四）

## 工作区符号

立即跳转到您正在寻找的模块。

![001](/images/blog/0009_001.png)

## 折叠（folding）

专注于重要的事情，放弃其余的。

![002](/images/blog/0009_002.png)

## 代码片段

快速插入参数化、可重用的代码片段。

![003](/images/blog/0009_003.gif)

## 类型规格（Type Specs）的自动建议

使用类型信息进行 Erlang 程序的类型注释。

![004](/images/blog/0009_004.gif)

## 调用层次（Call Hierarchy ）结构

Call Hierarchy 功能可让您探索给定函数的调用者（称为传入调用），以及显示给定函数调用了哪些函数（称为传出调用）。

有关调用层次结构的概述，请观看[此视频](https://www.youtube.com/watch?v=r5LA7ivUb2c)。

### VS Code

![005](/images/blog/0009_005.png)

要显示 Call Hierarchy 面板，请右键单击函数名称并选择 Show Call Hierarchy。 您可以使用新打开的面板在调用层次结构中导航。

要在传入调用和传出调用之间切换，只需使用面板右上角的call图标。

### Emacs

![006](/images/blog/0009_006.png)

该功能由 lsp-treemacs 包提供。

要显示传入调用层次结构：

<Code language="shell">
{`M-x lsp-treemacs-call-hierarchy`}
</Code>

要显示传出调用层次结构：

<Code language="shell">
{`C-u M-x lsp-treemacs-call-hierarchy`}
</Code>

有关更多信息，请参阅官方 lsp-treemacs 文档。

## Code Actions

代码操作是一种在错误或警告旁边为用户提供可能的纠正操作的机制。 如果有可用的操作，错误或警告旁边会出现一个灯泡或类似图标。 当用户单击灯泡（或点击快捷方式）时，会显示可用代码操作的列表。

目前 Erlang LS 支持以下代码操作：

- 导出未使用的函数
- 在未使用的变量前添加下划线 (_)
- 更正未绑定变量的错误名称
- 修复模块名称以匹配相应的文件名

## 相关配置

### erlang_ls.config 文件

可以通过名为 erlang_ls.config 的配置文件自定义 erlang_ls 服务器的行为。 erlang_ls.config 文件应放置在给定项目的根目录中，以存储该项目的配置。

示例 erlang_ls.config 文件如下所示：

<Code language="yaml">
{`otp_path: "/path/to/otp/lib/erlang"
deps_dirs:
 - "lib/*"
diagnostics:
 enabled:
 - crossref
 disabled:
 - dialyzer
include_dirs:
 - "include"
 - "_build/default/lib"
lenses:
 enabled:
 - ct-run-test
 disabled:
 - show-behaviour-usages
macros:
 - name: DEFINED_WITH_VALUE
 value: 42
 - name: DEFINED_WITHOUT_VALUE
code_reload:
 node: node@example`}
</Code>

文件格式为 yaml。

可以进行以下自定义：

| 参数 | 说明 |
| :-: | :-: |
| apps_dirs	| 包含项目应用程序的目录列表。它支持通配符。|
| code_reload | 是否应该对远程节点进行 rpc 调用以编译和重新加载模块|
| deps_dirs	| 包含依赖项的目录列表。它支持通配符。|
| diagnostics| 	自定义活动诊断列表。请参阅下面的可用诊断列表。|
| include_dirs| 	作为包含目录提供给编译器的目录列表。它支持通配符。|
| incremental_sync| 	是否支持客户端中文本更改的增量同步。默认启用。|
| lenses |	 自定义活动code lenses列表|
| macros | 	要传递给编译器的自定义宏列表，表示为名称/值对。如果该值被省略或无效，则使用“真”。|
| otp_apps_exclude |	不会被索引的 OTP 应用程序列表（默认：megaco、diameter、snmp、wx）|
| otp_path	| OTP 安装路径|
| plt_path |	Dialyzer PLT 文件的路径。如果没有提供，Dialyzer诊断将不可用。|
| code_path_extra_dirs	|erlang_ls 将使用代码add_path/1添加的通配符路径列表|
| elvis_config_path	elvis.config| 文件的路径。默认为 ROOT_DIR/elvis.config|
| exclude_unused_includes|	从 Unused Includes 警告中排除的包含文件列表|
| compiler_telemetry_enabled|	启用后，发送telmetry/event LSP 消息，其中包含文件中存在的任何诊断的代码字段。默认为假。|

### 诊断

打开或保存文件时，会在后台运行诊断列表，将代码库的最终问题报告给编辑器。 可以使用以下诊断：

|诊断名称	|用途	|默认值|
|:-: | :-: | -: |
|bound_var_in_pattern|	报告已在模式中绑定的变量（受 pinning 运算符的启发）	|enabled|
|compiler|	报告来自 Erlang 编译器的内联警告和错误	|enabled|
|crossref|	使用来自 Erlang LS 数据库的信息来找出未定义函数	|disabled|
|dialyzer|	使用 dialyzer 静态分析工具查找代码中的差异	|enabled|
|elvis|	使用 elvis 查看 Erlang 代码的样式	|enabled|
|unused_includes|	警告包含但未使用的头文件	|enabled|
|unused_macros|	警告已定义但未使用的宏	|enabled|

可以为特定项目定制诊断。 例如：

<Code language="yaml">
{`diagnostics:
 disabled:
 - dialyzer
 enabled:
 - crossref`}
</Code>

### 自动代码重新加载

code_reload 采用以下选项：

|参数|	描述|
|:-:| :-:|
|node|	为代码重新加载而调用的节点。 例如 erlang_ls@hostname|

### Code Lenses

Code Lenses 也可以在 Erlang LS 中使用。 Erlang LS 提供以下lenses：

|Code Lens 名称	|用途|
|:-: | :-:|
|ct-run-test|	在通用测试用例旁边显示一个运行按钮|
|function-references	|显示对函数的引用数|
|server-info	|在每个模块的顶部显示一些 Erlang LS 服务器信息。 仅用于调试。|
|show-behaviour-usages	|显示实现行为的模块数量|
|suggest-spec	|使用来自Dialyzer的信息来建议spec|

默认启用以下code lenses：show-behaviour-usage
可以为特定项目定制code lenses。 例如：

<Code language="yaml">
{`lenses:
 enabled:
 - ct-run-test
 disabled:
 - show-behaviour-usages`}
</Code>

### 全局配置

也可以将系统范围的默认配置存储在位于 User Config 目录中的 erlang_ls.config 文件中。 User Config 目录的确切位置取决于所使用的操作系统，可以通过在 Erlang shell 上执行以下命令来识别它：

<Code language="shell">
{`> filename:basedir(user_config, "erlang_ls").`}
</Code>

通常，User Config 目录的位置是：

|操作系统	|User Config 目录|
|:- |:- |
|Linux	|/home/USER/.config/erlang_ls|
|OS X	|/Users/USER/Library/Application\ Support/erlang_ls|
|Windows	|c:/Users/USER/AppData/Local/erlang_ls|

因此，例如在 Linux 上，默认配置文件的完整路径是 /home/USER/.config/erlang ls/erlang ls.config

### 常见配置

许多 Erlang 存储库都遵循相同的结构。 我们在本节中包含了常见的 Erlang LS 配置，以便于重用。

#### rebar3 项目

以下配置可用于大多数基于 rebar3 的项目。

<Code language="shell">
{`apps_dirs:
 - "_build/default/lib/*"
include_dirs:
 - "_build/default/lib/*/include"
 - "include"`}
</Code>

#### rebar3 umbrella 项目

如果您的 rebar3 项目包含多个应用程序（例如，在应用程序文件夹中），您可能需要调整您的 Erlang LS 配置，如下所示。

<Code language="shell">
{`apps_dirs:
 - "apps/*"
deps_dirs:
 - "_build/default/lib/*"
include_dirs:
 - "apps"
 - "apps/*/include"
 - "_build/default/lib/"
 - "_build/default/lib/*/include"`}
</Code>

#### The erlang/otp repository

为了能够在 erlang/otp 存储库中使用主要的 Erlang LS 功能，以下最小配置就足够了。

<Code language="yaml">
{`otp_path: "/path/to/otp"
apps_dirs:
 - "lib/*"
include_dirs:
 - "lib"
 - "lib/*/include"`}
</Code>

## 相关讨论

Boost your Productivity with the Erlang Language Server

**2020-09-11** Code BEAM Stockholm (Virtual)

<Youtube id="8FibGzqygo0" title="Code BEAM Stockholm"/>

为编程语言实现自动完成或转到定义等功能并非易事。 传统上，必须为每个开发工具重复这项工作，并且需要目标编程语言和所选开发工具内部使用的编程语言的专业知识组合。

一个绝妙的直觉，“语言服务器协议”（LSP），改变了游戏规则。 对 Erlang 社区来说是一个真正的祝福。

## 论文

提及 Erlang LS 的学术论文列表如下：

- B.Benavides, L.Castro, 2021 – Detecting Oxbow Code in Erlang Codebases with the Highest Degree of Certainty – Proceedings of the 20th ACM SIGPLAN International Workshop on Erlang (Erlang ’21).

## 如何使用调试器

Erlang LS 通过[Debug Adapter Protocol](https://microsoft.github.io/debug-adapter-protocol/)（简称 DAP）提供调试功能。 鉴于协议与编辑器无关的特性，所有支持 DAP 协议的文本编辑器和 IDE 都可以进行调试。 这是 Emacs 中调试会话的样子：

![007](/images/blog/0009_007.png)

当前的底层实现基于 Erlang/OTP 附带的 Erlang 解释器。 顺便说一句，官方 OTP 调试器也由同一个解释器提供支持。

在本教程中，我们将引导一个示例项目，看看我们如何使用 Erlang LS 调试我们的代码。

### 安装调试器

Erlang LS 中通过名为 els_dap 的单独可执行文件（Erlang escript）提供了调试功能。

#### VS Code

该可执行文件与 Erlang LS 扩展捆绑在一起，因此不需要任何额外的安装步骤。 您可以通过指定不同的 DAP 路径来配置 Erlang LS 扩展以使用自定义版本的调试器：

<Code language="shell">
{`Extension Settings > DAP Path`}
</Code>

#### Emacs

如果您使用的是 Emacs，那么您很可能是从源代码构建 Erlang LS。 要生成 els_dap 脚本：

<Code language="shell">
{`rebar3 as dap escriptize`}
</Code>

或者简单地说：

<Code language="shell">
{`make`}
</Code>

然后，您将在以下位置找到 els_dap 脚本：

<Code language="shell">
{`_build/dap/bin/els_dap`}
</Code>

确保生成的 els_dap escript 位于 Emacs 已知的 PATH 中。

官方 dap-mode 包支持 Erlang，因此需要该包和 Erlang 插件：

<Code language="shell">
{`(require 'dap-mode)
(require 'dap-erlang)`}
</Code>

您可以参考官方 dap-mode 文档以获取有关如何安装和配置 dap-mode 软件包及其插件的更多信息。

### 设置示例项目

为了展示 Erlang LS 调试器，我们将使用 Cowboy 网络服务器中的 Hello World 示例。 让我们从clone项目开始：

<Code language="shell">
{`git clone https://github.com/ninenines/cowboy.git
cd cowboy/examples/hello_world`}
</Code>

该项目使用 erlang.mk 构建系统和 relx 发布汇编器。 为了能够在我们的示例项目中使用调试器，我们需要对项目进行两个小的修改：

- 包含 Erlang 调试器作为依赖项
- 告诉 erlang.mk 符号链接版本中的 hello_world 应用程序

要将调试器添加为依赖项，请将以下行添加到项目的 Makefile 中的 include ../../erlang.mk 行之前：

<Code language="shell">
{`LOCAL_DEPS = debugger`}
</Code>

要对应用程序进行符号链接，请将以下行添加到 relx.config 文件中：

<Code language="yaml">
{`{overrides, [{hello_world, "../hello_world"}]}.`}
</Code>

我们现在可以运行我们的网络服务器：

<Code language="shell">
{`make run`}
</Code>

以上应该会导致终端中运行一个新的 Erlang 节点，名为 hello_world_example@[HOSTNAME]。

我们现在应该可以将浏览器指向 http://localhost:8080 以查看我们辉煌的 Hello world！字符串。

让我们保持服务器运行。 打开一个新终端并继续执行以下步骤。

### 创建启动配置

我们需要告诉调试器如何连接到正在运行的节点。 我们将通过启动配置来做到这一点。

#### VS Code

导航到 Run and Debug 面板并单击 Create a launch.json file 链接并选择 Erlang OTP Debugger 选项。

![008](/images/blog/0009_008.png)

这将在 .vscode/launch.json 中创建一个文件。 将文件内容替换为以下内容：

<Code language="json">
{`{
 "version": "0.2.0",
 "configurations": [
 {
 "name": "Existing Erlang Node",
 "type": "erlang",
 "request": "attach",
 "projectnode": "hello_world_example",
 "cookie": "hello_world_example",
 "timeout": 300,
 "cwd": "$\{workspaceRoot\}"
 }
 ]
}`}
</Code>

#### Emacs

我们需要在项目的顶层目录中创建一个名为 launch.json 的文件。 在我们的例子中，该文件将驻留在 cowboy/examples/hello_world/launch.json 中：

<Code language="json">
{`{
 "version": "0.2.0",
 "configurations": [
 {
 "name": "Existing Erlang Node",
 "type": "erlang",
 "request": "attach",
 "projectnode": "hello_world_example",
 "cookie": "hello_world_example",
 "timeout": 300
 }
 ]
}`}
</Code>

### 添加断点

#### VS Code

访问 src/toppage_h.erl 文件并通过单击与 init/2 函数体的第一行对应的行号旁边的来添加断点。

![009](/images/blog/0009_009.png)

#### Emacs

导航到 src/toppage_h.erl，移动到 init/2 函数体的第一行并运行：

<Code language="shell">
{`M-x dap-breakpoint-add`}
</Code>

![010](/images/blog/0009_010.png)

Erlang LS指南（三）

## Theia IDE
### 安装

通过在运行实例中包含 Erlang/OTP 并安装 VSCode 扩展，可以在 Theia IDE 中使用 Erlang LS。

如果您想尝试使用 GitPod，请单击此处。 要在您的 Erlang 项目（托管在 GitHub 或 Gitlab）中使用相同的设置，您可以在 .gitpod.yml 中找到 GitPod 配置

## Kakoune

Kakoune 编辑器通过 Kakoune 语言服务器协议客户端 (kak-lsp) Kakoune 插件为 Erlang LS 提供支持。

### 步骤 0：使用最近的 Kakoune 安装

确保您最近安装了 Kakoune。 包管理器可能带有非常旧的 Kakoune 版本。

提示：

1. 从源代码构建 Kakoune 很容易，并且会为您提供最新的功能
2. 如果您按照此页面上的步骤操作，Erlang LS 应该可以在 Kakoune 中使用。 但是，除了 Erlang LS 提供的功能（如 goto 定义等）之外，您可能还希望看到 Erlang 的语法突出显示。这仅在 Kakoune 2021.10.28 标记版本（及更高版本）或当前 git 源中可用

### 第 1 步：安装 Erlang LS

在你的系统上安装 Erlang LS。 您可能会或可能不会决定将 erlang_ls 可执行文件放在 $PATH 上。

### 第 2 步：安装 kak-lsp

按照存储库上的说明从源代码安装或构建 kak-lsp。

### 第 3 步：编辑 kak-lsp 配置

寻找 kak-lsp.toml。 该文件具有 Kakoune kak-lsp 插件的语言特定设置。

在 Linux 上，kak-lsp 的配置通常应该位于 $HOME/.config/kak-lsp/kak-lsp.toml 中，其中 $HOME 是您的主目录。

在你最喜欢的编辑器（Kakoune 😄？）中打开 kak-lsp.toml，查找 [language.erlang]。 它应该看起来像这样：

<Code language="bash">
{`[language.erlang]
filetypes = ["erlang"]
# See https://github.com/erlang-ls/erlang_ls.git for more information and
# how to configure. This default config should work in most cases though.
roots = ["rebar.config", "erlang.mk", ".git", ".hg"]
command = "erlang_ls"`}
</Code>

提示：如果您没有找到 [language.erlang]，您可能使用的是旧版本的 kak-lsp。 没关系，你可以自己添加这个 toml 片段到 kak-lsp.toml ，这没有任何问题。

如果 erlang_ls 可执行文件在您的 $PATH 上
如果您添加了上述代码片段并重新启动 Kakoune，请保存 kak-lsp.toml。

你完成了！ Erlang LS 现在应该可以用于 Erlang 项目和源代码了！

如果 erlang_ls 可执行文件不在您的 $PATH 上
将 [language.erlang] 部分的命令行更改为：

<Code language="bash">
{`command = "/the/path/to/erlang_ls"`}
</Code>

不要忘记保存文件并重新启动 Kakoune！

## 特性
### 面包屑

面包屑在页面顶部显示指向当前元素及其祖先的链接列表。

![001](/images/blog/0008_001.png)

#### VS Code

面包屑可以通过以下方式启用或禁用：

<Code language="bash">
{`Settings > Workbench > Breadcrumbs`}
</Code>

设置部分包含许多额外的首选项来调整要精确显示的内容（例如图标、符号、文件的完整路径等）。

#### Emacs

面包屑由 lsp-mode 包提供。 要启用面包屑：

<Code language="bash">
{`(setq lsp-headerline-breadcrumb-mode t)`}
</Code>

您还可以通过自定义 lsp-headerline-breadcrumb-segments 变量来自定义在面包屑中显示的内容。 更多信息请参考官方 lsp-mode 文档。

### Code Completion

通过获取上下文感知完成函数名称、宏、记录、变量名称等代码。

![002](/images/blog/0008_002.png)

### Go To Definition

导航到函数、宏、记录或类型的定义。

![003](/images/blog/0008_003.gif)

### 转到 OTP 行为的实现

在 gen_server:start_link 调用上悬停？ 只需按一下键即可跳转到相应的 init 函数。

![004](/images/blog/0008_004.gif)

### 函数签名（Signature）建议

永远不记得函数keytake/3参数列表的顺序？ 你并不孤单。 我们为您提供保障。

![005](/images/blog/0008_005.gif)

### 编译器信息诊断

整齐地排列显示来自编译器的警告和错误。

![006](/images/blog/0008_006.png)

### Dialyzer诊断信息

让 Dialyzer 毫无错误地完全通过从未如此简单。

![007](/images/blog/0008_007.png)

### Elvis 诊断信息

内联显示Elvis的风格建议。 不再有同事的挑剔评论！

![008](/images/blog/0008_008.png)

### Edoc

将鼠标悬停在本地或远程函数上以查看其 edoc。 当 edocs 不可用时，您会非常想念这个功能，以至于您将开始主动编写它们！

![009](/images/blog/0008_009.gif)

### 包含文件（Included files）自动导航

只需单击一下即可导航到包含的文件。

![010](/images/blog/0008_010.gif)

### 查找/查看参考

谁在调用这个函数？ 可以在不离开当前上下文的情况下弄清楚。

![011](/images/blog/0008_011.png)

### 大纲（Outline）

在旁边获得一个很好的模块大纲并在功能之间跳转。

![012](/images/blog/0008_012.png)

Erlang LS指南（二）

## 欢迎来到 Erlang LS的世界

为编程语言实现自动完成或跳转到定义等功能并非易事。传统上，必须为每个开发工具重复这项工作，并且需要目标编程语言和所选开发工具内部使用的编程语言的专业知识组合。

一个绝妙的直觉， [Language Server Protocol](https://microsoft.github.io/language-server-protocol/)，也称为 LSP，改变了游戏规则。对 Erlang 社区来说是一个真正的祝福。

Erlang LS 是一个为 Erlang 编程语言提供语言特性的语言服务器。该服务器可与 Emacs、VSCode、Sublime Text 3、Vim 以及可能更多遵循 LSP 协议的文本编辑器和 IDE 配合使用。

这些页面包含配置您喜欢的文本编辑器或 IDE 以及使用 Erlang LS 所需的所有信息。您还将找到有关如何配置服务器以识别项目结构并在事情未按预期工作时对安装进行故障排除的说明。

## 保持联系

如果您对该项目有任何疑问，请随时在 GitHub 上打开一个新issue。 如果您想参与其中或喜欢更非正式的交流方式，也可以加入 Erlanger Slack 中的 #erlang-ls 频道。 欢迎所有贡献，无论是以错误报告、问题、反馈或代码的形式。

## 入门

Erlang LS 语言服务器适用于所有遵守 LSP 协议的文本编辑器和 IDE。 支持的编辑器列表包括 Emacs、Vim、VS Code、Sublime Text 3 等。

这些页面包含配置您喜欢的文本编辑器或 IDE 以使用 Erlang LS 所需的所有信息。 您还将找到有关如何配置服务器以识别项目结构并在事情未按预期工作时对安装进行故障排除的说明。

## Emacs

### 安装

官方的 lsp-mode package 包括一个 Erlang 语言服务器的客户端。

在这里，您可以找到一个示例的 Emacs 配置文件，它安装和配置使所有 Erlang LS 功能正常工作所需的所有包。可以使用这个配置文件作为 Erlang LS Emacs 配置的起点。

每当第一次打开项目时，emacs-lsp 都会提示您选择正确的项目根目录。在那种情况下，您还有机会将项目列入黑名单。有关项目的信息存储在 lsp-session-file 变量指向的文件中。它的默认位置是 ~/.emacs.d/.lsp-session-v1。如果您改变主意将项目列入黑名单或错误地选择了项目根目录，则可能需要修剪或修改此文件。有关 lsp-session-file 和 emacs-lsp 的更多信息，请参阅官方文档。

请记住，Erlang 语言服务器需要 Erlang/OTP 21 或更高版本才能运行，因此请确保 OTP 21+ 在您的 PATH 中可用。例如，这可以通过使用 exec-path-from-shell Emacs 包来实现。

### 重启Language Server

您可能希望快速重新启动给定工作区的Language server（例如，在更新后或服务器崩溃的情况下）。 可以采用如下代码：

<Code language="bash">
{`M-x lsp-workspace-restart`}
</Code>

### 故障排除

如果事情没有按预期工作，我们建议您仅使用提供的示例文件中的配置启动 Emacs，使用以下命令：

<Code language="bash">
{`emacs -q -l [PATH-TO-ERLANG-LS]/misc/dotemacs`}
</Code>

这将从表达式中消除与您工作站上可能拥有的其他软件包或配置的潜在不兼容性，并且可能与 Erlang LS 冲突。

为了确保您没有安装过时或不兼容的软件包，您可能还想在对 Erlang LS Emacs 设置进行故障排除时重命名 ~/.emacs.d 目录。

此外，确保 Erlang（即 erl、escript 和朋友）和 erlang_ls 可执行文件都在您的 PATH 中可用。 如果不是，您可以尝试以下方法：

<Code language="bash">
{`;; Ensure your Emacs environment looks like your user's shell one
(package-require 'exec-path-from-shell)
(exec-path-from-shell-initialize)`}
</Code>

最后，要在客户端启用日志记录，只需：

<Code language="bash">
{`(setq lsp-log-io t)`}
</Code>

然后，您可以通过执行以下操作来跟踪当前工作区的客户端日志：

<Code language="bash">
{`M-x lsp-workspace-show-log`}
</Code>

### 技巧和窍门

您可以运行 M-x lsp-avy-lens 在shortcuts旁边显示字母。 然后，您可以按这些字母来触发相应的操作。

如果你已启用 ((setq lsp-ui-sideline-enable t))，您还可以使用 M-x lsp-execute-code-action 来触发快速修复操作。

## Spacemacs
### 安装 

开发分支包括一个 Erlang 层，支持使用 Erlang LS 作为后端的语言服务器协议。

您可以在此处找到有关安装和配置以及支持的功能的信息。

在设置 dotspacemacs-configuration-layers 时，可以配置 lsp 和 erlang-mode 变量，例如：

<Code language="bash">
{`dotspacemacs-configuration-layers
'(
;...
lsp
(erlang :variables
 erlang-backend 'lsp
 erlang-root-dir "<path to>/otp_22/lib/erlang"
 erlang-man-root-dir "<path to>/otp_22_kred/lib/erlang/man"
 erlang-fill-column 100
 company-minimum-prefix-length 1
 company-idle-delay 0.3
 lsp-ui-doc-position 'bottom)
;...
)`}
</Code>

## VSCode
### 安装

Erlang 语言服务器可通过专用扩展在 VSCode 中使用。

要试用它，只需打开 VSCode 并通过 Marketplace 安装扩展：

<Code language="bash">
{`Preferences > Extensions`}
</Code>

寻找 erlang-ls 扩展并安装它。 就是这样。

请记住，Erlang 语言服务器需要 Erlang/OTP 21 或更高版本才能运行，因此请确保 OTP 21+ 在您的 PATH 中可用。

### 重启Language Server

您可能希望快速重新启动给定工作区的语言服务器（例如，在更新后或服务器崩溃的情况下）。 为此：

<Code language="bash">
{`View -> Command Palette... -> Developer: Reload Window`}
</Code>

在 Mac OS 上，您可以使用 Cmd+Shift+P 快捷方式快速访问命令面板。

## Sublime Text 3
### 安装

安装 Erlang LS：

<Code language="bash">
{`git clone https://github.com/erlang-ls/erlang_ls
cd erlang_ls
rebar3 escriptize`}
</Code>

这将在以下位置创建一个 Erlang 脚本：

<Code language="bash">
{`_build/default/bin/erlang_ls`}
</Code>

尝试使用 –version 标志运行 Erlang LS 以验证一切是否按预期工作：

<Code language="bash">
{`_build/default/bin/erlang_ls --version`}
</Code>

确保 erlang_ls 在您的 PATH 中。

### 为 Sublime Text 3 安装 LSP 客户端

使用工具菜单中的命令面板，选择包控制：安装包并安装 LSP 包。

完成后，转到：

<Code language="bash">
{`Preferences -> Package Settings -> LSP -> Settings`}
</Code>

通过将以下配置添加到 LSP.sublime-settings – User 文件来添加 Erlang 客户端：

<Code language="bash">
{`{
 "clients":
 {
 "erlang-ls":
 {
 "command" : [ "erlang_ls", "--transport", "stdio" ],
 "enabled" : true,
 "languageId": "erlang",
 "scopes" : [ "source.erlang" ],
 "syntaxes" : ["Packages/Erlang/Erlang.sublime-syntax"]
 }
 },
 // Allow up to 30 secs to \`erlang_ls\` to respond to \`initialize\`
 // (it requires less, but just to be on the safe side)
 "initialize_timeout": 30
}`}
</Code>

就是这样。 打开一个新的 Erlang 项目并享受 Erlang LS。

### 故障排除
#### 确保 Erlang LS 在你的 PATH 中

为了能够使用 Erlang LS，erlang_ls escript 需要在您的路径中。

#### 启用日志记录

如果出现问题，您可以通过将以下配置添加到 LSP.sublime-settings – 用户文件来为 LSP 包启用额外的日志记录：

<Code language="bash">
{`{
 // Show verbose debug messages in the sublime console.
 "log_debug": true,

// Show messages from language servers in the Language Servers output
// panel.
"log_server": true,

// Show language server stderr output in the Language Servers output
// panel.
"log_stderr": true,

// Show full JSON-RPC requests/responses/notifications in the Language
// Servers output panel.
"log_payloads": true
}`}
</Code>

Sublime 控制台可以使用 Ctrl-` 快捷键进行切换。 可以使用命令 LSP：切换面板：语言服务器从命令面板切换输出面板。

## IntelliJ

### 安装
> 警告：IntelliJ LSP 插件 (1.6.1) 的当前版本非常有限，因此并非所有 Erlang 语言服务器功能都在 IntelliJ 中可用。

首先，确保您已安装 LSP 支持插件。 如果你不这样做，你可以简单地导航到：

<Code language="bash">
{`Preferences > Plugins > Browse Repositories`}
</Code>

搜索“LSP Support”并安装相应的插件。

重新启动 IntelliJ，然后导航到：

<Code language="bash">
{`Preferences > Languages and Frameworks > Language Server Protocol > Server Definitions`}
</Code>

在那里，您可以指导 IntelliJ 如何启动服务器。 选择 Raw Command，设置 erl;hrl 作为扩展名，然后添加为命令：

<Code language="bash">
{`/ABSOLUTE/PATH/TO/erlang_ls/_build/default/bin/erlang_ls --transport stdio`}
</Code>

确保使用绝对路径。 该插件似乎不理解 ~ 符号。 要使上述命令正常工作，IntelliJ 需要正确配置 PATH 变量以包含 Erlang 20+。 要在 Mac OS 上规避这个问题，最好的方法是从终端（即通过 idea 命令）而不是通过 Spotlight 启动 IntelliJ。

要在悬停函数时可视化文档和类型规范，请确保在您的 IntelliJ 首选项中启用 Show quick documentation on mouse move 选项：

<Code language="bash">
{`Preferences > Editor > General`}
</Code>

在那里，您还可以设置以毫秒为单位的延迟。

有关如何配置 IntelliJ LSP 客户端的更多信息，请参阅项目 GitHub 页面。

### 故障排除

在某些情况下，IntelliJ LSP 客户端可能无法连接到服务器。 在这种情况下，第一步是启用日志记录：

<Code language="bash">
{`Preferences > Languages and Frameworks > Language Server Protocol`}
</Code>

选中此处的日志服务器通信复选框。

重新启动 IntelliJ 后，您会注意到在您的 Erlang 项目中创建了一个额外的 lsp 目录。 该目录包含错误和输出日志，它应该给你一个关于正在发生的事情的提示。

IntelliJ 日志表示另一种信息来源：

<Code language="bash">
{`Help > Show Logs`}
</Code>

## Vim / NeoVim
### 使用Coc进行安装

以下说明应通过 Coc 系统（Vim 和 Neovim 的智能感知引擎）启用 Erlang 语言服务器集成。

#### 使用 vim-plug 安装 Coc

对于安装了 nodejs >= 10.12 的 vim-plug 用户，安装插件只是：

<Code language="bash">
{`" Use release branch (Recommended)
Plug 'neoclide/coc.nvim', {'branch': 'release'}`}
</Code>

然而，要让插件知道 erlang_ls，它需要配置。

#### coc插件配置

coc是通过coc-settings.json配置的，可以在vim中通过以下命令打开：

<Code language="bash">
{`:CocConfig`}
</Code>

如果 erlang_ls 存在于您的 $PATH 变量中，那么以下配置就足够了：

<Code language="bash">
{`{
 "languageserver": {
 "erlang": {
 "command": "erlang_ls",
 "filetypes": ["erlang"]
 }
 }
}`}
</Code>

当 vim 开始编辑文件类型为 erlang 的文件时，如果可以启动并连接 erlang_ls 服务器，您应该会看到来自 Coc 的以下消息：

<Code language="bash">
{`[coc.nvim] Erlang LS (in erlang_ls), version: X.Y.Z+build.REF`}
</Code>

有关配置 Coc 和可能的键绑定的建议，请参阅其示例配置文档。

### 使用内置语言服务器客户端设置 Neovim

以下说明应该使用 Neovim 中的内置语言服务器客户端启用 Erlang 语言服务器集成。 nvim-lspconfig 插件用于配置、启动和初始化语言服务器。

#### 安装 nvim-lspconfig

例如 vim-plug 安装：

<Code language="bash">
{`Plug 'neovim/nvim-lspconfig'`}
</Code>

#### 启用Language Server

将以下设置调用添加到您的 init.vim 以使语言服务器附加到 Erlang 文件：

<Code language="bash">
{`lua require'lspconfig'.erlangls.setup{}`}
</Code>

现在，当您打开 Erlang 文件时，您应该会看到如下消息：

<Code language="bash">
{`LSP[erlangls][Info] Erlang LS (in <your-project>), version: ..., OTP version: ...`}
</Code>

通过编写一些不正确的代码来测试它。 您应该会看到语法错误消息。 运行 :LspInfo 以获取活动和已配置语言服务器的状态。

#### 配置

LSP 命令没有默认的键绑定。 你可以在 nvim-lspconfig 插件页面的 Keybindings and completion 部分找到一个很好的例子来说明如何设置这些。 这个想法是创建一个函数来设置您的键绑定和配置，该函数将传递给上一节中的 setup 函数。 然后在附加 Erlang 语言服务器时调用此函数。 有关详细信息，请参阅 Neovim LSP 文档。

#### 技巧和窍门

在 Neovim 中运行 :h vim.diagnostic.config 以获取有关如何显示诊断信息的说明。 :h vim.lsp.codelens.refresh 描述了如何显示代码镜头。

Erlang LS指南（一）

Erlang JIT中基于类型的优化

自从Erlang 存在，就一直有让它更快的需求和野心。这篇博文是一堂历史课，概述了主要的 Erlang 实现以及如何尝试提高 Erlang 的性能。

## Prolog 解释器

Erlang 的第一个版本是在 1986 年在 Prolog 中实现的。那个版本的 Erlang 对于创建真正的应用程序来说太慢了，但它对于找出Erlang语言的哪些功能有用，哪些无用时很有用。在Prolog解释器中，可以在几小时或几天内添加或删除新的语言功能。

很快就清楚的了解，Erlang 需要至少快 40 倍才能在实际项目中应用。

## JAM（Joe’s Abstract Machine）

1989 年，JAM（Joe’s Abstract Machine）首次实现。[Mike Williams](http://www.erlang-factory.com/conference/ErlangUserConference2013/speakers/MikeWilliams)用 C 编写了运行时系统，[Joe Armstrong](https://github.com/joearms)编写了编译器， [Robert Virding](https://github.com/rvirding)编写了库。

JAM 比 Prolog 解释器快 70 倍，但事实证明这仍然不够快。

## TEAM (Turbo Erlang Abstract Machine)

Bogumil (“Bogdan”) Hausman 创建了 TEAM (Turbo Erlang Abstract Machine)。它将 Erlang 代码编译为 C 代码，然后使用 GCC 将其编译为本机代码。

对于小型项目，它比 JAM 快得多。但不幸的是，编译速度非常慢，而且编译后的代码太大，无法用于大型项目。

## BEAM（Bogdan’s Erlang Abstract Machine）

Bogumil Hausman 的下一台机器称为 BEAM（Bogdan’s Erlang Abstract Machine）。它是一种混合机器，可以执行本机代码（通过 C 翻译）和带有解释器的线程化代码。这允许客户将他们对时间要求严格的模块编译为本机代码，并将所有其他模块编译为线程化的 BEAM 代码。线程化的 BEAM 比 JAM 代码快。

## BEAM/C 的经验教训

现代的 BEAM 只有解释器，BEAM 生成 C 代码的能力在 OTP R4 中被删除，这是为什么呢？

C 语言不是 Erlang 编译器合适的目标语言，其主要原因是因为 Erlang 的进程模型，这里不能简单地将 Erlang 函数转换为 C 函数。每个 Erlang 进程都必须有自己的堆栈，并且该堆栈不能由 C 编译器自动管理。

BEAM/C 为每个 Erlang 模块生成了一个 C 函数。模块内的本地调用是通过显式将返回地址推送到 Erlang 堆栈，使用随后的goto语句跳转到调用函数来进行的。（严格来说，调用函数将返回地址存储到 BEAM 寄存器，然后被调用函数将该寄存器压入堆栈。）

使用 GCC 扩展，也可以类似地完成其他模块的调用：获取标签的地址，然后跳转到它。外部的调用也可以通过将返回地址压入堆栈，随后使用一个goto语句跳转到别的C 函数中的标签地址，完成外部调用。

这是不是未定义的行为？

是的，即使在 GCC 中也是未定义的行为。它只是碰巧在 Sparc处理器上与 GCC 一起工作，但是不适用于 X86 的 GCC。更复杂的是，嵌入式系统的 ANSI-C 编译器没有任何 GCC 扩展。

因此，我们必须维护三种不同风格的 BEAM/C 来处理不同的 C 编译器和平台。我不记得当时有任何基准测试，但 BEAM/C 在任何其他平台上都不太可能比在 Sparc 上的 Solaris 上解释的 BEAM 更快。

最后，我们移除了 BEAM/C 并对解释后的 BEAM 进行了优化，使其在速度上可以击败 BEAM/C。

## HiPE

HiPE（高性能 Erlang 项目）是Uppsal大学的一个研究项目，从 1996 年左右开始运行多年。它“旨在使用一般的消息传递，特别是并发功能语言 Erlang 有效地实现并发编程系统”。

该项目的众多成果之一是用于 Erlang 的 HiPE 本机代码编译器。HiPE 于 2001 年成为 OTP R8 中 OTP 发行版的一部分。HiPE 原生编译器是用 Erlang 编写的，无需 C 编译器的帮助即可将 BEAM 代码转换为原生代码，因此避免了 BEAM/C 遇到的许多问题.

与解释的 BEAM 代码相比，HiPE 本机编译器通常可以将顺序代码加速两倍或三倍。我们希望这将加速现实世界的大型应用系统。不幸的是，爱立信内部尝试 HiPE 的项目发现它并没有提高性能。

这是为什么？

主要原因可能是大多数大型 Erlang 应用程序没有包含足够的 HiPE 可以优化的顺序代码。这些系统的运行时间通常由消息传递、对[ETS](https://erlang.org/doc/man/ets.html) BIF 的调用和垃圾收集的某种组合控制，这些都没有 HiPE 可以优化。

另一个原因可能是大系统通常有许多小模块。HiPE 原生编译器（与 Erlang 编译器一样）无法跨模块边界优化代码，因此无法进行很多基于类型的优化。

此外，对于大多数大型系统，将所有 Erlang 模块编译为本地代码会导致构建时间过长，并且生成的代码会消耗过多的内存。从本机代码切换到解释 BEAM 会产生少量开销，反之亦然。找出哪些模块可以从编译为本机代码中获益，同时避免在本机代码和解释代码之间进行过多的上下文切换，这是一项不平凡的任务。

由于 Ericsson Erlang 项目中没有一个使用 HiPE 原生编译器，因此 OTP 团队只能花费有限的时间来维护 HiPE。因此，HiPE 的文档包含以下说明：

> HiPE 和 HiPE 编译代码的执行仅得到爱立信 OTP 团队的有限支持。OTP 团队只对 HiPE 做有限的维护，并没有积极开发 HiPE。HiPE 主要由Uppsala大学的 HiPE 团队提供支持。

### HiPE 项目的其他成果

我认为如果没有 HiPE 项目，Erlang/OTP 在今天看起来会非常不同。以下是 HiPE 项目对 OTP 的主要贡献：

- OTP R7 中的一种新的[分段标签方案](http://www.it.uu.se/research/publications/reports/2000-029/2000-029-nc.pdf)。新的标记方案允许 Erlang 系统寻址完整的 4GB 地址空间（以前的标记方案仅支持寻址较低的 1GB）。令人惊讶的是，新的标签方案还提高了性能。
- 直到今天，Erlang 编译器仍在使用 Core Erlang 中间表示。有关更多信息，请参阅 Core Erlang 简介和 [Core Erlang 示例](http://blog.erlang.org/core-erlang-by-example)。
- [Dialyzer](https://erlang.org/doc/apps/dialyzer/index.html)（DIscrepancy AnaLYZer for ERlang programs）最初是作为 HiPE 原生编译器的类型分析通道，但很快成为 Erlang 程序员帮助在其应用程序中查找错误和无法访问代码的工具。
- Bit string 和 binary comprehensions。
- 在 OTP R10 中引入[try…… catch](https://erlang.org/workshop/2004/exception.pdf)
- 实现每个函数的计数器和[cprof](https://erlang.org/doc/man/cprof.html) 模块。计数器最初旨在用于查找热点函数并为这些函数生成本机代码。但是解释代码和本机代码之间上下文切换的开销使得这种用法没那么有用。
- 曾有多次建议， Erlang 需要一个字面量池（literals pool)来存放预制的字面量项（而不是每次使用它们时都构建它们）。在 HiPE 团队和 OTP 团队的一次会议上，我记得[Richard Carlsson](https://github.com/richcarl)向我指出，如果[Wings3D](http://www.wings3d.com/)拥有浮点字面量会很好。OTP 团队在 OTP R12 中实现了字面量池。

## The Tracing JIT projects (BEAMJIT)

已经有三个独立的研究项目试图为 Erlang 开发tracing JIT。他们都由[RISE](https://en.wikipedia.org/wiki/Swedish_Institute_of_Computer_Science)（前身为 SICS）的 Frej Drejhammar 领导。

tracing JIT（Just In Time compiler）是一个分两个阶段运行的 JIT：
- 首先，它跟踪执行以查找热（经常执行）代码。
- 然后它将找到的tracing重写为本机代码。

这三个 JIT 项目的目标是：
- JIT 应该自动工作，用户无需事先确定哪些模块要编译为本机代码。
- 应该与非 JIT BEAM 完全兼容。特别是，跟踪、调度行为、保存调用和热代码重新加载应该能正常工作，并且堆栈跟踪应该与非 JIT BEAM 中的相同。
- 至少平均而言系统应该永远不会比非 JIT BEAM 慢。

如果运行基准测试，则会获得一些承诺的结果，但最终证明不可能实现永远不比非 JIT 系统慢的目标。以下是运行缓慢的主要原因：
- 为了进行跟踪（查找热代码），BEAM 解释器需要调整。而在不降低 BEAM 解释器的基本速度的情况下，很难进行跟踪。
- 在不降低 BEAM 解释器基本速度的情况下，设计解释代码和本机代码之间的上下文切换机制也很困难。
- 当找到热代码序列时，需要将代码编译为本机代码。但使用 LLVM 的编译速度很慢。
- 当一个热代码序列最终被转换为本机代码时，它可能不会再次被执行。对于运行多道pass的 Erlang 编译器来说，这尤其是一个问题。通常，当一次pass的某些代码已转换为本机代码时，编译器已经在运行下一次pass。

后来的项目缓解了以前项目中的一些问题。例如，通过在调用 LLVM 之前进行更多优化来减少编译时间。不过，最终决定在 2019 年底终止第三个也是最后一个tracing JIT 项目。

有关 BEAMJIT 的更多信息，请参阅：
- BEAMJIT: a just-in-time compiling runtime for Erlang
- Just-in-time in No Time? “Use the Source!”
- JIT, a Maze of Twisty Little Traces
- A Status Update of BEAMJIT, the Just-in-Time Compiling Abstract Machine
- Just-in-time compiler for the Erlang VM
- Tracing JIT Compiler

## 新的 JIT（也称为 BeamAsm）

在第三个tracing JIT 项目结束后，参与了最后两个tracing JIT 项目的[Lukas Larsson，想了各种不同的方法来生成一个有用的 JIT](https://github.com/garazdawi) 。造成前三个tracing JIT缓慢的原因是跟踪以查找热代码和使用 LLVM 生成优化的本机代码。是否有可能有一个更简单的 JIT，它不进行跟踪并且没有或很少进行优化？

2020 年 1 月，从第三个tracing JIT 项目中挽救了一些代码，Lukas 迅速构建了一个原型 BEAM 系统，该系统在加载时将每个 BEAM 指令翻译成本机代码。生成的代码不如 LLVM 生成的代码优化，主要是因为它仍然使用 BEAM 的堆栈和 X 寄存器（存储在内存中），但消除了[指令解包和指令分派的开销](http://blog.erlang.org/a-closer-look-at-the-interpreter/)。

最初的基准测试结果很有希望：与解释的 BEAM 代码相比，速度大约是两倍，因此 Lukas 扩展了原型，以便它可以处理更多种类的 BEAM 指令。

[John Högberg](https://github.com/jhogberg)很快对这个项目产生了兴趣，并开始充当传声筒。一段时间后，可能是在 3 月，John 建议新的 JIT 应该将所有加载的代码转换为本地代码。这样，就不需要支持 BEAM 解释器和本机代码之间的上下文切换，这将使设计更简单并消除上下文切换的成本。

那当然是一场赌博。毕竟，本机代码可能太大而无法实际使用或降低性能，因为它不适合代码缓存。他们认为冒险是值得的，以后可能会优化代码的大小。（剧透：在撰写本文时，JIT 生成的本机代码比解释的 BEAM 代码大 10%。）

设计的另一个变化是生成本机代码的工具。在 Lukas 的原型中，每条指令的本地代码模板都包含在与加载程序使用的其他文件类似的文本文件中。那是不灵活的，所以决定使用一些可以生成本机代码的库。虽然可以使用一些纯 C 库，但 C++ 库[AsmJIT](https://asmjit.com/)在实际使用中比任何 C 库都更方便。此外，一些 C 库被排除在外，因为它们使用了 GNU 许可证，而我们不能在 OTP 中使用。因此，将 BEAM 指令转换为本机代码的加载程序部分需要用 C++ 编写，但运行时系统的其余部分仍然是纯 C 代码，并且将保持不变。

John 于 3 月底加入了重新调整的 JIT 项目的实际工作。

2020 年 4 月 7 日，约翰达到了“prompt beer”的里程碑。

### Prompt Beer

当 Erlang 系统启动时，在提示符出现之前执行了大量的代码。一方面，这意味着在启动 Erlang 系统之前需要实现许多指令的翻译，更不用说运行任何测试套件或基准测试了。

另一方面，当提示符最终出现时，是一个重要的里程碑，值得用一些prompt beer或其他适当的饮料来庆祝，或者在晚上剩下的时间里休息一下。

### 新的 JIT成熟

4 月 14 日，John 让 Dialyzer 使用 JIT 运行，而在 4 月 17 日，在对代码生成进行了一些改进之后，使用 JIT 的 Dialyzer 仅比使用 HiPE的 慢 10%。没有一个tracing JIT 在加速 Dialyzer 方面取得任何成功。（在撰写本文时，Dialyzer 在 JIT 下的运行速度与在 HiPE 上的运行速度大致相同，尽管由于 HiPE 不能在 OTP 23 之后的版本上运行，因此进行公平比较变得越来越困难。）

可能是在那个时候，我们意识到我们有一个可以最终包含在 OTP 版本中的 JIT。

5 月 6 日实现了堆栈跟踪中的行号，实现了下一个重要里程碑。这意味着更多的测试用例现在可以运行并取得成功了。

此后不久，所有测试套件都可以成功运行。在夏季和初秋期间， [我](http://github.com/bjorng)和[Dan](http://github.com/dgud)兼职加入了该项目，并完成了以下工作：

对 BEAM 加载程序进行了重大重构，以便在 JIT 和 BEAM 解释器之间共享尽可能多的代码。（BEAM 解释器仅用于不支持 JIT 的平台。）
实现和完善重要但较少使用的功能，例如跟踪、性能支持和保存调用（参见[process_flag/2](https://erlang.org/doc/man/erlang.html#process_flag-2)的save_calls标志）。
缩小生成的本机代码的代码大小。
将 JIT 移植到 Windows，结果相对容易。
使使用本机堆栈指针寄存器和堆栈操作指令成为可能。这改进了性能支持并略微减小了本机代码的大小。

在 Lukas 于 9 月 11 日[介绍新JIT](https://www.youtube.com/watch?v=lM7UV95Rpyo)期间，其创建的pull request时，这项工作达到了高潮。

pull request于 9 月 22 日合并。

## 未来

以下是我们一直在为未来版本考虑的一些改进

- 支持 ARM-64（在 Raspberry Pi 和 Apple 新的带有 Apple Silicon 的 Mac 中使用）。
- 实现本机代码的类型引导生成。OTP 22 中引入的[新的基于 SSA 的编译器通道](https://blog.erlang.org/ssa-history/)进行了复杂的类型分析。令人沮丧的是，并非所有类型信息都可以用来为解释的 BEAM 生成更好的代码。我们计划修改编译器，以便将一些类型信息包含在 BEAM 文件中，然后由 JIT 在代码生成期间使用。
- 引入二进制匹配和/或构造的新指令，以帮助 JIT 生成更好的代码

Erlang JIT之路

现在我们已经了解了[BEAM](http://blog.erlang.org/a-brief-BEAM-primer/)和[解释器](http://blog.erlang.org/a-closer-look-at-the-interpreter/)，我们将探索 OTP 24 中最令人兴奋的新增功能之一：即时编译器，或简称为“JIT”。

如果你和我一样，“JIT”这个词可能会让你想到 Hotspot (Java) 或 V8 (Javascript)。这些是非常令人印象深刻的工程，但它们似乎劫持了这个术语；并非所有的 JIT 都那么复杂，也不是为了快速而必须如此复杂。

多年来，我们为了获取成功在 JIT 上进行了许多尝试。我们最新的也是迄今为止最成功的尝试是以简单为主，而不是在生成的代码中以轻微的低效率来换取易于实施。如果我们排除我们使用的运行时汇编程序库[asmjit](https://asmjit.com/)，那么整个东西大致与解释器一样大。

我相信我们的成功很大程度上归功于我们在项目早期的四个想法：

## 所有模块总是编译成机器码。

以前的尝试（以及 HiPE）在解释器和机器代码之间切换时遇到了困难：要么太慢，要么太难维护，要么两者兼而有之。

始终运行机器代码意味着我们永远不必切换。

## 在指令之间数据只在BEAM 寄存器中保存（传递）。

这可能看起来很愚蠢，机器寄存器不是更快吗？

是的，但实际上并没有太快，这会使事情变得更加复杂。通过始终在 BEAM 寄存器中传递数据，我们可以使用 Erlang 编译器提供给我们的寄存器分配策略，从而使我们不必在运行时执行这个非常昂贵的步骤。

更重要的是，从运行时系统的角度来看，这最小化了解释器和 JIT 之间的差异。

## 模块一次编译一条指令。

在我们之前的尝试中，最困难的问题之一是在编译某些东西所花费的时间和这样做的渴望之间取得良好的平衡。如果我们太急切，我们将花费太多时间编译，如果我们太松懈，我们将看不到任何改进。

这个问题很大程度上是自己造成的，并且是由于编译器太慢（我们经常使用 LLVM）造成的，而我们给它提供了大量代码以允许更多优化，这使情况变得更糟。

通过将自己限制为一次编译一条指令，我们保留了一些性能，但大大提高了编译速度。

## 每条指令都有一个手写的机器代码模板。

这使得编译非常快，因为我们基本上只是在每次使用指令时复制粘贴模板，只根据其参数执行一些小的调整。

起初这可能看起来令人生畏，但一旦你习惯了它实际上并没有那么糟糕。虽然实现即使是最小的事情肯定需要大量代码，但只要代码保持简短，它本质上就很简单且易于遵循。

缺点是每个架构都需要实现每条指令，但幸运的是没有很多流行的指令集，我们希望在我们发布 OTP 24 时支持两个最常见的指令：x86_64 和AArch64. 其他人将继续使用解释器。

编译模块时，JIT 会一一执行指令，同时调用机器代码模板。与解释器相比，这有两个非常大的好处：不需要在它们之间跳转，因为它们是背靠背发出的，并且每个的结束都是下一个的开始，并且不需要在运行时解决参数问题，因为它们已经“烧毁”了。

现在我们有了一些背景知识，让我们看一下上一篇文章中示例的机器代码模板is_nonempty_list：

<Code language="C">
{`/* Arguments are passed as 'ArgVal' objects which hold a
 * type and a value, for example saying "X register 4",
 * "the atom 'hello'", "label 57" and so on. */
void BeamModuleAssembler::emit_is_nonempty_list(const ArgVal &Fail,
 const ArgVal &Src) {
 /* Figure out which memory address 'Src' lives in. */
 x86:Mem list_ptr = getArgRef(Src);

 /* Emit a 'test' instruction, which does a non-
 * destructive AND on the memory pointed at by
 * list_ptr, clearing the zero flag if the list is
 * empty. */
 a.test(list_ptr, imm(_TAG_PRIMARY_MASK - TAG_PRIMARY_LIST));

 /* Emit a 'jnz' instruction, jumping to the fail label
 * if the zero flag is clear (the list is empty). */
 a.jnz(labels[Fail.getValue()]);

 /* Unlike the interpreter there's no need to jump to
 * the next instruction on success as it immediately
 * follows this one. */
}`}
</Code>

此模板将生成看起来与模板本身几乎相同的代码。假设我们的源是“X register 1”，我们的fail lable是 label_57：

<Code language="C">
{`test qword ptr [rbx+8], _TAG_PRIMARY_MASK - TAG_PRIMARY_LIST
jnz label_57`}
</Code>

这比解释器快得多，甚至比线程代码更紧凑，但这是一条微不足道的指令。更复杂的呢？让我们看一下timeout解释器中的指令：

<Code language="C">
{`timeout() {
 if (IS_TRACED_FL(c_p, F_TRACE_RECEIVE)) {
 trace_receive(c_p, am_clock_service, am_timeout, NULL);
 }
 if (ERTS_PROC_GET_SAVED_CALLS_BUF(c_p)) {
 save_calls(c_p, &exp_timeout);
 }
 c_p->flags &= ~F_TIMO;
 JOIN_MESSAGE(c_p);
}`}
</Code>

那肯定是很多代码，而且那些宏手动转换会很烦人。我们到底要如何做到这一点而不失去理智？

通过作弊，就是这样：D

<Code language="C">
{`static void timeout(Process *c_p) {
 if (IS_TRACED_FL(c_p, F_TRACE_RECEIVE)) {
 trace_receive(c_p, am_clock_service, am_timeout, NULL);
 }
 if (ERTS_PROC_GET_SAVED_CALLS_BUF(c_p)) {
 save_calls(c_p, &exp_timeout);
 }
 c_p->flags &= ~F_TIMO;
 JOIN_MESSAGE(c_p);
}

void BeamModuleAssembler::emit_timeout() {
/* Set the first C argument to our currently executing
* process, c_p, and then call the above C function. */
a.mov(ARG1, c_p);
a.call(imm(timeout));
}`}
</Code>

这个出口使我们不必从一开始就用汇编程序编写所有内容，并且许多指令仍然如此，因为没有任何改变它们的意义。

这就是今天的全部内容。在下一篇文章中，我们将介绍我们的约定和我们用来减少代码大小的一些技术。

初识Erlang JIT

这篇文章是初识Erlang JIT的后续文章，更深入地挖掘了实现细节。

虽然用机器代码（汇编程序）编写东西给了你很大的自由，但它的代价是必须自己发明几乎所有东西，而且没有聪明的编译器可以帮助你发现错误。例如，如果您以某种方式调用一个函数并且该函数与预期不一致，那么充其量您会使操作系统进程崩溃，或者最坏的情况是花费数小时追逐一个[heisenbug](https://en.wikipedia.org/wiki/Heisenbug)。

因此，在编写汇编程序时，约定总是最重要的，所以我们需要在继续之前明确我们选择的一些约定。

最重要的是寄存器，我们基于系统调用的约定，可以更容易调用 C 代码。我在下面列出了 Linux 上使用的 SystemV 约定的表格。寄存器在其他系统（如 Windows）上有所不同，但它们的原理是相同的。

| 寄存器 | 名称 | 调用者保存 | 用途 |
| :-- | :----------: | :----------: | :----------- |
| RDI | ARG1 | no | 第1个参数 |
| RSI | ARG2 | no | 第2个参数 |
| RDX | ARG3 | no | 第3个参数 |
| RCX | ARG4 | no |	第4个参数 |
| R8 | ARG5 | no | 第5个参数 |
| R9 | ARG6 | no | 6个参数 |
| RAX | RET | no | 数返回值 |

因此，如果我们想用两个参数调用一个 C 函数，我们在调用它之前将第一个参数放入ARG1，第二个参数放入ARG2，当函数返回时我们将在RET中得到结果。

除了说明哪些寄存器用于传递参数之外，调用约定还说明哪些寄存器在函数调用中保留其值。这些被称为“被调用者保存”寄存器，因为如果它们被修改，被调用函数需要保存和恢复它们。

在这些寄存器中，我们保留 C 代码中很少（如果有的话）更改的常用数据，帮助我们避免在调用 C 代码时保存和恢复它们：

|寄存器 | 名称 | 用者保存 | 用途 |
|:-- | :--- | :-: | :--- |
|RBP | active_code_ix | yes | 	Active code index |
|R13 | _p | yes | 	Current process |
|R15 | TOP | yes | 	Top of the current process’ heap |
|R14 | CALLS |	yes | 	Reduction counter |
|RBX | egisters | yes | 	BEAM register structure |

我们还将当前进程的堆栈指针保存在RSP寄存器（堆栈指针寄存器）中，这样就在Erlang代码中允许使用call和ret指令。

这样做的缺点是我们不能再调用任意 C 代码，因为它可能假设一个更大的堆栈，需要我们在“C 堆栈”和“Erlang 堆栈”之间来回交换。

在我之前的文章中，我们调用了一个C 函数: timeout（在我们更改堆栈的工作方式之前，它曾经是这样做的，但它仍然非常简单，如下所示：

<Code language="C">
{`void BeamModuleAssembler::emit_timeout() {
 /* Swap to the C stack. */
 emit_enter_runtime();

 /* Call the 'timeout' C function.
 *
 * runtime_call compiles down to a single 'call'
 * instruction in optimized builds, and has a few
 * assertions in debug builds to prevent mistakes
 * like forgetting to switch stacks. */
 a.mov(ARG1, c_p);
 runtime_call<1>(timeout);

 /* Swap back to the Erlang stack. */
 emit_leave_runtime();
}`}
</Code>

交换堆栈是非常便宜的操作，因为我们在设置registers时使用了一个技巧 ：通过在C函数的堆栈上分配registers结构，我们可以从中计算所述堆栈的地址，这避免了必须保留宝贵的被调用者上下文，并且比保存在内存的某个地方要快得多。

摆脱约定后，我们可以再次开始查看代码。这次让我们选择一个更大的指令[test_heap](https://github.com/erlang/otp/blob/OTP-23.1/erts/emulator/beam/macros.tab#L77-L88)，它分配堆内存：

<Code language="C">
{`void BeamModuleAssembler::emit_test_heap(const ArgVal &Needed,
 const ArgVal &Live) {
 const int words_needed = (Needed.getValue() + S_RESERVED);
 Label after_gc_check = a.newLabel();

 /* Do we have enough free space already? */
 a.lea(ARG2, x86::qword_ptr(HTOP, words_needed * sizeof(Eterm)));
 a.cmp(ARG2, E);
 a.jbe(after_gc_check);

 /* No, we need to GC.
 *
 * Switch to the C stack, and update the process
 * structure with our current stack (E) and heap
 * (HTOP) pointers so the C code can use them. */
 emit_enter_runtime<Update::eStack | Update::eHeap>();

 /* Call the GC, passing how many words we need and
 * how many X registers we use. */
 a.mov(ARG2, imm(words_needed));
 a.mov(ARG4, imm(Live.getValue()));

 a.mov(ARG1, c_p);
 load_x_reg_array(ARG3);
 a.mov(ARG5, FCALLS);
 runtime_call<5>(erts_garbage_collect_nobump);
 a.sub(FCALLS, RET);

 /* Swap back to the Erlang stack, reading the new
 * values for E and HTOP from the process structure. */
 emit_leave_runtime<Update::eStack | Update::eHeap>();

 a.bind(after_gc_check);
}`}
</Code>

虽然这并不太复杂，但它仍然具有相当多的代码：因为所有指令都直接在模块中生成，像这样的低效率往往会很快使模块膨胀。而这除了使用更多 RAM 之外，还浪费了宝贵的指令缓存，因此我们花费了大量时间和精力来减少代码大小。

我们减少代码大小的最常用方法是将尽可能多的指令分解为全局共享部分。让我们看看如何应用这种技术：

<Code language="C">
{`void BeamModuleAssembler::emit_test_heap(const ArgVal &Needed,
 const ArgVal &Live) {
 const int words_needed = (Needed.getValue() + S_RESERVED);
 Label after_gc_check = a.newLabel();

 a.lea(ARG2, x86::qword_ptr(HTOP, words_needed * sizeof(Eterm)));
 a.cmp(ARG2, E);
 a.jbe(after_gc_check);

 a.mov(ARG4, imm(Live.getValue()));

 /* Call the global "garbage collect" fragment. */
 fragment_call(ga->get_garbage_collect());

 a.bind(after_gc_check);
}

/* This is the global part of the instruction. Since we
* know it will only be called from the module code above,
* we're free to assume that ARG4 is the number of live
* registers and that ARG2 is (HTOP + bytes needed). */
 void BeamGlobalAssembler::emit_garbage_collect() {
 /* Convert ARG2 to "words needed" by subtracting
 * HTOP and dividing it by 8.
 *
 * This saves us from having to explicitly pass
 * "words needed" in the module code above. */
 a.sub(ARG2, HTOP);
 a.shr(ARG2, imm(3));

 emit_enter_runtime<Update::eStack | Update::eHeap>();

 /* ARG2 and ARG4 have already been set earlier. */
 a.mov(ARG1, c_p);
 load_x_reg_array(ARG3);
 a.mov(ARG5, FCALLS);
 runtime_call<5>(erts_garbage_collect_nobump);
 a.sub(FCALLS, RET);

 emit_leave_runtime<Update::eStack | Update::eHeap>();

 a.ret();
 }`}
</Code>

虽然我们必须编写尽可能多的代码，但复制到模块中的部分要小得多。

在我们的下一篇文章中，我们将暂停一下实现细节，看看这个 JIT 背后的历史。

再探Erlang JIT

如果您最近一直在关注 Twitter，您可能已经看到有关 Phoenix Web 框架可以处理的并发连接数的显著增加的文字。这篇文章记录了一些用于执行基准测试的技术。

## 它是如何开始的

几周前，我试图对连接数进行基准测试，并设法在我的本地计算机上获得 1k 个连接。我对这个数字不太确信，所以我在 IRC 上发帖，看看是否有人对 Phoenix channels 进行了基准测试。事实证明他们没有，但核心团队的一些成员认为我提供的 1k 数字非常低。这就是本次旅程的开始。

## 如何运行基准
### 服务器

要对同时打开的 Web 套接字的数量进行基准测试，首先需要一个 Phoenix 应用程序来接受这些套接字。对于这些测试，我们使用了[Gazler/phoenix_chat_example](https://github.com/chrismccord/phoenix_chat_example)提供的[chrismccord/phoenix_chat_application](https://github.com/Gazler/phoenix_chat_example/tree/bench)的略微修改版本- 主要区别在于：

- 广播用户已加入频道的after_join钩子已被删除。在测量并发连接时，我们希望限制发送的消息数量。这方面可以在将来进行基准测试。

大多数这些测试都是在[Rackspace 15 GB I/O v1](http://www.rackspace.com/cloud/servers#dd-wrap-iov1)服务器上进行的——这些机器有 15GB RAM 和 4 个内核。[Rackspace](https://www.rackspace.com/)让我们免费使用其中 3 台服务器进行基准测试。他们还让我们使用具有 128GB RAM 并在 htop 中显示 40 个内核的[OnMetal I/O服务器](http://www.rackspace.com/cloud/servers) 。

![001](/images/blog/0002_001.png)

需要进行的另一项更改是删除check_origin–conf/prod.exs，这意味着无论使用的 IP 地址/主机名如何，都可以连接应用程序。

要启动服务器，先git clone然后运行：

1. MIX_ENV=prod mix deps.get
2. MIX_ENV=prod mix deps.compile 
3. MIX_ENV=prod PORT=4000 mix phoenix.server

您可以通过访问YOUR_IP_ADDRESS:4000来验证是否有效。

### 客户端

为了运行客户端，我们使用了[Tsung](http://tsung.erlang-projects.org/)。Tsung 是一个开源分布式负载测试工具，可以轻松地对 websocket（以及许多其他协议）进行压力测试。

分布式的Tsung 工作方式是使用主机名。在我们的示例中，第一台机器被称为“phoenix1”，是在/etc/hosts进行的ip 分配。其他机器“phoenix2”和“phoenix3”也同样.

在与 Phoenix 应用程序不同的机器上运行客户端以进行基准测试非常重要。如果两者都在同一台机器上运行，结果将不是真实的表示。

Tsung 使用 XML 文件进行配置。您可以阅读[文档](http://tsung.erlang-projects.org/user_manual/index.html)进行配置。这是我们使用的配置文件（但是数字已经降低以反映这里的客户端数量，对于我们更大的测试，我们使用了 43 个客户端）。它每秒启动 1k 个连接，最多可达 100k 个连接。对于每个连接，它都会打开一个 websocket，加入“rooms:lobby”主题，然后休眠 30000 秒。

我们使用了较长的睡眠时间，因为我们希望保持连接打开，以查看在所有客户端连接后应用程序的响应速度。我们将手动停止测试，而不是关闭配置中的 websockets（您可以使用type="disconnect"）。

<Code language="xml">
{`<?xml version="1.0"?>
<!DOCTYPE tsung SYSTEM "/user/share/tsung/tsung-1.0.dtd">
<tsung loglevel="debug" version="1.0">
 <clients>
 <client host="phoenix1" cpu="4" use_controller_vm="false" maxusers="64000" />
 <client host="phoenix2" cpu="4" use_controller_vm="false" maxusers="64000" />
 <client host="phoenix3" cpu="4" use_controller_vm="false" maxusers="64000" />
 </clients>

 <servers>
 <server host="server_ip_address" port="4000" type="tcp" />
 </servers>

 <load>
 <arrivalphase phase="1" duration="100" unit="second">
 <users maxnumber="100000" arrivalrate="1000" unit="second" />
 </arrivalphase>
 </load>

 <options>
 <option name="ports_range" min="1025" max="65535"/>
 </options>

 <sessions>
 <session name="websocket" probability="100" type="ts_websocket">
 <request>
 <websocket type="connect" path="/socket/websocket"></websocket>
 </request>

 <request subst="true">
 <websocket type="message">{"topic":"rooms:lobby", "event":"phx_join", "payload": {"user":"%%ts_user_server:get_unique_id%%"}, "ref":"1"}</websocket>
 </request>

 <for var="i" from="1" to="1000" incr="1">
 <thinktime value="30"/>
 </for>
 </session>
 </sessions>
</tsung>`}
</Code>

## 第一个 1k 连接

Tsung 在8091端口提供了一个 Web 界面，可用于监控测试状态。我们对这些测试真正感兴趣的唯一图表是并发用户数量。所以我第一次运行 Tsung 是在我自己的机器上， Tsung 和 Phoenix 聊天应用程序同时都在本地运行。这样做时，Tsung 经常会崩溃——发生这种情况时你看不到 Web 界面——这意味着没有图表可以显示，但它是一个不起眼的 1k 连接。

## 又是第一个 1k 连接！

我远程设置了一台机器并再次尝试进行基准测试。这次我获得了 1k 连接，但至少 Tsung 没有崩溃。其原因是已达到系统范围的资源限制。为了验证这一点，我运行了ulimit -nwhich 返回1024，这可以解释为什么我只能获得 1k 个连接。

从这开始，使用了以下配置。这种配置将我们一路带到了 200 万个连接。

<Code language="bash">
{`sysctl -w fs.file-max=12000500
sysctl -w fs.nr_open=20000500
ulimit -n 20000000
sysctl -w net.ipv4.tcp_mem='10000000 10000000 10000000'
sysctl -w net.ipv4.tcp_rmem='1024 4096 16384'
sysctl -w net.ipv4.tcp_wmem='1024 4096 16384'
sysctl -w net.core.rmem_max=16384
sysctl -w net.core.wmem_max=16384`}
</Code>

## 第一个真正的基准

当 Chris McCord（Phoenix 的创建者）联系我告诉我 RackSpace 已经设置了一些实例供我们用于基准测试时，我一直在 IRC 中谈论 Tsung。我们必须使用以下配置文件设置 3 台服务器：https://gist.github.com/Gazler/c539b7ef443a6ea5a182

在我们启动并运行之后，我们将一台机器专用于 Phoenix，另外两台用于运行 Tsung。我们的第一个真正的基准测试以大约 27k 连接结束。

![002](/images/blog/0002_002.png)

在上图中，图表上有两条线，顶部的线标记为“用户”，底部的线标记为“已连接”。用户根据到达率增加。对于大多数这些测试，我们使用每秒 1000 个用户的到达率。

结果一出来，José Valim 就提交了一次[改进](https://github.com/phoenixframework/phoenix/commit/061c69b43c3b8c6fa19fd129d35a3a25ae767850)

这是我们的第一次改进，这是一个很大的改进。从这里我们得到了大约 50k 的连接。

![003](/images/blog/0002_003.png)

## 观察变化

在我们的第一次改进之后，我们意识到我们是盲目的。如果有某种方式可以观察正在发生的事情的话就更好了。幸运的是，Erlang 附带了[observer](http://www.erlang.org/doc/apps/observer/observer_ug.html)，它可以远程使用。我们使用 https://gist.github.com/pnc/9e957e17d4f9c6c81294 中的以下技术来打开remote observer。

![004](/images/blog/0002_004.png)

Chris 使用observer根据邮箱的大小对进程进行排序。:timer进程的邮箱中有大约 40k 条消息。这是因为 Phoenix 每 30 秒做一次心跳以确保客户端仍然连接。

幸运的是，Cowboy 已经解决了这个问题，所以在这次[提交](https://github.com/phoenixframework/phoenix/commit/7b252f42cc8552496a5ebd392f59a008ef6c98a9)之后，结果看起来像：

![005](/images/blog/0002_005.png)

实际上，在这张图片中我使用observer杀死了 pubsub 主管进程，这解释了最后的 100k 连接的下降。这是第二次翻番的性能提升。测试中使用 2 台 Tsung 机器提供 100k 并发连接。

## 我们需要更多机器

上图有两个问题。一是我们没有达到全部客户端数量（大约 15k 时进入超时状态），二是我们实际上只能为每个 Tsung 客户端生成 40k 到 60k 连接（每个 IP 地址存在技术上的上限）。对于 Chris 和我来说，这还是不够好。除非我们可以产生更多客户端负载，否则我们无法真正看到限制。

在这个阶段，RackSpace 给了我们内存 128GB 的服务器，所以我们实际上还有另一台机器可以使用，使用像 Tsung 客户端这样强大的软件而被限制在 60k 连接可能看起来很浪费，但总比机器闲置好！Chris 和我在我们之间设置了另外 5 个服务器，这是另外 30 万个可能的连接。

我们再次运行基准测试，我们获得了大约 33 万个连接的客户端。

![006](/images/blog/0002_006.png)

现在最大的问题是大约 70k 的连接并没有真正连接到机器上。我们不知道为什么。有可能是硬件问题。我们决定尝试在 128GB 机器上运行 Phoenix。这样达到我们的连接限制肯定不会有问题，对吧？

![007](/images/blog/0002_007.png)

但结果是错误的。这里的结果与上面的结果几乎相同。克里斯和我认为 330k 也相当不错。克里斯在推特上发布了结果，我们称之为一个阶段性成果。

> 可以称之为已经达到了最大的channels数量：大约333k并发客户. 它耗尽了8台服务器的最大端口来进行推送，还剩下大约40%的内存，但是我们没有服务器了。 - [Chris McCord (@chris_mccord) October 24, 2015](https://twitter.com/chris_mccord/status/657716607578472448)

## 了解您的 ETS 类型

在达到 330k 并发客户并获得 2 次相当容易的性能提升后，我们不确定是否还会有更多相同幅度的性能提升。但是我们错了。当时我并没有意识到这一点，但我在Voice Layer的同事 Gabi Zuniga ( [@gabiz](https://twitter.com/gabiz) )周末一直在研究这个问题。他的承诺给了我们迄今为止最好的性能提升。您可以在 [pull request](https://github.com/phoenixframework/phoenix/pull/1311)上看到差异。为方便起见，我也会在这里展示出来：

<Code language="git">
{`- ^local = :ets.new(local, [:bag, :named_table, :public,
+ ^local = :ets.new(local, [:duplicate_bag, :named_table, :public,`}
</Code>

这 10 个额外的字符使图表看起来像这样：

![008](/images/blog/0002_008.png)

它不仅增加了并发连接的数量。它还使我们也可以将到达率提高 10 倍。这使得后续测试更快。

bag和 duplicate_bag之间的区别在于duplicate_bag允许同一个键有多个条目。由于每个套接字只能连接一次并且有一个 pid，因此使用重复包不会对我们造成任何问题。

这次测试在大约 450k 连接时达到最大值。此时 16GB 服务器的内存不足。我们现在已经准备好真正测试更大的服务器了。

> 在phoenix channels benchmark上声称结束为时尚早，有了 [@gabiz](https://twitter.com/gabiz) 提供的优化，我们已经在4核/15G的服务器上获得了450k并发客户的成绩。 — [Chris McCord (@chris_mccord) October 25, 2015](https://twitter.com/chris_mccord/status/658393399821795328)

## 我们需要更多的机器

Justin Schneck ( [@mobileoverlord](https://twitter.com/mobileoverlord) ) 在 IRC 上告诉我们，他和他的公司Live Help Now将在 RackSpace 上设置一些额外的服务器供我们使用。准确地说，还有 45 台额外的服务器。

我们设置了几台机器，并将 Tsung 的阈值设置为 100 万个连接。这时 128GB 机器轻松实现的新里程碑：

![009](/images/blog/0002_009.png)

当 Justin 完成所有 45 个服务器的设置时，我们确信有 200 万个连接是可能的。不幸的是，事实并非如此。仅在 130 万个连接处开始出现一个新的瓶颈！

![010](/images/blog/0002_010.png)

就是这样。1.3M 连接就足够了，对吧？错误的。在我们达到 130 万订阅者的同时，我们在请求订阅单个 pubsub 服务器时开始定期超时。我们还注意到广播时间大幅增加，向所有订阅者广播的时间超过 5 秒。

Justin 对物联网感兴趣，并想看看我们是否可以优化 1.3+M 订阅者的广播，因为他看到了这些级别的真实用例。他的想法是通过分块订阅者和并行化广播工作来分割广播。我们尝试了这个想法，它将广播时间缩短到 1-2 秒。但是，我们仍然有那些讨厌的订阅超时。我们处于单个 pubsub 服务器和单个 ets 表的限制。所以 Chris 开始着手将 pubsub 服务器池化，我们意识到我们可以将 Justin 的广播分片与 pubsub 服务器池和 ets 表结合起来。因此，我们通过订阅者 pid 将其分片到一个 pubsub 服务器池中，每个服务器都管理自己的 ets 表。这让我们可以在没有超时的情况下达到 200 万订阅者并保持 1s 广播。代码改变正在进行中，这个提交在合并到 master 之前正在被完善。

所以你现在有了200万连接！每次我们认为不再需要进行优化时，就会提出另一个想法，从而大幅提高性能。

200万是我们满意的数字。但是，我们并没有完全使用机器，我们还没有做出任何努力来减少每个套接字处理程序的内存使用量。此外，我们还将执行更多基准测试。这组特定的基准专门围绕同时打开的套接字数量设置。拥有 200 万用户的聊天室非常棒，尤其是在消息传播得如此之快的情况下。不过，这不是典型的用例。以下是一些未来的基准测试想法：

- 一个频道，x 个用户发送 y 个消息
- X 个频道，有 1000 个用户发送 y 个消息
- 跨多个节点运行 Phoenix 应用程序
- 模拟发送随机数量的消息，用户随机到达和离开，表现得像真正的聊天室

在此基准测试中发现的改进将在即将发布的 Phoenix 版本中提供。密切关注未来基准测试的信息，Phoenix 将继续推动现代网络的边界。

Phoenix 200 万个 Websocket 连接之路


如何在 2022 年为应用选择最佳的 Web 编程语言和框架？这是可能吗？我相信是的，在这篇博文中，我将尝试说服您为什么 Elixir 和 Phoenix 是您正在寻找的完美组合。

## Elixir: 生产力等于更少的成本

生产力仍然是编程语言的一个被大大低估的特性。一般来说，市场上的大多数应用程序都必须实现一些业务目标，众所周知，我们产生的成本越少，利润就越高。

编程劳动力并不便宜，这就是**生产力很重要**的原因。简而言之，如果我们可以编写更少的代码同时提供相同的功能，我们认为编程语言是高效的。这就是[Ruby](https://www.ruby-lang.org/)被赋予生命的原因，虽然从设计上讲，它不是一种可以用来创建高性能应用程序的技术，但它实际上做了一件非常好的事情——它非常高效。它实际上仍然是，这就是为什么你可以找到如此多的大型应用程序，比如Shopify是基于它的。那么…为什么不选择 Ruby 呢？

在某些情况下，生产力是有代价的，对于 Ruby 来说，这是一个性能和可扩展性问题，这就是我们如何找到这篇博文的主角 – [Elixir](https://elixir-lang.org/)。这种语言的一个关键假设是支持良好的可维护性和易用性，同时不会让开发人员使用在广泛使用时可能会使代码库过于复杂的机制。

然而，上述并不是 Elixir 高效的唯一原因。让我们深入挖掘其强大的生产力能力。

## Elixir是一种函数式语言

听起来很奇怪吧？当然，许多开发人员会不同意它，但在多年面向对象编程之后，我认为 Elixir 在易用性方面是生产力的圣杯。一旦你掌握了这种语言的基本概念，它就非常容易使用功能范式，最终很容易描述：

> 在函数式编程语言中，您使用不可变数据作为产生结果的函数的输入。相同的输入总是产生相同的输出。

与面向对象编程相比，函数式范式的核心假设给您信心。

## 它有一个简单的结构，可以做强大的事情

这种语言的设计非常周到。Elixir 中有两个核心概念——模块和函数。一旦你学会了这些，你就可以编写代码了。

整个应用程序被组织在模块中，这些模块用作创建基于域的功能分类的容器。没有类、接口、头文件和其他我们不需要编写工作和高性能应用程序的样板文件。

## 它使用现代编程语言解决方案

在 Web 编程世界中应该被认为是一流的机制已经在这里。例如，在 Elixir 中，您可以使用：

- 例如，您可以使用高级模式匹配技术根据参数的值创建多个函数版本。多么酷啊？
- 内置高级并发处理和代码的直接分布式执行（感谢[Erlang OTP](https://www.erlang.org/)）
- 管道运算符使函数处理流程非常清晰
- 匿名函数
- 元编程

仅举几例。简而言之，使用 Elixir，您不必担心使用旧机制来解决现代问题。

## 结果你写的代码更少

这种语言中使用的简洁明了的架构设计和现代编程技术使您可以编写更少的代码，就像在 Ruby 中一样。

![elixir advance](/images/blog/0001_001.png "elixir advance")

## 出色的可扩展性

Elixir 建立在 Erlang 虚拟机 (Erlang VM) 之上，并利用了它的所有优点。让我快速描述一下为什么 Erlang 会被赋予生命：

> Erlang 运行时系统专为具有以下特征的系统而设计：分布式；容错；软实时；高可用；不间断的程序；热交换，可以在不停止系统的情况下更改代码。

听起来像是每个开发者的梦想，对吧？

根据Cisco的说法：“90% 的互联网流量都通过 Erlang 控制的节点”，同时，由 Erlang VM 处理的电话系统中仍有大量流量。Erlang 被设计为在高可用性、可伸缩性、容错性和性能很重要的环境类型中运行。

为什么你会关心 Web 编程中的 Erlang？好吧，一旦您的应用程序获得了一些真正的流量，它就需要轻松扩展，并且不能同时中断。[这是许多初创公司创始人在开发他们的第一个最小可行产品（MVP）](https://curiosum.com/blog/what-is-mvp-and-why-you-should-choose-elixir)时没有考虑到的。

一旦您的应用程序变得流行，您不能只考虑将其切换到另一种编程语言。在这一步明智地选择意味着未来的成本要低得多，这就是 Elixir 的亮点——它不仅高效，而且还允许您扩展。你需要证明吗？[Discord](https://discord.com/)能够通过 Elixir 扩展到 5000000个并发用户。

## 难以置信的稳定性

如前所述，Elixir 的特性之一是出色的容错能力（继承自 Erlang）。如今，对于企业及其客户而言，停止交付因停机而导致的数字化产品或服务是不可接受的。

让我们看一些数字（[来源](https://www.atlassian.com/incident-management/kpis/cost-of-downtime)）：

- 2015 年 3 月，12 小时的 Apple Store 停电使公司 损失了 2500 万美元；
- 2016 年 8 月，一个运营中心停电 5 小时，导致 2,000 个航班取消，达美航空估计损失 1.5 亿美元 ；
- 2019 年 3 月，一次 14 小时的中断使 Facebook 损失 了大约 9000 万美元。

更不用说最近的 Facebook 中断导致该公司损失了近 1 亿美元的收入，并导致许多用户的信任度大幅下降。

正如您所看到的，没有停机时间，这是您在构建 Web 应用程序时应该考虑的编程语言的另一个特性。Elixir 提供稳定性。

## Elixir成熟度

一些开发者会说 Elixir 不够成熟，它只是一种小众语言。我不同意。虽然它自 2014 年就已经存在（第一个发行说明可以在这里找到），但说它只有 7 年的历史并不合适。

Elixir 是基于 Erlang 的，它继承了它的所有优点和经验。由于 Erlang 自 1986 年就存在，可以肯定地说，与大多数著名的 Web 编程语言相比，Elixir 是最成熟和经过验证的语言。如果不考虑 Erlang，就无法描述 Elixir 的功能。

同时，也有大品牌在使用 Elixir 和 Erlang。让我们仅举几例：

- Discord – Elixir 帮助他们扩大规模；
- WhatsApp – 看看为什么他们只需要 50 名工程师就可以处理 9 亿用户；
- 百事可乐 -查看一个很好的案例研究；
- Spotify – 在这里聆听它背后的故事，
- Heroku 案例研究可在此处获得。

使其成熟的不仅是大公司的广泛生产采用，还有编程库的可用性。现在对我来说可以肯定地说，在 Elixir 生态系统中，您几乎可以找到适用于您需要的任何用例的库。当然，可能需要为第三方服务编写一些 API 客户端代码，但无论如何您都不会面对最流行的编程语言。

这一切让我觉得Elixir毕竟是成熟的。

## 很棒的 Phoenix Web 框架

Phoenix 框架是 Elixir 的亮点。它以一种非常优雅的方式内置，并为您提供构建强大的 Web 应用程序和高级 API 所需的一切。一旦您了解了Phoenix 中的Plug.Conn是什么。您开始将应用程序视为具有不同职责的一组层。这很有帮助。

使用[Phoenix](https://www.phoenixframework.org/)和[Absinthe](https://github.com/absinthe-graphql/absinthe)，您可以构建现代 GraphQL API。由于对 [WebSocket ( Phoenix Channels )](https://hexdocs.pm/phoenix/channels.html)的内置支持，您可以在一台机器上同时处理超过 200 万用户！这有多疯狂？

然而，真正将 Phoenix 与其他现代 Web 框架区分开来的是[Phoenix Live View](https://hexdocs.pm/phoenix_live_view/Phoenix.LiveView.html)。这只是构建反应式实时服务器渲染 HTML 的绝佳方式。这是什么意思？这意味着在大多数情况下，您可以忘记编写 JavaScript 和 React。您可以留在 Elixir 世界中，在服务器端定义实时组件，无需 JS 代码。

## 安保与安全

有一些充分的理由声称 Elixir 是安全的。

首先，Elixir 对不可变数据进行操作，这最终意味着不会有数据处理的副作用。函数式编程语言的这一特殊特性有一些非常好的好处。它允许您以可预测的方式编写和测试代码，并为您节省大量调试时间。如前所述，函数式语言没有副作用，这是一种解脱。

其次，Phoenix 框架具有定义明确的层，由于其功能性，这些层更容易控制。您可以清楚地看到请求处理的每个步骤，这使得导航更容易，因此可以生成安全可靠的应用程序。

最后，如果您研究 Elixir 的用例，您会发现它用于金融服务（如Klarna）以及大型消息传递应用程序（如 Discord）。不会破坏或泄漏的商业大型应用程序只是 Elixir 和 Phoenix 安全性的绝佳证明。

## 社区和开发者的满意度

Elixir 社区非常有帮助和支持。快速浏览一下[Elixir 论坛](https://elixirforum.com/)就可以证明这一点。从我的角度来看，这一切都归结为程序员的满意度。Elixir 不仅在最受喜爱的编程语言中名列前茅，而且收入也是最高的。如果您考虑招聘，这是一个很大的优势。

你可以选择更流行的语言，但毕竟你要明白程序员的满意度和参与度才是带来结果的。

## 伟大的创造者和维护者

幕后的人是Elixir的力量。我有信心说 José Valim（Elixir 的创造者）是 Elixir 如此出色的语言的主要原因。他是一个非常聪明和多产的人，你会经常看到他参与关于 Github 问题或论坛的讨论。他作为 Ruby 核心贡献者的经验在创建 Elixir 的过程中带来了红利，它现在结合了各种编程语言的最佳优势。将编程语言的发展导向正确的方向并不容易。他在这一步做得很好。

![José Valim](/images/blog/0001_002.png)

Phoenix Framework 的创建者 Chris McCord 是另一个谦逊而敬业的人，他为我们带来了一些很棒的东西，比如 Phoenix Live View，你在其他地方很难找到。

## Elixir & Phoenix – 2022 年现代 Web 应用程序的绝佳选择

查看 Google 趋势中的编程语言流行度图表并不足以为 Web 应用程序选择一种编程语言。您必须了解该技术的所有功能才能做出可靠的决定。Elixir 拥有一切——生产力、稳定性、安全性和可扩展性。它也受到程序员的喜爱，大公司在生产中使用它。

为什么您会在 2022 年为 Web 应用程序选择一种编程语言，它可以让您快速创建 MVP 但无法扩展？明智地选择，Elixir 可能就是你要找的那个。
