Erlang有哪些改变?

Erlang不是一具放在一个装满甲醛的玻璃容器里的尸体，等待在光天化日之下被带走——它一直在进化。部分原因是由于Elixir社区的压力和需求，幸运的是，他们对自己的工具的期望比Erlang用户已经习惯的要高。另外部分原因在于推动平台向前发展的实际工业需求，而不像学术界，他们只是按照他们自己喜欢的方式推动事情向前发展。

以下是我能想到的一些改变，大家可能很高兴知道有些变化在 2009 年或更早的时候就发生了：

• 多核支持现在工作得很好。最初支持2- 4 个内核的时候，开发人员经常碰到各种超出自己控制的瓶颈问题，后来就可以很好地处理12- 16 个内核了。而现在我不太确定能支持的内核上限是多少，但有一点我很确定，我写的堆栈操作运行在超过 32 个内核的机器上没有任何问题。

• Stacktrace异常跟踪报告支持行号。回到没有行号的年代几乎是无法想象的，在那个年代，“写简短的自我描述的函数”不仅仅是一个设计问题，也是一个生存问题。现在，你不再需要超自然的调试技能，就可以调试Erlang程序。

• Unicode支持现在可以接受。string模块包含最重要的算法，Unicode模块可以很好地处理大多数转换和规范化，处理raw codepoint、utf-8、utf- 16 和utf- 32 的一般策略已经具备。本地化支持仍然缺乏，但现在一切都可行，诸如re(用于正则表达式)和所有更高级别的文件处理代码之类的模块也可以很好地处理unicode。

• 支持映射(作为HAMTs实现)，具有明确的模式匹配语法。使用Dialyzer对其进行的类型分析也可以将其替换为多个使用案例，在这些案例中，以前使用的记录非常痛苦。

• 虚拟机中的时间处理机制是世界级的，在处理时间规整、各种类型的时钟等问题时，都可以很好工作。不过，时区和格式处理使用社区库仍然更好一些。

• 添加了atomics、counters和persistent terms等高性能工具，以帮助改进所有增强可观测性功能和较低级别核心库的底层机制。

• 所有信号处理都是异步的，包括端口，大大减少了瓶颈。

• 编译器正在重写中，以便通过SSA获得更高级别的分析和性能提高。

• 运行NIF的脏调度器已经可用，使得与C甚至Rust代码的集成变得简单，同时支持IO密集型或CPU密集型工作负载。因此，尽管该语言可能不会无限快，但它已经快过其它语言。在对运行时稳定性不造成太大影响的情况下，为获得更高性能的库而停机比以往任何时候都容易。

• 内存分配和管理的各种改进。

• 更快速、更灵活的实时跟踪和微观状态分析，以保证正确运行和性能调查。

• 更灵活的gen-statem OTP行为模式，以实现能够处理选择性接收的有限状态机。

• 新的改进的日志框架，内置对结构化日志的支持。

• 重写crypto加密模块以便使用NIF，而不是更复杂(通常更新速度较慢)的驱动程序。

• 使用NIF对文件驱动程序进行整体重写，以获得巨大的性能提升。

• 使用NIF对网络驱动程序进行重写的工作正在进行，以获得类似的性能提升。

• 对用于TLS处理的SSL应用程序进行整体重写。这让我想起我在HeloCu工作的日子，通过整体重写使其与C++解决方案在延迟(可能慢5%)方面具有竞争力，并且在可预测性方面总体上要好得多(大约10- 30 倍的提升)。

• ETS性能的主要改进。

