… 在我工作过的几家工程组织中，每一家都变成了工程速度缓慢的泥潭，当团队减少所需的上下文时，他们看到了速度的提升和错误的减少。职责分离，允许独立运行的各个服务，更多的和更好的测试和可观测性，以及，是的，更好的类型。很多人认同这样的观点：“旧系统让我们走到今天，现在我们可以负担得起重写并正确地做事。” 真正的成本是， literally，数年开发人员的努力才能解开纠缠的职责。数百万到数千万的开发人员薪资正在被用于维持船只的漂浮，同时更换船体。机会成本是真正令人震惊的。为了避免这种成本：保持职责分离，定义数据域，并使用一种允许你将逻辑本地化的语言。如果你不得不跳转文件才能理解你的输入参数，当你无法在脑海中容纳所有内容时，你会遇到麻烦，尤其是当你是新员工时。…
源讨论Elixir v1.20 发布：现在是一种渐进类型的语言原帖 411 条评论 · 导入时统计说实话，我认为你对此的描述是错误的。Twitter、Airbnb和Shopify都使用Ruby on Rails取得了巨大的成功。也许这就是原因之一？也就是说，他们能够快速前进，而开发者也很高兴。 我不使用Rails，所以没有利害关系。但一旦你达到这个规模，你是否需要重写一次又有什么关系呢？
完整原文把你的经验，加入这段讨论。
> Elixir，我仍然需要了解整个调用链才能知道我可以对传入参数做什么。调用点越多，需要的脑力越多。 但调用链不一定要很长，比如只有2或3个地方；这可以装进我的脑海里。少即是多
完整原文在创业界几乎没有人会把产品/创业公司的失败归咎于选择了动态语言。可能有一些例外情况，但非常少，而且在这些情况下，确实应该使用最高效的强类型语言，并使用静态分析和性能优化的字符串工具。 现实是，在我所在的大多数公司中，语言偏好（类型化或动态）更多是一种时尚选择，而不是纯粹的技术考虑。 如果你在构建产品时积累了技术债务，而没有专注于简化和努力让它做任何事情，那么多年后解决方案就是重写。但如果你有相同的文化并保持相同的客户，你将处于与起点相同的位置，但现在面临不同类别的问题（例如网络延迟 vs N+1s）。 也许这就是“……的方式”…
完整原文尊重不同观点，分享具体经验。
登录后即可发帖、评论、转发和引用。