亲历两场编程语言迁移“惨案”，谷歌大佬揭露技术选型真相：90%决策与技术无关

see122

编者按： 技术选型，尤其是编程语言的选择，常常被包裹在“性能”、“生态”、“开发效率”等技术术语的外衣之下，被视为一场纯粹理性的辩论。然而，在这篇由资深技术领导者撰写的文章中，作者通过自身亲历的两起惊人相似的案例——从早期创业公司因 CTO 执意将 PHP 换为 Perl 而错失市场，到后来在谷歌目睹团队为追逐 Rust 而罔顾更优选择——为我们揭开了技术决策背后令人不安的真相：很多时候，我们以为是在权衡技术利弊，实则是在为个人的身份认同、情感归属与职业标签寻找合理化借口。

这篇文章的核心价值在于，它精准地指出了在每一次“看得见”的技术辩论之下，都潜藏着一场更为强大且“看不见”的自我对话。后者关乎“我是谁”、“我想成为谁”，它直接触动我们大脑中的防御机制，让理性的天平悄然倾斜。

对于每一位技术决策者——无论是 CTO、技术 VP 还是团队负责人——这篇文章都是一面不可或缺的镜子。它迫使我们反思：我们引以为傲的技术决策，究竟是基于客观事实，还是源于那个渴望被特定技术社区认可和定义的“自我”？在下一个价值数百万甚至数千万美元的技术选型会议开始前，这篇文章或许能为你提供一个至关重要的审视视角。

本文作者 Steve Francia 是一位在软件、产品及推广领域拥有 27 年深厚经验的技术领导者，长期专注于开源生态与开发者体验。他曾主导多个具有行业影响力的标杆项目，包括 Go 语言、MongoDB、Docker 以及支撑全球 10% 商业互联网的 Drupal 内容管理系统。

此外， Steve 还负责撰写了谷歌的开源战略，并牵头制定了谷歌云的开发者战略。

作为一名热爱编程的开源贡献者，他创建了多个广受欢迎的开源项目，如全球最流行的静态网站生成器 Hugo、为超过 5 万个应用程序提供支持的 Go CLI 框架 Cobra，以及 Go 语言配置框架 Viper。这些成就也使他成为全球最受欢迎的开发者之一。

Steve 也是一位活跃的技术布道者，经常受邀在各类会议、播客及用户组活动中发表演讲，其《Go 语言——站在巨人的肩膀上》和《Drupal 与我的成功秘诀》两场演讲深受业界好评。他还为 O'Reilly 撰写或合著了《Go 语言中的强大 CLI 应用程序》、《Hugo 实战》等多本技术书籍，并在其他多部著作中提供了建议与贡献。

新任 CTO 把 PHP 换成 Perl， 导致成本飙升，错失良机

编程语言是企业做出的成本最高的单项选择，然而我们却将其视为一场单纯的技术争论。目睹这一错误导致数十家公司破产、超过数百家公司受损后，我领悟到一个令人不安的事实：这类决策极少与技术本身相关。它们关乎身份认同、情感与自我，并且会以一种事后才察觉的方式，损害公司的发展速度与预算。

在我职业生涯早期，我曾任职于 Takkle，这是一家前景良好的社交网络公司。由于一名高管突然离职，我从首席工程师晋升为工程副总裁，带领着一支 12 人的团队。尽管我们顺利达成了所有目标，但当时我才 20 出头，缺乏经验，董事会希望解决这一风险。他们向 CEO 施压，要求招募一位更具经验的 CTO。我很期待能向这位新 CTO 学习 —— 他在 Perl 社区颇具名气，入职时还带来了一摞 O'Reilly 出版的 “骆驼书”（Perl 编程语言经典教程）。

这位 CTO 上任后的首要举措之一，便是宣称我们当时使用的编程语言 PHP 是错误选择，并下令将其更换为 Perl。在我看来，他此前对 PHP 和 Perl 进行的对比分析毫无意义，这场更换命令正是在此之后下达的。

我们的发展速度一落千丈。团队不仅要学习新的编程语言，还得从零开始重建系统，这导致产品上线时间推迟了 9 个月。为了弥补进度损失、搭建基于 Perl 的新系统，我们的团队规模扩大了一倍多，月度烧钱速度也从 20 万美元飙升至 50 万美元，公司的资金存续周期因此缩短了一半。

这位 CTO 确实兑现了部分承诺。我们搭建出一套出色的系统，我也真心为此感到自豪。但一切都为时已晚。当我们最终完成产品上线时，市场机遇早已消失。彼时 Facebook 已不再局限于高校用户，而我们的资金也即将耗尽。激增的开支让资金存续周期缩短一半，新网站又缺乏足够的发展势头来达成融资所需的里程碑，我们再也无法获得更多资金支持。

