引用一篇国外的网文：

主要内容是解释为什么重写了原来的 Python 的程序。

  • Architecturally, the existing architecture was incapable of scaling to other technologies or changing direction without massive amounts of effort. The business had just been forced to change to MQTT from another IaaS provider because of licensing cost concerns, and the cutover took nearly a year. With new devices released every year (e.g. BLE, Wifi, Z-Wave, Zigbee, arbitrary REST APIs) the business wants to be able to change IoT stacks quickly to adapt to new technology.
  • There were technical debt items nobody understood or was prepared to resolve. (Did I mention that none of the original programmers were still around to fix bugs or answer questions?) Fixing obvious issues in one place often broke the program in completely unrelated parts of the code.
  • The program had unit tests in places, but there were no coding standards — someone’s “very clever” generator expression state machine drove the serial framing protocol, but it took weeks to figure out why it was broken.
  • There was dead code everywhere, but we couldn’t prove it was really dead code.
  • Holy cow, the bugs. Did I mention the bugs?
  • There were opportunities to replace the error-prone first-party Python Z-Wave handler code with a vendor-supplied reference implementation written in C. It would have been more effort to hack the existing Python implementation around the C library than to just rewrite the thing.
  • We wanted to run more customers on cheaper hardware. Improving that ratio directly drives higher profit margins for the business.

简单翻译了一下：

  • 在体系结构上，现有的体系结构如果没有大量的努力就无法扩展到其他技术或改变方向。出于许可成本的考虑，该业务刚刚被迫从另一家IaaS提供商转变为MQTT，转换花费了近一年的时间。随着每年新设备的发布(例如BLE、Wifi、Z-Wave、Zigbee、任意REST应用编程接口)，企业希望能够快速改变物联网堆栈以适应新技术。
  • 有些技术债没有人懂也没人解决。(我想说目前没有任何之前的程序员还在修bug或回答问题？)在一个地方修复一个简单的 bug 通常会破坏其他完全不相关的部分。
  • 该程序有些地方进行了单元测试，但是没有编码标准，有人的“非常聪明”的表达式生成器状态机驱动了串行成帧协议，但是花了几个星期才弄清楚为什么它被破坏了

到处都是没用的代码，但我们也不确定它就是真的没用的。

  • 天啊，到处是 bugs，我有提到 bugs 吗？
  • 有机会用供应商提供的用C语言编写的参考实现来替换自己容易出错的Python Z-Wave处理代码。但要想绕过C语言库修改现有的Python实现，比重写要麻烦得多。
  • 我们想让更多的客户使用更便宜的硬件。提高这个比率会让企业有更高的利润率。

So from those business needs we can start to pick apart some of the actual requirements in the chosen language for our particular project:

因此，从这些业务需求中，我们可以开始根据我们这个项目的实际需求来选择语言了。

  • It needs to talk C and run against C libraries.
  • There are timing requirements (because of the serial communications).
  • We need to be able to run it on a potato (because of cost).
  • It has to be able to run both the serial communications and a bunch of command/telemetry at the same time, without bugs.
  • String manipulation should be easy, because the commands and responses are all JSON.
  • The software must work correctly and deterministically, even though we are not all genius programmers.
  • It needs to be secure.

大概意思：

  • 它必须能调用C的库，和C语言对话。
  • 有时序的要求(因为串行通信)。
  • 我们需要能够在 potato 上运行它(因为成本)。
  • 它必须能够同时运行串行通信和一系列命令/遥测，并且没有bug。
  • 字符串操作应该很容易，因为命令和响应都是JSON。
  • 即使我们都不是天才程序员，软件也必须正确而果断地工作。
  • 它必须是安全的。

As it happened, Rust fit the bill for all of these needs.

事实上，“Rust” 符合所有这些需求。