在dwell，我們為物聯網閘道器編寫的程式碼已經用Rust了。它快速，可靠，安全。但我們不是從Rust開始的，我們也不是在一個週末就寫好了程式碼。本系列講述的是我們一年前的故事，我們是如何變成Rust的，以及為什麼你可能想要做同樣的事情。我們將介紹使用Rust的原因（或者不使用！）、執行緒化、硬體通訊、無畏的併發、與C庫互動、從頭編寫MQTT庫，以及我們經過艱苦努力學到的經驗教訓。
一年前，我加入了一家物聯網初創公司，當時有大量的遺留Python程式碼在Raspberry Pi上執行。在幾年的時間裡，這些程式碼已經有機地增長了，就像大多數程式碼庫一樣。這段程式碼的最初目的是監視MQTT命令通道，透過串列埠解碼和執行Z-Wave網路上的命令，並透過另一個命令通道報告成功或失敗。此外，程式碼還用於報告有關係統總體健康狀況和Z-Wave網路上連線的裝置狀態的資訊。在這個過程中，軟體逐漸轉移到控制狀態led，透過單獨的串列埠控制蜂窩調變解調器，並與板載釋出管理軟體進行通訊。
在我的招聘面試中，一位高階軟體工程師迫切地想要重寫整個程式，於是我離開了一家c++商店，這家商店在之前的成功的勢頭下搖搖欲動。劇透：他想把現有的Python程式碼轉換成Rust，這個前景非常令人興奮，我從我的舊工作跳槽到其他城市。
但是在我們開始討論為什麼我們選擇Rust或者為什麼它令人興奮之前，我們為什麼決定重寫呢？傳統的智慧告訴我們，當你已經有了可以執行的軟體，甚至是部分可以執行的軟體時，永遠不要重寫軟體。但如果我們遵循這個邏輯，我們在未來的太空任務中仍然會執行阿波羅制導計算機軟體（嘿，架構是1號的補充，但最後的錯誤報告是在1969年，所以它一定是可靠的）。為什麼要重寫呢？
簡而言之，它歸結為業務需求。
從架構上講，現有的架構在沒有大量工作的情況下無法擴充套件到其他技術或改變方向。由於許可成本問題，該公司剛剛被迫從另一家IaaS供應商轉向了MQTT，而這一轉變花了將近一年的時間。隨著每年都有新裝置釋出（例如BLE、Wifi、Z-Wave、Zigbee、任意REST api），企業希望能夠快速改變物聯網堆疊，以適應新技術。
有些技術性債務專案沒有人理解，也沒有人願意解決。（我有沒有提到過，最初的程式設計師都沒有修復bug或回答問題？）在一個地方修復明顯的問題往往會在完全不相關的程式碼部分破壞程式。
該程式有單元測試，但沒有編碼標準——某人的“非常聰明的”生成器表示式狀態機驅動了序列幀協議，但它花了幾周的時間才弄清楚它為什麼壞了。
到處都是死程式碼，但我們不能證明那真的是死程式碼。
天哪，這些蟲子。我有提到那些蟲子嗎？
有機會將容易出錯的第一方Python Z-Wave處理程式程式碼替換為供應商提供的用C編寫的參考實現。它將花費更多的精力來破解圍繞C庫的現有Python實現，而不是僅僅重寫它。
我們想讓更多的客戶使用更便宜的硬體。提高這一比率將直接提高該業務的利潤率。
因此，從這些業務需求中，我們可以開始為我們的特定專案挑選語言中的一些實際需求：
它需要與C語言對話並針對C庫執行。
有定時要求（因為有序列通訊）。
我們需要能夠在土豆上執行它（因為成本）。
它必須能夠同時執行序列通訊和一堆命令/遙測，沒有bug。
字串操作應該很容易，因為命令和響應都是JSON。
軟體必須正確和確定地工作，即使我們不是天才程式設計師。
它需要安全。
事實上，Rust符合所有這些需求。
我不會成為那些說每個人都必須使用我最喜歡的新語言的傳道人之一。有很多很棒的工具，沒有一種程式語言是完美的。事實上，Rust尖銳的學習曲線和接近裸金屬使得它成為許多專案的次優工具。
為什麼你可能不想用Rust
如果你需要快速建立原型，做面向webby使用者的東西，有10億個JS框架。如果你有足夠的記憶體，現在的電子實際上是相當快的。
如果您需要快速建立原型，並且需要為科學計算數字，那麼您可能需要Python。不要再在Matlab上浪費錢了，把你的助學金省下來給本科生吧。快點，暗能量不會自我解決的。
如果您試圖在普通硬體上編寫可執行緒的後端軟體，如果您需要JVM庫基礎設施，可以考慮Go或Kotlin。
有時候一個shell指令碼就可以了！
但是，如果你是一個和其他人一起編寫程式碼的人，並且覺得你需要用C/ C++（速度、資源限制、時間限制、可移植性）編寫新的程式碼，那麼你應該強烈地考慮用“Rust”來編寫它。
在下一章中，我將回顧一些我們不使用c++的原因，以及為什麼Rust對我們有用。