我时常会想：如果当初我们坚持使用 PHP 会怎样？我们原本的系统运行良好，发展也具备十足势头。那样一来，我们不仅能更早推出产品，成本还会大幅降低。PHP 对 Facebook 而言都够用，为什么对我们就不行呢？

但真正困扰我的问题是：为何如此经验丰富的领导者，会犯下这样严重的错误？

惨痛的教训又来了： CTO 一拍脑门决定用 Rust

无独有偶，我的职业生涯，又经历了一遍上述悲剧。

在谷歌担任编程语言产品负责人时，我所带领的团队涉及 C++、Java、Go 和 Python 四种语言。在 MongoDB 工作期间，我管理的团队使用着 13 种不同的编程语言。在这两家公司，我都看到过才华横溢的工程师们各执一词，他们手中的数据看似相互矛盾，实则每一份都真实可信，却又都不够全面。而在谷歌云部门，我发现客户们也面临着同样的难题。

距离 Takkle 事件已过去 20 年，我却再次经历了似曾相识的场景。当时，谷歌一位工程副总裁正向管理层汇报，说明他的团队为何需要用 Rust 语言搭建下一套系统。这场汇报与当年 Takkle 的经历惊人地相似 —— 当年那位 CTO 为选择 Perl 给出的理由，几乎每一条用在当时的 PHP 上都更贴切；而如今，这位副总裁为选择 Rust 罗列的每一条理由，客观来看 Go 语言都更具优势。举个例子：他们称 “易于构建和部署” 是 Rust 的优点。诚然，这确实是 Rust 的强项，但在这一具体指标上，Go 语言的即时跨平台编译能力和单一静态二进制文件特性，比编译速度极慢的 Rust 表现更出色。

我并非认为他们应该选择 Go 语言 —— 事实上，结合他们的实际情况，Go 或许是个错误选择，而 Rust 才是正确答案。但让我震惊的是，他们的推理过程漏洞百出。如果他们是在进行理性论证，理应会考虑 Go 语言；而按照他们汇报中提出的评判标准，他们早该发现 Go 更符合要求，至少也会重新调整评判标准。

会议结束后，我把这位副总裁拉到一旁，问道：“跟我说说你们是如何评估其他候选编程语言的？” 他顿时面露茫然，承认道：“我们…… 其实没考虑过其他语言。大家都在谈论 Rust。” 真相就此揭开：一个价值 5000 万美元的决策，仅凭跟风炒作就要获批通过。

对我而言，这一刻如醍醐灌顶 —— 我终于找到了职业生涯初期那个问题的答案。那场汇报根本不是在展示分析结果，因为他们从未做过分析；它只是为一个早已定好的选择寻找借口。这个决策，完全是基于炒作、情感和身份认同做出的。

为什么会出现这样现象？因为本质上，每一场技术争论，都是两场对话的交织。在每一次编程语言讨论中，都有两场对话在同步进行。

看得见的对话——“Rust 具备内存安全性，且无需垃圾回收机制。”“Go 语言编译速度更快，部署也更简便。”“Python 拥有最丰富的机器学习生态系统。” 这类对话聚焦技术本身的特性，所有观点均以技术维度的事实为支撑。

看不见的对话——“我是一名 Rust 开发者。”“我想成为一名 Rust 开发者。”“我无法想象自己会是不选择 Rust 的人。” 这场对话隐藏在技术表述背后，核心是个人的身份认同、职业期待，以及对自我技术选择的心理维护。

如果你看到这里，心里在想 “不对，我上次选编程语言时不一样，我当时很理性”，那说明你此刻正处于这场看不见的对话中 —— 在你读这句话的同时，它已经在为你的选择辩护了。

我在 Takkle 公司时遇到的那位 CTO，就深陷这场看不见的对话。他为选择 Perl 所做的技术分析，每一个观点从技术层面看都属实，但总让人觉得空洞，因为这些分析只是为了掩盖更深层的隐形对话。他并非在评估编程语言，而是在守护自己用十年时间建立起来的身份认同 ——Perl 技术专家的身份。

我们公司每个月多花 30 万美元，并非为了更优的架构或更快的招聘速度。我们支付的，是让他能以 “Perl 首席技术官” 而非 “PHP 首席技术官” 自居的机会。这才是背后真正的 “交易”，而重建系统不过是这场交易的 “付款方式”。

