Rust 調查團隊分享了於 2023 年 12 月 18 日至 2024 年 1 月 15 日期間進行的 2023年 Rust 程式語言調查的結果。
2023年Rust程式語言調查結果顯示，Rust使用者數量略有增加，主要使用英語進行技術溝通。調查顯示Rust在全球範圍內得到了廣泛應用，尤其在美國、德國、中國等國家。對於技術領域的溝通，有 6.1% 的使用者選擇使用中文。
- 調查表明：Rust使用者希望改進Traits、Const execution和Async等方面的功能
- 調查表明：Rust使用者也關注編譯時間、執行時效能和編譯器錯誤等問題。
- 調查還揭示了Rust在工作中的使用情況、使用者對Rust的關注和擔憂、以及使用者對Rust未來發展的期望。
Rust 使用者普遍認為 Rust 在工作中具有幫助，認可其效能、控制、安全性等特點，但也提出了關於 Rust 複雜性、未來擔憂和改進最佳化的建議。
詳細點選標題
Reddit討論：
有趣的是，與借用檢查器相比，更多的人在非同步（async）和特質/泛型（traits/generics）方面遇到了問題，而借用檢查器通常被認為是學習 Rust 時最容易出問題的地方。
我想，經過一段時間的學習，你會學會如何與借用檢查器合作，而不是與之對抗，然後它有時就會變成一個小麻煩。
這也清楚地表明，該語言的這兩個部分最需要在今後的工作中加以改進（順便說一句，這兩個部分似乎進展順利）。
非同步有啥意義?
如果理解了借用檢查器要解決的問題後，它就開始變得有意義了，那麼非同步有啥意義？
因為......十年前，事件驅動程式設計、"c10k 問題"（一萬個併發連線）、nginx 如何比 apache 更好（因為它是事件驅動的，而不是預分叉/執行緒的）等風靡一時。
當然，nginx 只是一個大的狀態機，用來管理一個由套接字（以及檔案或其他 I/O）組成的多路複用的 epoll（或現在越來越多的 io_uring）陣列，它 "優雅地 "消除了建立新程序/執行緒的開銷。
非同步可以幫助你 "更優雅 "地做到這一點。
在某些問題上，這些絕對效能導向的非同步架構是有意義的。(例如，在編寫高頻交易機器人或網路中介軟體（防火牆、路由器、vSwitch、代理伺服器）前置軟體時，就可以使用這種架構。
當然，預先分配的一切意味著擴大或縮小規模都需要重新配置/重啟，也意味著一旦達到容量限制，就不會有優美的降級，請求/資料包會被丟棄等等。
如今，NUMA 和 SMP（以及多佇列網路卡和 NVMe 裝置）已成為預設設定，"分割 "機器並並排執行多個程序通常是合理的......但這樣一來，它們之間的工作分配可能就會出現問題，突然之間，你又回到了工作搶佔佇列（如果你想避免不平衡負載，通常在這種最佳化級別上會這樣做，因為你想要一致性），以及由檔案描述符和陣列索引結構表示的工作單位，這又是nginx所做的（現在仍然在做），而tokio在這方面也有幫助。
考慮到 Rust 的首要目標--追求無畏的併發性，它也是為了幫助使用者處理這些棘手的問題！
- 在 Rust 中，將執行緒模型推進到令人髮指的程度非常容易。
(例如，使用佇列和工作執行緒......你為自己構建了一個執行緒池執行器，如果你不需要async/await的所有花哨語義，那麼......執行緒就可以工作，即使理論上你會留下一些 "可擴充套件性"）。
非同步很難
大多數其他語言都是透過以下方式掩蓋這種複雜性的：
- 閉上眼睛，假裝整個概念不存在：Golang
- 提供一套受限的高階控制元件，增加了易用性，但減少了控制：C#、JS
- 是一個完全不正常的、無用的中間地帶：Python
- 所有工具、所有功能、所有風險：C/C++
語言級非同步的缺點
非同步程式設計的主要用例是支援大量（數千或更多）併發任務/執行緒，例如在網路伺服器中。不過，如果只有少量併發任務（比如小於 100 個），那麼生成普通的系統執行緒就可以了（即使是Web伺服器），而且使用起來更簡單（因為 Rust 中的 async 目前存在限制，而且缺乏 "函式著色"）。
語言級非同步 async 並不是實現輕量級任務的唯一方法，例如在Java21 中，他們選擇了使用虛擬執行緒 的更 "開發人員友好 "的解決方案。這意味著無論您使用的是系統執行緒還是虛擬執行緒，程式碼看起來都基本相同（儘管仍有一些差異需要消除），因此無需學習語言中的特殊非同步構造。一切都將由執行時和 stdlib 來處理。
不過，Java這種解決方案並不適合 Rust，因為它需要堆分配和執行時。