Erlang十年编程


大约10年前,我在炒作的第一阶段中期加入了Erlang社区。 有人告诉我们Erlang是竞争和并发的未来。 用这种语言实现它们是最简单,最快的,您仍然可以免费分发。 当时,未来似乎不可思议。 该虚拟机最近已获得SMP支持,但是为了真正使用所有处理器,您必须在同一台计算机上运行多个虚拟机。

我想回顾一下过去的十年。 在本文中,我将讨论有关Erlang的炒作阶段,有关语言的思想阶梯及其对语言分布的可能影响,这十年来我经历了哪些变化。 最后,我将分享我对Erlang尚未带给整个程序员社区的想法。

炒作阶段


炒作周期包括产品或技术生命周期的各个阶段。 这是一种营销概念,而不是科学的概念,但通常有助于描述正在发生的事情的本质。 我最感兴趣的是炒作阶段 ,这是一种覆盖程序员社区的淘金热。 也许您遇到了不止一次,并且所有这些阶段都与每个人都急着使用的杀手级应用程序相关。

我马上想到的例子是Ruby on Rails, 如何在15分钟内构建博客引擎 (短语“看看我不做的一切!”仍然很有趣)或与Kubernetes一起使用(在此之前他们一起工作过,以及然后直接增加了)。 这包括Elixir和Phoenix。

在炒作阶段,有大量新人涌入,他们想看看大惊小怪的是什么。 剩下的人,大多数离开。 您可以居住数月或数年,在极少数情况下,您会找到几十年的家。 但是,绝大多数是不断涌现的从技术过渡到技术的连续人员,他们寻找机会从他们首先使用框架,语言或工具包这一事实中受益。

因此,大多数情况下,您需要制作一个真正的“杀手级应用程序”,然后人们才能进入您的生态系统。 杀手级应用激发了人们的兴奋。 如果您写了,他们会来找您的。 而且,如果您可以保留其中的一小部分并使它们保持活动状态,那么在可预见的将来,您将拥有一个充满活力的社区。 这有点使人联想起雨后的想法:

上帝驱动耕作机... ...采用这种奇妙的装置,这是人类对大自然的唯一控制权,乌云倾盆大雨... [犁]是一种将文明与野蛮人分开的工具,它将沙漠变成了农田和花园。 简而言之,下着犁。

该理论的实质是人类的居住和农业对干旱和半干旱地区的气候产生不可逆转的影响,使这些地区更加潮湿。 这种理论在1870年代得到广泛传播,作为定居大平原的理由,大平原以前是美国大沙漠地区。 在那些年里,这一理论被用来证明在南澳大利亚边缘地区扩大小麦作物的合理性。

如果我们可以启动一个大型项目,那么开发人员将出现,并且将变得自给自足。 我认为这个想法显然是错误的,主要是因为在最大的炒作阶段,Erlang有数十个杀手级应用程序,但是社区仍然很小。 以下是这些应用程序的示例:

  • ejabberd (2002年,2005年第一个稳定版本):它是最大(甚至不是最可扩展)的聊天服务器之一。 埃贾伯德取得了巨大的成功,并且在某种程度上仍然有意义。 今天,在StackOverflow上仍然存在有关此服务器模块的问题。 在2011年左右,他加入了MongooseIM ,并且仍然支持这两种解决方案。
  • CouchDB (2005):基于CAP定理 ,用Erlang编写的最受欢迎的数据库之一。 它是指多主存储库出现的时间。 尽管MongoDB占据了大部分市场,但CouchDB在诸如BarrelDB之类的存储引擎中具有精神上的继任者,但仍受支持。
  • RabbitMQ (2007):消息队列服务器,压垮了大多数AMQP市场。 尽管这些产品具有不同的功能和应用程序,但在流负载方面,它一直在发展并经常与Kafka竞争。
  • Facebook chat (2008):Facebook Chat的初始版本是用Erlang编写的。 由于多种内部原因(稳定性,大量的C ++程序员和许多已建立的解决方案),后来将其重写为C ++。
  • WhatsApp (2009年,2014年购买):当Facebook摆脱Erlang聊天系统时,他们购买了WhatsApp, 这只需要50位工程师才能支持9亿用户 。 他一直活到今天,而且,WhatsApp团队进一步加强了与Erlang和Elixir社区的联系。
  • Riak (2009):在分布式系统领域展示能力的最好例子之一。 Riak是可靠的键值类型的分布式存储。 这是Basho产品,仍可在医疗保健系统和其他关键基础设施部件中使用。 后来,Basho破产了(很大程度上是由于违反信托义务“全速导致公司倒闭” )。 然后Bet365购买了他们所有的IP,慷慨地开放了它们,从那以后数据库一直生活在开源世界中,尽管今天它正处于艰难时期。

