1樓：Hao Yu
如果你的專案是新的，並且在可知的未來和其他基礎庫依賴不大，rust是個很好的選擇。
但如果你的專案有沉重的歷史包袱，依賴複雜，還得好好考慮一下，如何重構，如何平衡商業成本和風險。
2樓：find goo
大廠已經在使用了，都是有影響力的領域。
linus已經準備把rust加入linux核心谷歌準備把rust加入安卓
華為也在使用rust寫網路通訊
亞馬遜用於寫AWS雲計算
微軟用Rust重寫Windows元件
蘋果使用rust代替c語言移植
阿里雲和微軟合作發布有rust開源專案
雲計算，大資料，移動網際網路，人工智慧，區塊鏈，物聯網發展越來越快，對高效能低延遲語言未來需求會越來越大，可以節省大量電費。
c和c++由於高效能靜態編譯，輝煌了30多年，估計rust會是未來幾十年的c和c++，廣泛應用於各個領域。
這麼多大廠一致開始使用，未來發展前景會很好。
3樓：巽震
再過 10 年……我把話放在這，期望被打臉。
當年有多少人捧 Haskell？最近這些天，我的時間線裡出現了因為 rust 能寫 linux 核心模組所以可以替代 C 的答案，他們或許根本不知道：Kernel Modules - HaskellWiki
至於那些說 rust 沒歷史包袱，rust 有 cargo……的人，難道 Haskell 有歷史包袱，或者 Haskell 沒有乙個包管理器怎麼的？無論是論資歷，論安全，論社群，論記憶體管理……記憶體管理好像論不了，Haskel 有 GC，但是要是有什麼好辦法，誰願意在 Rust 程式裡寫 lifetime 標記呢？
Haskell 要過 20 年……依然期望被打臉。
4樓：
周圍用rust做工業和js嵌入式專案最早應該是17年，語言這類技術，夠用就行，rust的特性確認有很多吸引人的地方，類似我這樣開發者，嵌入式用c，cpp或者rust都是基於成本測量的。新專案現在用rust完全可以，老專案看移植成本。
5樓：歐流全
在Windows程式設計方面，C/C++、C#二者是第一語言，Rust在呼叫Win32 API總會遇到各種各樣的問題，不是這個資料型別缺少或者不對，就是那個API不對，你用完整使用總要造各種各樣的中間層bindings去處理，這其實很折騰很費時間。
微軟那個windows-rs和社群的winapi看看就好，煎蛋demo沒問題，真用起來現實中各種各樣的Win32 API簡直要你命。
6樓：Crane
直接回答，是個好選擇。
當前有兩個標誌性事件，linux kernel，已經同意使用rust來編寫核心模組，這個絕對夠底層了。
android，Google也決定引入rust來開發底層服務。
linux kernel加上android，是兩個使用廣泛的作業系統，rust在這兩領域突破影響是巨大的。
為什麼這麼選呢，因為過去多少問題都是C/C++的記憶體操作引起的，rust在語言層面對解決這個問題有全面的考慮。
7樓：生鏽的鉻
用Rust寫了一些通道、網路、地理資訊資料處理的專案。
個人觀點：
可讀性方面，Rust的抽象能力非常強，預設的消耗值、借用檢查器以及一些函式式特性會讓你感覺非常舒服。這一點其實和你熟悉什麼語言高度相關，所以我感覺和CPP差不多。
可維護性方面，這一點絕對是比CPP強。Rust解決問題的方案一般非常直接，細節上很少耍花裡花哨的東西（大方向設計上還是很考究），所以大家的思路一般比較一致。而CPP的玩法太多，同樣的問題有很多種思路解決，搞不好還有愛炫技的朋友寫出誰也不好接手的東西。
程式設計體驗方面，Rust相比CPP的優點是有大一統的Cargo來管理一切，所有的專案都是Cargo來管理，呼叫別人的crate簡直清爽到極點，個人管理自己的專案依賴的時候也很好用。CPP有些專案原始碼拿過來，搞不好連合進自己專案都做不到，最後還得造輪子。同時，缺點也很明顯，那就是Rust還是太年輕了，好用的庫太少，冷門領域很可能壓根沒有。
如果你寫的東西像我寫這些資料處理專案一樣，本身就是造輪子，那絲毫不耽誤啥。但是如果你寫的東西需要依賴一些領域的支援，那一定要先想好這個領域有沒有好用的crate，如果沒有，自己能不能寫或者能不能用FFI去做介面呼叫。別開發到一半再因為沒有合適的庫撓頭
程式設計效率方面，Rust開發者花費在通過編譯器檢查的時間遠高於編譯後找bug的時間，這一點和CPP應該是相反的。所以如果是非常容易出錯而且debug很困難的專案，Rust會幫你節省時間，反之CPP開發效率更高。
最後想說的是，個人認為想要優雅流暢地掌握Rust，最好先會一門系統級手動管理記憶體的語言，這樣才會明白Rust為什麼要額外付出生命週期和借用檢查的代價，再學會一門函式式語言，這樣才好理解Rust很多函式和閉包的設計，最後再上Rust就會感覺一切都是很自然的
8樓：qwety ed
如果是和硬體打交道（從軟體角度）那沒有語言能幹過C，如果條件真的苛刻，那沒有語言能幹過手寫彙編（或者進一步，指令） 純硬體，不好意思，上萬用表示波器吧。
其他的「偏底層」，你總歸可以使用機制+策略分層的思路……之前這兩層都是c++，現在，至少多了乙個選擇。
9樓：歐流全
Rust的unsafe能跟C++一樣做靜態分析嗎？
如果真想做底層，不能說你unsafe了就不做靜態分析了，你可以把C++當成能做unsafe分析的Rust
10樓：
真正到了底層，反正 C++ 也是一樣尷尬，Rust 因為包管理和低心智負擔當然是可以在那些本來能用 C++ 的地方的。但一般到用 C 的程度也就不一樣了。
11樓：XIVN1987
嵌入式，作業系統，硬體驅動這些底層領域大多數用的是C，而不是C++，，所以就更談不上Rust替代C++了，，
C++在嵌入式領域主要的應用是GUI，，比如Qt
C++和Rust最大的特點是"zero cost abstraction"，底層領域只需要「zero cost」，不太需要「abstraction」，，所以語法簡單的C更合適
12樓：彭亞倫
是.只不過rust生態上目前還沒有太成熟, 畢竟也就出現也幾年的時間, 如果你是自己從頭從底層開始造輪子那完全可以.
話說, 這個問題下的有些回答說話那麼衝, 企鵝家的人似乎對rust含有深深的怨念啊~
13樓：馮東
底層這個領域的特性對 Rust 並不友好。
第一是 Rust 並不是變魔術消除 complexity，它是把 complexity 圈禁在 unsafe code 裡。如果你的專案大部分都是 safe code，這個是否還叫「底層開發」就值得商榷。你把好多 safe code 歸到底層，這就是說你的架構可能就不清晰。
第二是底層開發強調乙個專案盡可能通用，可重用，功能穩定。這種專案的管理本身消除了 C++ 在快速迭代上的弱勢，凸顯了 C++ 語言本身穩定，工具鏈成熟的優勢。
14樓：徐辰
整體來說Rust可讀性比C++還是好一些，歷史包袱也比較少，工具鏈比較順手，新東西加入的也比較快。
如果在偏底層的領域有一些船新專案不妨一試，如果你要重寫現有專案那還是再想想。
15樓：feverzsj
國內基本找不到rust的底層工作，預計5年內也不會有太大改善，而且現在rust的工作，基本都要求精通C++，所以還是老老實實學C++吧。
馬上2023年了，在2023年有什麼遺憾嗎？
Kilig 2020年真的是對我來說超級重要的一年。今天的九月退伍的時候趕上了連隊出任務，想見的人沒有見上，待了兩年的地方就這樣最後就冷冷清清的走了。可能是自己軍旅生涯最大的遺憾了 阿芳 沒有遺憾，這一年比2019年成長了許多，也得到了很多，希望在2021年繼續加油！早日實現自己的計畫和目標，為自己...
2023年的教資筆試真的很難嗎，很偏嗎 是自己沒有背好，沒有準備充分，還是題目出的有問題？
我裸考真的都感覺不難，就是沒好好準備我覺得，考完就很後悔沒什麼沒好好準備 其實不偏，真的把知識大概掌握了，然後不是臨時抱佛腳的，我感覺是沒問題能過的，題目出的有點意料之外但是又情理之中 個人覺得還好，雖然有難題，但總體考下來也不是什麼都不會。如果好好複習，認真準備的話，應該可以全面地學習到考點，科一...
2023年了，uniapp發展的怎麼樣了
瀟湘 因此如果業務需要重點使用這些功能，那麼使用原生幾乎是唯一的選擇，用跨平台開發便是噩夢。如果業務只需要向使用者展示UI內容，進行互動，涉及的只是IM 支付等偏UI的功能，那麼用跨平台開發應該算是乙個可以考慮的方式。 魚小禮 看到這個問題正好手頭有個簡單專案就來回答一下。簡單說一下專案背景，乙個非...