Rust 火了會怎樣？

12-30

(如題(剛剛看到haskell為何不火的知乎(有人說(為了學術研究，它不能火，否則將無法繼續進行研究(看完後突然對最看好的rust產生了同樣的問題(以前，我總在盼(盼著盼著，1.0stable發布了;盼著盼著，rust book Chinese發布了，盼著盼著，它可能某時會火。)))))
我很想知道，我為何希望或不願它火的根本原因。

//我知道，如果rust火了，rustcc的人是國內最先受益的。
//PS:微軟已經盯上rust了。。。
//PS:知道Y I N 語言的人因該知道它為何從開源走向閉環。
///

///不是問前景(大神，你們水的漂亮
///
過多的也說不完，爪機真累。//為了rust，值了

沒用過rust，只讀過一些論文聽過一些talk，簡單說說我的看法。

首先要知道Rust的誕生是為了服務於Mozilla開發瀏覽器這個目的的。現在瀏覽器有哪些問題？我知道的有兩個，一個是安全，一個是效率。翻翻每年計算機安全方面的頂級會議就知道，因內存錯誤（溢出，懸掛指針）引發的攻擊（主要是ROP一類的code reuse攻擊）一直是學界和工業界的研究熱點。而幾乎每一篇這方面的論文都會拿Chrome，IE，Firefox這些瀏覽器搞一個proof-of-concept attack。工業界方面，Google自己也在Chrome的安全性上狠下功夫。關於效率，複雜的結構讓瀏覽器的內存管理很成問題，Chrome的內存泄漏也算比較有名了。總而言之，兩方面問題都的癥結有一個交點，那就是C++的內存管理一直困擾著大型項目的程序員。

要儘可能消除內存錯誤，有兩條路。一個是動態測試，一個是靜態分析。Google的人曾跟我說他們有一些專門的機器其他什麼也不幹，就用Valgrind跑Chrome排錯。當然這麼做效率感人，而且可以改進的地方也不多，所以現在大家主要都在靜態分析上下功夫。

Rust的設計思路，就是通過定義一個特別的類型系統，把某些類別的內存錯誤的檢查放到編譯階段。這個檢查非常激進，只要有可能出內存錯誤編譯器（或者說類型系統）就不讓你過。換個說法，其實Rust就是把確保代碼正確性的負擔的一部分從靜態分析工具直接轉嫁給了程序員，逼著你寫絕對內存安全的程序。

理解了這個背景，就好分析Rust的前景。用Rust的利弊很大程度上取決於項目的特徵。像現代瀏覽器這樣級別的項目，維護往往比編碼成本更高，所以儘管程序員在用Rust的時候可能會覺得縛手縛腳，但長期來看這個trade off是值得的。今年ICSE的Software Engineering In Practice Track剛收了一篇Mozilla的文章，叫Engineering the Servo Browser Engine Using Rust。裡面介紹了一些Mozilla內部用Rust寫瀏覽器的經驗，很接地氣，大家可以去看看。

回到最初的問題，Rust火了怎麼辦？首先我不認為它會火到C++的程度。這世界上瀏覽器級別的項目本來就不多，對內存安全要求極高的就更少了。然而從另一方面看，Rust的普及或許可以推廣一種安全編碼的理念，讓大家認識到很多錯誤可以消除在編譯階段，不管你用不用Rust。實際上Verifiable code這個概念最近有抬頭的趨勢。去年USENIX Security上有人給了special talk，介紹了一些人如何邊寫程序代碼邊寫coq代碼做驗證，最終弄出了一個Verified OS kernel，保證沒有錯誤。要干成這個事，程序員需要考慮的不僅僅是如何實現功能，更多的是如何編碼才容易用coq驗證。這個理念實際上和Rust的設計初衷就很相似。

總的來說Rust是集合了數十年來PL方向在類型系統和內存管理方面研究成果的一個產品，底子是相當不錯的。現在又有Mozilla做推動，用Rust寫一個世界級的產品，所以我認為這個語言還是很有前途。

幸好rust1.0出來之前沒人用，不然永遠都到不了1.0了。早期rust的設計，其實跟C++一模一樣，唯一的區別是，C++覺得應該把自己的語法發展的完美以便於讓你們把所有能寫得庫都寫出來，rust覺得標準庫就應該是語法不能讓你們有機會自己寫。

我們知道，當一門語言選擇後者，並且還堅持零代價封裝的時候，概念和語法就會變得又亂有多（看他早期支持的一萬種指針類型）。堅持前者的話，雖然語法還是很多，但是整個系統看起來非常整齊。

後來rust還是改邪歸正了，就不知道能做到多遠。

rust已經挺火的了，我觀察了steam上幾個生存遊戲，rust和h1z1在線人數大部分時候差不多，dayz稍微少點，然後是7 days to die，新出的hurtworld人數不穩定，大部分時候人數大於7 days to die

雖然rust和haskell我都不懂，但是看到這麼多括弧，我笑了。題主是會玩的

我覺得rust具備一些不易被c/c++模仿的特性，他能夠在安全領域有自己的一席之地。

我最近對著rust官網的例子做了一個教程，[oeasy]教你玩轉rust編程 - 網易雲課堂，希望對您有幫助！

我感覺rust的變數好複雜：

值為「不可變變數的引用」的不可變變數
值為「不可變變數的引用」的可變變數
值為「可變變數的不可變引用」的不可變變數
值為「可變變數的不可變引用」的可變變數
值為「可變變數的可變引用」的不可變變數
值為「可變變數的可變引用」的可變變數

T_T~~

單看rust，能不能火難說。但是rust的行為代表的PL的發展方向的大勢所趨，c太簡陋，c++不夠完美，主要是歷史包袱問題。

寫 Rust 時它的內存管理方式讓我感覺自己像是一個需要別人照顧的 baby。

lifetime 的概念讓人束手束腳。雖然 Rust 的編譯系統會始終檢查變數的生存期和引用，而傳統的C++不檢查指針，但你仍然需要大腦記憶或手工填寫引用的轉移，而且需要區分變數的可變和不可變，所做的活兒一點兒也不比使用C++等傳統語言手工管理內存的少。做這麼多麻煩的工作，帶來的效益卻相比之下卻沒那麼高，那我為什麼不直接用C++？

在性能不成問題、技術追求「方便」的今天，除非真正需要「安全」的實時系統或不可停機系統，安全真的不是一個比方便或高效更大的痛點！

當然 Rust 的安全內存管理模型除了服務於「安全」，還有一個更大的好處就是多線程內存共享，更大地利用多核CPU的效率。可是在伺服器端，支持高並發的大型系統設計如今都傾向於把內存共享的數據放置在第三方如Redis等專業內存緩存系統中，把業務數據放在進程內存中？我要5台Web伺服器共享數據怎嘛辦？

所以，除非 Rust 的內存管理能像自動引用計數或gc一樣做到全自動，讓我省去一切手工管理的麻煩，也不用區分什麼可變不可變，不要強加給我那麼多新的概念，讓普通的web程序員也能順手無痛的用起來，直接跟Python，Ruby這些語言競爭，而不是去挑戰老大哥C++的霸主地位，那麼有可能火起來。

否則，只能等每個CPU都是幾十上百個核心的時候了。

在這個動態的時代，如此底層如此靜態，還懶的一比啥事都要交給程序員的語言，要火是不可能的

rust 語言目前國外的關注度還是很高的，火起來的可能很大，我看好他哦。

光看rust的語法，就知道rust火不起來。。。

rust語法用反人類來形容，一點也不為過。。。

在JavaScript，PHP，Python，Java，C/C++，golang，rust等編程語言中，也只有rust語言的語法把我噁心到了。。。

編程語言的語法越簡單越好，rust搞了一堆莫名其妙的概念和語法，嘩眾取寵，增加初學者的學習成本。。

就語言的語法而言，rust真應該向golang學習。。。

我在這裡留言，是我這裡幾天一直用用Rust，也還沒有發現在項目使用Rust的必要，但我一直在尋找這種必要。我覺得他會火，如果有一天它火了，回頭再來看這個討論。