其中许多产品是在Joe Armstrong的《 Programming Erlang》一书的第一版中发布的 。 结果,这种语言的受欢迎程度开始爆炸式增长,而Erlang赢得了很多崇拜者。 甚至, Hacker News迫使所有关于Erlang Innards的讨论都产生了重大影响。 但是,很少有人忠于这种语言。

现在,我相信杀手级应用程序是由构成炒作初始阶段的人们创建的,反之亦然。 总是有一小部分人在其他人之前先找到有趣的技术,确定他们是否喜欢它们,然后再创造一些东西,如果您拥有杀手级应用程序,它将刺激更强大的炒作阶段的发展。 人们将从事货物崇拜,成功的项目将产生模仿者。 同样,标准情况是“发明轮子”的阶段,那时每个人都花时间重新发明现有的东西,并且有一波关于“实现X,但是用Y语言”的信息。

但是,仅创建杀手级应用程序还不够。 奇怪的是,所有这些产品,例如RabbitMQ和Ejabberd,尽管很受欢迎,但其用户社区比开发人员社区大得多。 数以千计的使用这些产品的公司不一定会对Erlang社区做出重大贡献。

部分原因是大多数杀手级的Erlang应用程序都在专用基础架构中使用。 您以黑匣子的形式创建了一个高度可靠的组件,每个人都可以使用它,如果运行良好,则没人会看内部。 数十位开发人员为数千种其他产品和服务奠定了基础。 根据定义,专用基础结构不需要大量人员来确保其广泛的影响。 与更接近最终产品的技术(例如,Web框架,甚至是适用于任何公司的小型部署项目中使用的更通用的基础结构)相比,它总是只有很少的开发人员和较小的社区。

但是尽管如此,很显然,Erlang在炒作阶段错过了很多人。

楼梯的想法


我不会抱怨可以或应该做些什么。 相反,我想谈一谈我多年来在该语言的教学和编程过程中在Erlang社区中遇到的流行学习模式。 我今天在Elixir社区中观察到相同的模式,这可能对他来说意味着相似的未来。

我有一种理论认为,诸如编程语言(及其生态系统)之类的技术主题在不同概念所处的复杂性上有多个层次。 我在“ 学习一些Erlang”项目中使用了这一理论。 它显示在图中,我称之为九伯爵圆

当然,这是一个具有讽刺意味的想法,我认为对技术的研究不会带来无尽的痛苦(至少不应如此)。 我只是喜欢双关语。 简而言之,在学习技术时,总会有某种“主要”路径或学习顺序—这是“思想阶梯”,概念在阶梯上的位置越高,实现的价值就越高,难度就越大,人们就越少认识她

Erlang中的思想阶梯可能是什么样的:

  1. 功能编程。
  2. 孤立的流程和竞争力。
  3. 可靠的竞争力(链接,监视器,超时)。
  4. OTP原理和其他系统抽象。
  5. 如何根据OTP原理构建系统。
  6. 如何收集发布并与它们一起使用(部署)。
  7. 如何防止系统崩溃并使用它。

如果您只是了解Erlang并为初学者买书,那么您很可能会在阶梯的第一步上花费很多时间:熟悉函数式编程,不变性(immutability),递归和其他类似概念。 迟早您将获得竞争力和并行性,流程和消息传递。 在它们之后,您将立即开始学习链接和监视器,处理故障以及Erlang的作用。 在大肆宣传的阶段,第二步和第三步包含的机会对于大多数观察者来说简直是难以置信的。 如果您需要学习将在以后的所有项目中使用的内容,则可以选择以下Erlang功能之一。