• 我编写了一本关于如何使用Erlang VM操作和调试生产系统的手册(https://erlang-in-anger.com/)。

• 全新的构建工具(rebar3)，与Erlang生态系统的统一软件包管理器集成。

• 在虚拟机上还提供多种新的编程语言，具有可替换的库用法。包括(但不限于)Elixir、Efen、LFE、Luerl、Clojerl，以及至少两种使用Gleam和Alpaca进行类型推断的语言。

• 其它更多针对核心Erlang分发包的内部和外部的改进。

如果你有兴趣了解更多信息，你可以查看版本发布说明的完整列表(https://www.erlang.org/news/tag/release)。但简而言之，如果OTP 版本 13 到 16 的发布时间对爱立信(Ericsson)OTP团队来说有点晚的话(我们现在已经是版本22!)，那么他们使用Erlang对他们的旗舰产品中所做的最新投资确实是显而易见的。但即使在爱立信之外，一切都在发生变化。Erlang社区，以及Elixir社区和运行在Erlang VM上的其他语言的贡献者，都聚集在一起建立了Erlang生态系统基金会，现在它拥有一个活跃的工作组，帮助协调和解决有关构建和打包工具、可观察性工作、安全性、培训和采用等问题。

如果你像我一样，在大炒作初期加入Erlang，但又没有像我一样留下来，因为你觉得很多东西不可用或太棘手，你可能想再试一次，因为Erlang的语言的人类工程学及其生态系统已经大大改善。

Erlang将去向何方?

虽然没有必要像 2007 年到 2009 年那样突然出现大杀手级的应用程序，但这并不意味着没有任何项目显示出这种希望。Erlang仍然是许多公司的基础设施的不可缺失的部分，其最初的杀手级应用程序大多还在其上运行。我们也有很多有趣的新应用，就像每个BEAM配置文件显示的那样。我自己真的很喜欢基于属性的测试等概念，并且Erlang和Elixir拥有世界上最好的框架。尽管如此，迹象表明我们现在还没有进入炒作阶段。

会有另一个炒作阶段吗?也许有，也许没有。你可以说，Elixir会有下一个炒作阶段。生态系统都有足够的共同点，在一个地方学到的经验教训可以用到另一个地方。它们之间的相似之处多过不同之处。也许还有一个新的复兴时期，我个人不再那么在乎它了。我喜欢小社区，所以我对此感觉很好。Erlang不需要几何级增长来让我觉得乐在其中，它只需要可持续发展。

Erlang社区的规模大小也从来没有阻碍它在全世界发挥它的影响力。就我所知，Erlang一直处于这样一种状态，既没有足够的工作量满足Erlang开发人员的需求，同时没有足够的开发人员来完成Erlang的工作：这两个方面都有很多工作要做，但他们在地理位置上并不一致。面向偏远市场的公司和员工往往做得最好。而在Erlang之前无法轻易突破Webapp市场的地方，整个Elixir的就业市场现在只需稍加努力就能达到良性循环。

从一个更高的层面来看，你是否使用Erlang或类似的语言，这可能并不太重要。虽然我确实觉得它没有被充分利用而且它的价值被低估了，但最大的好处不是来自于运行一个使用它的系统。而是来自于学习可靠系统设计的基本原理，并在实际环境中吸收其经验教训。

我多年来听到的一类问题都和寻求指导有关。例如，我应该如何学习系统设计?关于构建分布式系统，你有什么好的建议吗?我应该做什么可以让系统变得更加健壮和容错?我怎么知道我的设计是模块化的，不会导致抽象泄漏?什么是良好的错误处理?有什么好方法可以让我知道优化工作还为时过早呢?声明(declarative)某个东西意味着什么?

我们总是喜欢简短易懂的解决方案，如食谱和最佳实践，但事实证明，大多数真正的答案都是“我花了很多时间学到的”或类似的东西。我可以坦诚地说，我的职业生涯中没有什么能比得上花时间在Erlang世界里，潜移默化地吸收社区里老手们的丰富经验。从数量上看，Erlang不是一个大的社区，但从任何其它指标来看，它肯定是富有的。几年后，我从一个初级开发人员变成了高级开发人员，在世界各地发表演讲，寻找方法把我获得的这些经验传授传大家，这其中大部分都归功于Erlang这个社区。

也许我在 15 分钟内还是写不出一个博客引擎(事实上，我不是一个快速开发人员)，但我已经成为一个更加可靠的开发人员和系统架构师，我认为这是一种非常有效的方式。再说一次，我在这里讨论的不是使用系统，而是构建它们并使它们工作。无论如何，激励人们的东西并不随处可见。

我无法想象我能在其他社区能得到这么多，过去的 10 年里发生的一切令人惊叹。有趣的是，Erlang社区仍然很小，大部分还没有开发利用。这意味着你有足够的机会参与到任何事情中去，与那些充满智慧的人一对一地进行交流，并为自己争取一席之地。

原文：https://ferd.ca/ten-years-of-erlang.html