自从我专注于长生不老药的职业生涯以来，我已经注意到我更喜欢开发软件的方式发生了变化。它让我有更大的想法，在减少摩擦和恐惧的情况下发展。我不想回去。
许多人被介绍给Elixir是因为它关注并发性。JoeArmstrong甚至称Erlang是一种“面向并发”的语言。(注意：我的大部分观点对于任何BEAM语言都是通用的，但是我的经验来自于药剂的观点，所以请原谅我的术语有偏见)。我发现考虑并发性是一个更原始的关注点的逻辑结果是有帮助的：故障容忍。实现束式容错来自孤立的进程，即使它们崩溃也不会影响任何其他进程，再加上当另一个进程死亡时得到通知的监督进程。
流程的核心是包含由错误造成的损害的“爆炸半径”。碰巧的是，能够实现这一点的隔离特性也使它们成为并发的极佳候选者。
当我第一次听到二郎社区的“让它崩溃”的咒语时，根据我之前的开发经验，它听起来很疯狂。重要的是要理解，这不是不负责任的许可证，也不是我们不应该关心系统崩溃的许可证。它的核心是认识到我们的系统会有错误(即使我们写的是没有bug的代码，硬件最终也会让我们出错)，而且有了一个管理损害“爆炸半径”的体系结构，那么系统的小部分崩溃就不再是一件可怕的事情了。
更少的恐惧-好的，请！我已经学会了用“爆炸半径”作为何时到达进程的驱动程序来编写我的灵丹妙药代码。即使在我不需要并发的情况下，我也会使用一个进程来封装可能导致错误的损害。我使用监督树和持久的工作队列来从进程的严重或崩溃中恢复。我已经学会了更喜欢插入而不是插入，这样可以安全地重试我的逻辑，从而实现更大的幂等。在我编写的任何灵丹妙药代码中，这两个关于包含可能的错误和幂等的过程的想法已经成为我的第二天性。
这种从错误中自动恢复的能力改变了诸如测试覆盖率强制、静态类型、广泛的代码审查等主题的面貌。从本质上讲，所有这些都是为了防止在第一时间引入错误(是的，我也认识到它们的次要好处)。这些仍然是好事(我不是在提倡不负责任)，但有了BEAM提供的坚实的安全网，我们可以从不同的角度来看待它们，并看到它们确实给交付软件增加了一些摩擦和惯性。也许在某些情况下，我们可以减少对它们的依赖，以提高交货速度。更少的恐惧意味着更多的选择自由。
灵丹妙药重新点燃了我对软件开发的兴趣。通过Erlang和BEAM历史，我发现分布式系统中有大量的智慧，我可以从中学习，并且在我的工具箱中找到了如何思考软件的新工具。由于进程如此轻量级、无处不在，并且提供了免于崩溃的恐惧，我的视角以令人兴奋的方式发生了转变。如果我认为我在写一个“Web应用程序”，那么我的想法马上就会受到限制。我现在考虑建立系统。我可以有更大的想法，因为我有更好的抽象概念来构建它们。
一些团队乐于使用Elixir来编写Web应用程序，以便将其应用到他们先前存在的微服务部署模型中。我敦促开发人员实现容错轻量级过程所支持的更宏大的想法。您可以认为每个进程都是一个逻辑微服务，但您不需要单独部署它、与json、容器、编排和分布式日志记录等进行序列化。您可以在单个BEAM版本中部署包含数百万个交互逻辑微服务的整个系统。
长生不老药和比姆肯定改变了我的游戏规则。当我构建系统时，我更加无所畏惧，我希望我能与其他人分享这种自由。光束把我宠坏了，不过是好的一面。