Erlang 二十年,如何在编程语言中占据一席之地?

2019-07-24 10:03 稿源:CSDN公众号  0条评论

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

声明:本文转载自第三方媒体,如需转载,请联系版权方授权转载。协助申请

相关文章

相关热点

查看更多