给大家讲一个"十动然拒"的故事：
2018年6月，Nodejs 之父刚刚开发 deno 不久，Protobuf 的作者建议 deno 不要使用 Protobuf，并向 ry 推荐了自己开发的 Cap'n Proto，性能非常卓越 https://github.com/denoland/deno/issues/269。ry 和 kentonv 围绕性能问题展开了近一个月的深入探讨，ry 十分感动，然后……拒绝了 kentonv 的推荐，而选择了 flatbuffers。昨天 ry 新开了一个 issue，打算替换掉 flatbuffers 库 https://github.com/denoland/deno/issues/2121 因为根据 deno 的基准测试数据看，目前的性能瓶颈就是 flatbuffers, 随后 kentonv 又被重新召唤出来。
想到一首歌《倔强》
kentonv:用Cap\'n Proto吧，性能好，balabala...用嘛用嘛。
ry：不了。我和我最后的倔强...这一次再让我倔强一次吧。
kentonv:。。。那我走了？
...一段时间后
ry：？？？性能卡在flatbuffers。。。
ry：kentonv大佬，你回来啊！我不倔强了。
哈哈哈
kentonv 说 Cap’n Proto 也解决不了
@steambap Cap’n Proto 和 flatbuffers 原理一样，看来这个瓶颈只能依靠其他途径解决了
node 之父，promise ，npm ，gyp 真的留下一堆坑，不听社区建议~
@zuohuadong 这个锅 ry 不背。ry 虽然是 Nodejs 之父，但是他早就离开 Node 了，Node 由 Nodejs 基金会主导，目前已经和 JavaScript 基金会合并，改名为 Open 基金会。
ry 给 node 提交的最后一行代码是 2012 年
@justjavac 後悔之一：沒有堅持使用 Promise 在 2009年六月在 Node 中開始引入 JavaScript 的 Promises，但又在 2010年二月就移除掉了。
結果，隨著日子久遠，Node裏面就遍佈著 async/await 和 promise 的不同 async API設計，直至現時都極難整合。
後悔之二：看輕了安全性（Security） JavaScript Engine V8 本身有很好的 sandbox 架構，但是有時候 Node.js 本身沒有好好善用到，例如有可以直接讀取 Memory 的 例子、或者 linter 可以直接使用網絡功能等的漏洞。
後悔之三：沒有從 GYP 建構系統轉到 GN Node.js 用到的 JavaScript Engine V8 一開始是使用 GYP 來建構的，Node 理所當然也跟隨；後來 V8 轉用了 GN (Generate Ninja)，只剩下Node 成為唯一的用家。GN 比用 Python 寫的 GYP 快近起碼 20倍，對於使用者來說，簡直是天淵之別。 ....
太黑了
@justjavac 感觉 ry 做事风格一直这样，导致留了很多坑，担心 deno 前途~
笑哭