Post #341
1.87K
#杂
《那位用Rust重写数据库的创始人来复盘了:删除27万行C++代码,值吗?》
仅引用文中两句话:
“C++ 比较经典的问题是内存泄漏,但这类 Bug 比较容易修,我们觉得可以忍。”
“与此同时,我也想起之前在 AWS Redshift 工作中遇到的一个 Bug,三个人不断调试了两周都无解,最终发现是内存泄漏的问题,如果现在的项目继续下去很可能会遇到类似的情景,假设那时的产品已经有了很多用户,我们还需要因为这种内存泄露的问题调试许久,得不偿失。”
重新定义了“容易”。
我这一年用Rust的体验:业务特性可以往前继续开发,不太需要回头看有没有可能出现内存问题(泄露、野指针、越界)等情况,还是很令人安心的。
至于说什么“内存Bug容易修”之类的话,不多说了懂的都懂。我以前记录过也是我查了一周多的问题,本质也是个内存问题:《线上存储服务崩溃问题分析记录》,老实说这种问题查得累死了,能最后解决当然是有成就感的,可问题是:真的需要每次都这样吗,如果一边开发一边还为这种问题困扰,业务很难往前走。
《那位用Rust重写数据库的创始人来复盘了:删除27万行C++代码,值吗?》
仅引用文中两句话:
“C++ 比较经典的问题是内存泄漏,但这类 Bug 比较容易修,我们觉得可以忍。”
“与此同时,我也想起之前在 AWS Redshift 工作中遇到的一个 Bug,三个人不断调试了两周都无解,最终发现是内存泄漏的问题,如果现在的项目继续下去很可能会遇到类似的情景,假设那时的产品已经有了很多用户,我们还需要因为这种内存泄露的问题调试许久,得不偿失。”
重新定义了“容易”。
我这一年用Rust的体验:业务特性可以往前继续开发,不太需要回头看有没有可能出现内存问题(泄露、野指针、越界)等情况,还是很令人安心的。
至于说什么“内存Bug容易修”之类的话,不多说了懂的都懂。我以前记录过也是我查了一周多的问题,本质也是个内存问题:《线上存储服务崩溃问题分析记录》,老实说这种问题查得累死了,能最后解决当然是有成就感的,可问题是:真的需要每次都这样吗,如果一边开发一边还为这种问题困扰,业务很难往前走。
- 👍 14
- 🍌 5