您可以稍后再执行其他步骤,但前提是您必须遵守循序渐进的培训计划。 特别是,OTP(第四阶段)可以描述为“全部内容”。 竞争能力和功能性编程都不错,但是OTP提出的整个框架确实是独一无二的,需要使用。 随着时间的流逝,许多人将与他一起工作,发现他们可以创建很酷的抽象,但是他们不喜欢构造方法。

实际上,创建像Ejabberd这样的应用程序足以克服第四步。 那时,生态系统类似于狂野的西部,而OTP的知识则归爱立信的工作人员所有,并且是最有动力的自学成才。 大多数人从未进入第五阶段,除非他们将某些东西发送到生产中,然后遇到问题,或者他们没有寻找更好的解决方案。 直到2015-2016年,第六步的成就都是罕见的,然后Relx出现了,这简化了发行版的组合及其开发。 几乎没有人到达第七步,许多人认为他们不应该对Erlang节点执行热更新,并且理想情况下,您将永远不需要在生产中使用SSH进行调试。

在实践中,并不是每个人都按照相同的顺序上进阶梯;在某些书中,其步骤是相反的(例如,在Erlang和OTP in Action中 )。 毫无疑问,楼梯是作为一个插图而发明的。

社区的规模在不断变化。 在大肆宣传的阶段中,一段时间的大小可能会增加数十倍或数百倍,所有这些人都会好奇并离开。 大多数参与者坐在楼梯的第一步,很少将其抛在后面。 有些上升到第二阶段,甚至没有上升到第三阶段,依此类推,直到达到最高级别的狭窄专家圈为止。

我认为攀登Erlang的前三步很容易。 要升到第四位,有必要发展几年,并且确实感到有必要进一步研究。 第五步已经很困难。 Erlang的工具包和生态系统都很差。 社区成员忍受着这种贫瘠的环境,对新移民的困境漠不关心。 为了使文章简短(长,长,但不长),请在Erlang用户大会上看我关于语言生态系统的话题:


如果您在Elixir上写文章,那么您可能会看到站在这个人造楼梯的哪个步骤,并且您已经可以想象社区在其中分布的比例。 许多参与者仅在凤凰城就很流利,但很少能超越第四步,而且很多人都停留在第三和更低的位置。 通常这足够了。 我不怪,只分享观察。 就像任何人一样,我已经走了很多步(可能还有更多步骤要走,例如“修补虚拟机”之类的东西),我看到这些人并不了解很多。 但老实说,所有这些信息可能对他们毫无用处。 那很好。

我想说的是:我认为,作为一个社区,我们很可能在我们下面看到一些母狗,这使得很难在基本水平以上掌握思想阶梯。 有些主题需要慢慢研究,而在某些主题中,盲人会导致盲人,因为Erlang很小,我们只有很少的人可以分享所有必要的经验。 如今,它变得更简单了,如果您没有在炒作阶段来过Erlang,您可能会得到帮助,因为同时请求帮助的人越来越少。

我想,如果第二阶段的炒作明天在Erlang世界开始,那么我们将比我来时的大浪潮更好地接受新来者。 我希望这种经验,再加上Erlang和Elixir社区之间的紧密合作,将使我们成功扩大使用这些语言的机会加倍。

发生了什么变化


Erlang不会在烧瓶中游泳,等待将其拉入灯光。 它在不断发展。 部分原因是由于Elixir社区的竞争和建议,幸运的是,人们对Elixir工具的期望比对Erlang用户的期望高得多。 发展部分取决于行业的迫切需求和学术界的意愿。