谷歌那位副总裁关于 Rust 的汇报中，将 “易于构建和部署” 列为 Rust 的优势。从技术角度看这没错，但客观而言，Go 语言在这一具体指标上表现更优。如果他们真的在认真进行那场 “看得见的对话”，理应会发现这一点，至少会在分析中考虑 Go 语言。但他们没有。因为他们从头到尾都没在进行 “看得见的对话”，却即将为这场 “看不见的对话” 投入 5000 万美元。

为啥你永远看不出自己的偏见？

在过去二十年一项极具启发性的研究中，研究者试图探寻：为何人们即使面对压倒性的反证，仍会固执坚守某些信念？这项发现从根本上改变了我们对人类决策机制的认知。

研究人员先锁定每位参与者身份认同的核心信念——包括其核心立场、基本价值观等构成自我认知的根基。随后，在参与者接受 fMRI 脑部扫描时，研究者分别对其核心信念与非核心信念发起精准挑战。

脑部扫描结果显示：这两类挑战激活的神经通路截然不同。

当非核心信念受到质疑时，大脑推理中枢正常运转。参与者能够理性分析证据，权衡论点，甚至改变原有看法。

然而当核心信念遭遇挑战时，大脑反应如同遭受物理攻击。负责威胁识别的杏仁核立即激活——这与遭遇猛兽时的应激反应如出一辙；处理情绪痛苦与厌恶的脑岛皮层剧烈活动；最具启示性的是，维持自我认知的默认模式网络会立即进入防御状态，全力守护既存身份认同而非评估新信息。

换言之，此刻你的大脑并非在权衡证据，而是在抵御生存威胁。

研究结论一针见血：“若要接受不同观点，你必须构想另一个版本的自己。”

大脑无法客观评估对核心信念的挑战，因为这需要暂时解构定义“你是谁”的神经架构。这并非靠增强理性或加倍努力就能解决——偏见本身已侵蚀了你察觉偏见的能力。

这种现象在现实中如何显现？当工程师评估非擅长领域的编程语言时，其大脑实质上在自我对抗。他们不仅在分析技术权衡，更在直面一个充满威胁的“潜在自我”：Python 开发者研读 Go 语言性能案例时，其杏仁核会将每个证据标记为待消除威胁；Rust 拥护者审视相同问题时，其默认模式网络会构建“唯 Rust 能解”的叙事逻辑。

我们并非刻意欺骗——我们真诚相信自己的逻辑无懈可击。这正是身份认知思维既代价高昂又难以察觉的根源。

我们自称 Pythonista、Gopher、Rustacean，将这些标签化作勋章（乃至实体徽章：T 恤、贴纸等）。纵观历史，众多姓氏源于职业（陶匠、铁匠、酿酒师），昭示着“职业即身份”的深层逻辑。这些看似装饰性的标签，实则是潜意识的决策框架。

整个行业始终聚焦于表层对话：培训工程师进行技术辩论，建立功能矩阵决策框架，寄望于通过足够多的基准测试案例做出正确选择。

但潜意识的暗流才真正主导着决策走向：这解释了为何某 CTO 选择 Perl，某副总裁钟情 Rust。在您即将进行的语言选型中，这股暗流正在无声涌动。

当你雇佣 Rust 开发者评估编程语言时，结局早已注定——两百万美元的可行性研究，不过是为既定结论披上理性外衣的仪式。

真正的代价

问题不在于这种偏见是否存在 —— 科学结论早已明确。真正该问的是：你承担得起让它左右决策的后果吗？

因为这场 “看不见的对话” 是要花钱的。行业研究显示，在产品生命周期内，技术栈的选择会占据总开发成本的 40% 到 60%。Stripe 的研究也发现，开发者有 42% 的时间都在处理技术债务。当你让 “身份认同” 主导决策时，本质上是在拿公司的发展速度、预算和资金存续周期做抵押，只为满足某个人的自我认知。

“看得见的对话” 围绕技术展开，“看不见的对话” 围绕身份展开，而最终赢的永远是后者。

既然 “看不见的对话” 总在拖后腿，我们该如何破局？答案是彻底转变对话的核心。

不要再问 “哪种语言最好”，而要问 “用这种语言会让我们付出多少成本”。这里的成本不只是薪资，还包括发展速度的损耗、技术债务的积累、招聘的难度、运维的复杂度 —— 涵盖所有关乎公司能否存活的维度。

把技术层面的争论，重新定义为经济层面的考量。而且和 “身份认同” 不同，经济成本可以量化、可以对比、可以理性决策，不会威胁到任何人的自我价值。

选择编程语言，是公司要做的成本最高的单项经济决策。它会决定公司的技术文化、限制预算分配、影响招聘渠道、设定运维成本，最终还会左右你能否以足够快的速度抢占市场。

