世界上有一种非常常见的模式，人们会将目标和结果混为一谈。当然，当我这么说的时候，很明显这两者是不同的，但当你不注意的时候，这种未经审视的假设还是会悄悄地出现，这是一种很难察觉的认知捷径，更难以提前防范并处理。在这种观点下，对我整篇文章中提出的论点问题的答复是："这引发了这样一个问题：为什么语言和库的设计者不借鉴Erlang行为背后的结构，而是复制轻量级进程和消息传递的想法呢？" 答案是，虽然Erlang有很多好的目标，但它们实现这些目标的结果并不是最前沿的。或者说，语言设计者并没有复制Erlang，他们不复制Erlang是正确的。我非常尊重Erlang。它们比当时的时代早了大约10到15年。然而，你会发现，即使你将Erlang的创建日期往后推10到15年，你仍然会处于过去。…
源讨论Erlang并不是关于轻量级进程和消息传递的原帖 274 条评论 · 导入时统计把你的经验，加入这段讨论。
> 然后，在这些消息总线的矩阵中，我们不需要 Erlang 的重启功能。我们有很多重启进程的方法，从 systemd，到 Kubernetes，到其他各种方式。 我基本上同意你评论中的所有内容（这显然来自于深厚的经验），但让我不断回到 Erlang 的想法——可能徒劳地尝试在实际使用的语言中实现类似的概念（包括开发一种在 C++ 协程中管理纤程的方法，这些纤程类似于 Erlang 进程，这样我就可以调试后台行为）——就是这些可重启和隔离的单元太小了，无法由操作系统和 systemd 或 Kubernetes 来管理：它们就像单个用户连接。虽然世界上有很多简单的方法可以实现无共享并发，…
完整原文> 在这句话的背景下，我所认为的那篇文章主题问题的答案是： > "这引出了一个问题：为什么语言和库的设计者不借鉴 Erlang 的行为结构，而是复制轻量级进程和消息传递的想法？" > [...] > 但对我们今天所处的世界来说，这是不值得付出的代价。我们不需要 Erlang 消息总线成为唯一的消息总线。Erlang 消息总线说实话并不好，如果你想要一个非 Erlang 进程与另一个进程通信，它甚至很糟糕。我们不需要 Erlang 消息总线。我们有十几种消息总线，有些在云中，有些是商业的，有些是开源的，有些还兼具保留功能（如 Kafka），它们都能更好地扩展，而且没有任何东西会把你绑定到 Erlang 的奇特数据类型上。 我问为什么他们不借鉴背后结构…
完整原文> 我们不再需要 Erlang 集群来实现冗余了。你只需要在消息总线上运行多个服务副本，并在多个系统上运行以实现冗余。 Erlang 的特点是，你根本不需要集群。冗余是内建在每个实例的运行时中的。当你以这种方式构建时，所有东西都可以自然地水平扩展，增加更多的处理器和/或物理节点。 在其他任何语言中，你无法做到这一点，除非从头开始为它构建整个系统。 使用多个系统进行冗余意味着依赖整个系统宕机。Erlang 的方式将这种影响限制为系统本身可能数百万个并行操作中的一个。使用其他系统进行冗余，这个服务器上进行的其他一百万个操作也会随之宕机。冗余级别之间的差异是显著的。 但我同意你的观点，我们………
完整原文> 但当混乱平息，最佳实践出现时，我认为这至少还需要至少5年的时间 这非常乐观。我30岁了，基本上没有希望在有生之年看到这种情况发生，而与此同时，BEAM 运行得很好。我同意你的所有观点，除了当你把2023年写得好像我们现在做得更好一样。在过去30年里，这个领域的研究并没有像你描述的那样产生太多成果。
完整原文> 我们不需要 Erlang 消息总线作为唯一的消息总线。Erlang 消息总线，坦白说，不是很好 我真心好奇为什么它不是很好。你是从非 Erlang 进程的角度来说的吗？还是特别针对远程消息而不是本地消息？
完整原文我不太确定 Erlang 的世界是全面的。它有非常集成的方式来传输东西，但我已经部署和运行的 Erlang 软件和其它东西一样被容器化，在同一个 K8s 集群中，和其它东西使用相同的控制方式，具有类似的特性标志和遥测功能，使用相同的 Kafka 流，以及相同的 gRPC（或 Thrift 或 Avro）消息，从操作员的角度来看，它们在集群中运行的方式与其他应用程序几乎不可区分，除了当其中一部分崩溃时生成的堆栈跟踪看起来不同。 它也提供了其他方式来做事，这在任何方面都不会限制或约束你的决定，而我维护的大多数现代 Erlang（或 Elixir）应用程序都是以相同的方式运行的。 你仍然可以获得进程间的消息传递（对内部进程），监督（使用共享无状态和/或不可变性…
完整原文"这引发了一个问题：为什么语言和库的设计者不借鉴Erlang行为背后的结构，而是复制轻量级进程和消息传递的想法呢？" 因为他们和Erlang的目标不同。 但当我有类似目标的人将这些想法带入其他语言时，我见过这种情况。 几年前我有一份工作，当时我们正在开发一个产品，其要求可能像电话交换机一样：高可靠性和健壮性，由外行人员拥有和操作，完全没有互联网连接的期望，我们希望尽量减少维护电话。 在那个项目期间，我一边学习Erlang，一边有了一个顿悟，第二天我兴奋地和软件架构师聊天，说我想到了我们的库和设计是从Erlang中借鉴的。有趣的是，这家伙对Erlang几乎一无所知，而…
完整原文从某种意义上说，这种“全面性”可以被视为一个优点而不是缺点。 是的，今天我们有整个生态系统的服务集合，可以提供上述的关键功能。这些技术各自都伴随着长长的依赖链、安全问题、维护工作量、普通的计算开销等等。 而与此同时，这项30年的技术提供了相匹配的功能（是的，尽管它的语法和对象类型让人同时感到眩晕和恶心），但所有的bug早已被消除或封存在琥珀中，就性能而言，它会比那些拖着一个Java虚拟机或一堆node_modules的替代方案强得多，还包裹在docker镜像和k8s yamls中。 我用yaws作为我的首选web服务器。它是坚不可摧的。它很简单*，而且只需工作。很难找到一个黑客能入侵它。…
完整原文尊重不同观点，分享具体经验。
登录后即可发帖、评论、转发和引用。