我认为有人会对自2009年或更早以来发生的这些变化感到满意:

  • 现在,多核支持效果很好。 以前,如果有2-4个以上的内核,则系统会遇到各种不受应用程序开发人员约束的瓶颈。 然后就可以使用12-16个内核。 今天,我什至不知道上限是多少,但是我编写并管理了可以在32个以上内核上工作的堆栈,没有任何问题。
  • 堆栈跟踪现在具有行号。 在数字出现之前回到过去几乎是不可想象的。 在那些年里,“编写简短的自文档功能”不是体系结构的问题,而是生存的问题。 您现在可以调试Erlang程序而无需使用超自然的调试技能,尽管它们永远不会受到伤害。
  • 目前可以接受Unicode支持质量。 字符串模块包含最重要的算法,而unicode模块在大多数类型的转换和规范化方面做得很好。 有使用代码点UTF-8,UTF-16和UTF-32的典型方法。 区域设置支持仍然有很多不足之处,但是其他所有功能都可以使用。 当使用Unicode时,诸如re(用于正则表达式的模块)之类的模块以及用于处理文件的所有高级功能也没有问题。
  • 支持使用显式模式匹配语法的地图(实现为HAMT )。 在Dialyzer的帮助下,对它们进行了类型分析,这使得它们可以用于需要付出巨大努力才能使用记录的情况。
  • 现在,虚拟机使用出色的机制来处理时间 ,它们可以应对时标的变化,不同类型的时钟等。 但是,在社区开发的库的帮助下,使用时区和格式化时间会更好。
  • 添加了诸如原子计数器持久性术语之类的高性能工具,以帮助改善监视工具和低级基础库的各种机制。
  • 所有信号处理都变得异步 ,包括使用端口 ,这使我们摆脱了许多瓶颈。
  • 该编译器已被重写,并且仍在被重写,以增强使用SSA的高级分析和性能
  • NIF中有一种特殊的调度程序-脏调度程序,它简化了用c甚至rust编写的代码的集成,同时支持CPU和I / O密集型进程。 因此,尽管语言本身并没有变得更快(尽管有所进步),但连接高性能库变得更加容易,而又不会过度影响虚拟机的稳定性。
  • 已经对分配和管理内存的机制进行了各种改进
  • 得益于对微状态的更快速,更灵活的跟踪和计算 ,该程序的分析变得更加准确和快速。
  • gen_statem的OTP行为更加灵活,允许实施可选择性处理输入数据的有限状态机。
  • 新的和改进的日志记录框架 ,内置对结构化日志的支持。
  • 加密模块被重写并使用NIF而不是更复杂(且更新速​​度通常较慢)的驱动程序。
  • 使用NIF完全重写了文件驱动程序,从而大大提高了性能。
  • 为了获得相同的性能,他们继续使用NIF重写网络驱动程序。
  • 完全重新设计了SSL处理TLS的使用。 当我在Heroku工作时,我们试图使该产品在延迟(可能会降低5%)和可预测性方面大大超过(比99%降低10到30倍)方面与C ++解决方案具有可比性。
  • 大大提高了ETS性能。
  • 我写了一个在Erlang虚拟机上管理和调试生产系统指南
  • 全新的构建工具( rebar3 )与Erlang生态系统的统一软件包管理器集成在一起
  • , . Elixir, Efene, LFE, Luerl, Clojerl Gleam Alpaca.
  • Erlang.

, . , OTP Ericsson 13-16 ( 22!), Erlang . , Ericsson. Erlang Elixir, Erlang VM , Erlang Ecosystem Foundation , , , (observability — ), , ..

, , , , , , , , , Erlang . .

Erlang


, , 2007-2009, , . Erlang , . , , BEAM Conf. (Property-Based Testing), Erlang Elixir . , . , .

? , , , . , Elixir. , , , . , . , . . , . Erlang, , .

, Erlang . , , Erlang-, Erlang-: , , . , .

Erlang -, Elixir-.

, , Erlang . , . Erlang , . , .

, . ? ? , - ? , , ? ? , ? « - »?

, , « ». , Erlang . , . junior senior-, , , , .

, 15 ( , ), . , 系统,以及它们的创造并使其处于工作状态。每个人都有自己的动力。

我无法想象我会在另一个社区得到很多。这十年来真是太神奇了。令人好奇的是,Erlang社区仍然很小,其潜力没有被发现。这意味着有很多机会参与到所有事物中,与充满智慧并想要分享的人面对面交流,并找到自己的位置。

PS。感谢您翻译mail ru group;电报中的Erlang社区(Evgeny M.,Sergey Ivanov,Vladimir Sekisov,Greg)

Source: https://habr.com/ru/post/zh-CN460115/


All Articles