我们需要一个能让 “隐性成本显形” 的框架。这个框架要能引导我们讨论经济问题，而非纠结身份认同；无论你是第一次选语言，还是评估技术栈迁移，它都能发挥作用。

网友这么看？

一直以来，关于编程语言的争论总是备受瞩目。Steve Francia 的这篇文章在 Hacker News 社区中引发了诸多讨论。

有位 ID 名为 bri3d 的 Hacker News 用户表示并不认同这篇文章中的观点。该用户表示自己参与过很多编程语言重写项目，有成功的也有失败的，项目成功的不在于编程语言，而是取决于：项目团队成员的构成，以及项目架构师的能力。

“我参与过几十个重写项目，有成功的也有失败的，也见过各种规模的项目和产品，但我始终认为编程语言的选择并非决定产品成败的主要因素。即使将这个论点从语言扩展到框架和生态系统，尽管在这些领域或许能找到一些蛛丝马迹，但仍然无法展开有意义的讨论。项目成功的关键几乎总是取决于：项目团队成员的构成，以及项目架构师的能力。当然，我并不是说某些语言（尤其是小众语言）完全不重要——它们在一定程度上确实会影响招聘和员工类型，但这种影响远不及项目团队成员的构成和项目管理水平。”

有从事咨询工作的用户对于 bri3d 的观点表示认同。他表示：

“这是一个非常精辟的观察。在我从事咨询工作的过程中，也很快意识到企业面临的问题大多可以归为两类：一类是足以‘毁掉整个项目’的致命问题，另一类则是‘会给优秀工程师带来麻烦’的棘手问题。

以编程语言选择为例——这基本上总属于后者。就像我的团队虽然不精通 Java，但若情势所迫，我们依然能用它完成开发。而真正属于前者的，往往是糟糕的管理体系或某个刚愎自用的人物。比如当持续集成流水线需要 30 分钟才能完成反馈循环，或者连本地开发环境都无法搭建时，项目才真正走到了生死存亡的边缘。”

ID 名为 WalterBright 的用户也不赞同文章作者的观点。他终认为，编程语言的选择并非决定产品成败的核心因素。这一点在他的开发生涯中多次得到验证。

“我曾接手过一个庞大而复杂的宏汇编程序，由于原开发者离职且无人愿意维护，我主动提出用 C 语言进行重写。最终成果不仅显著提升了代码的可维护性，还成功实现了向公司多个目标平台的移植。

另一个例子是 Optlink（一个 Win32 链接器）的移植尝试。虽然我致力于将其从汇编语言迁移到 C 语言，但由于 Win32 编程市场的整体萎缩，这个项目最终未能获得成功。

而我的《帝国》游戏开发经历更是生动的例证：这个项目最初采用 BASIC 语言实现，随后经历了 FORTRAN、PDP-11 汇编语言、PC 平台的 C 语言，直至最终的 D 语言多次技术栈转型。每一次语言迁移都顺应了当时的技术环境，但产品的核心价值始终得以延续。

这些经历让我深刻认识到：真正决定项目命运的，是市场需求、架构设计和团队执行力，而非具体的编程语言选择。”

还有用户表示，在选择编程语言时，也不是所有决定都是一拍脑门做出来的，而是优先采用团队最熟悉的语言。唯有当所有成员一致认为另一门语言更契合项目需求，或存在其他令人信服的更换理由时，才应考虑改变。盲目追逐技术潮流、或通过行政命令强行推行某项技术——无论是 Cucumber、GraphQL、微服务还是其他什么——往往会导致灾难性后果。

“就个人习惯而言，我自然倾向于使用自己最擅长的技术栈。但我清楚地意识到这种偏好可能存在局限，因此在实际工作中会主动提出其他可能性。若项目不由我主导，我非常乐意配合团队既定的技术方向。我始终认为，盲目追逐技术潮流、或通过行政命令强行推行某项技术——无论是 Cucumber、GraphQL、微服务还是其他什么——往往会导致灾难性后果。

正确的做法应该是：首先精准定义你要解决的问题，并真正站在最终用户的视角思考体验；接着切换到运维支持者的角度评估可持续性；再以未来维护者的身份审视代码可维护性；最后，想象十年后的自己会如何评价这个技术决定。

如果有成熟的现成解决方案，就直接采购；若确实需要自主开发，则优先考虑将非核心模块外包。总而言之，我们应该用最简单、最直接的方式解决问题，这才是最明智的工作哲学。”

参考链接：

https://spf13.com/p/the-hidden-conversation/

https://spf13.com/about/


来源：36kr