應 QCon北京2016|全球軟體開發大會 主編臧秀濤邀請，我（Liigo）于2016年4月23日在大會上做主題演講《Rust程式設計語言的核心優勢和核心競争力》（PDF演講稿）。由于是初次登台，現場表現不佳，個人不是很滿意。故做本文對此次演講進行總結和補充。
核心三要素：系統程式設計，零運作時，記憶體安全
我把Rust程式設計語言的核心優勢和核心競争力概括為三個要素：系統程式設計，零運作時，記憶體安全。在強調底層控制的系統程式設計領域，同時保持極小的運作時開銷和極高的運作時效率，又保證了系統記憶體安全的現代程式設計語言，Rust幾乎可以說是唯一的一個。這三個核心要素是過濾器，提高了競争門檻，把許多對手拒之門外；同時也是一把雙刃劍，把Rust自身限制為一個小衆語言。（百姓網賀師俊老師現場提問說Rust啥時候能火起來，我說Rust頂多在系統程式設計領域小火一把，而系統程式設計在整個IT行業内也隻是小衆領域而已。Rust學習曲線陡峭，對程式員程式設計能力要求較高，不具備成為網紅的潛力。我在現場的表述既啰嗦又不條理。）
對于系統程式設計，我總結道：系統程式設計是軟體行業的基石，很多基礎性的、平台性的大中型項目，或者隸屬于系統程式設計，或者依賴于系統程式設計；系統程式設計強調底層控制、運作性能和系統安全；目前主流的系統程式設計語言C/C++在記憶體安全方面有重大欠缺。針對Rust和C/C++的競争，我認為Rust的記憶體安全是競争優勢，C/C++的曆史地位和積累是競争優勢，長遠來看還是Rust潛力更大。
對于零運作時，我總結道：Rust語言的設計和實作十分重視運作時性能，盡力避免任何非必要的運作時開銷，僅當與記憶體安全産生沖突時才有所妥協；Rust的運作性能跟C/C++在同一個數量級上。演講中提到，“不為用不到的特性付出代價”是C++的設計原則同時也是Rust的設計原則。并針對無GC、無VM、無解釋器，疊代器(Iterator)，動靜态分派(Static-,Dynamic-Dispatch)，FFI，Thread，IO等操作做了運作時開銷分析。特别地，強調了Rust語言不強制使用垃圾收集器(GC)，沒有明顯的運作時開銷。
對于記憶體安全，先說為什麼記憶體安全很重要。然後逐一介紹Rust如何保障記憶體安全，其中涉及所有權(Ownership)、所有權轉移(Move)、租借(Borrowing)、生命周期(Lifetime)等。
演講之後的提問環節，除了上文提及的賀老師火不火的問題，還有個朋友問Rust跨平台的表現。我說，Rust标準庫(libstd)是跨主流作業系統平台的（Unix/Linux/Windows/Mac），而Rust核心庫(libcore)則跨更多平台，甚至可以工作在沒有作業系統的裸金屬(Bare metal)硬體環境中（此處可聯想Rust“鏽”之命名）。現場表現有些語無倫次。
另有朋友提問Rust和Go的差別。我回答說，Go是有GC的語言，而Rust沒有GC，Rust屬于系統程式設計而Go不是，故二者在各自核心應用領域沒有競争關系。提到GC我又順便抛出“個人以為Go的GC有很大的問題”。然而因為沒有進一步的闡述，導緻這個結論很蒼白無力，難以令人信服。我在現場試圖用兩天前百度陶春華《Golang 在 Baidu-FrontEnd 的應用》的演講内容相印證，卻一時想不起演講者和标題（其實早已寫在我的演講稿裡），隻得作罷（欲言又止）。陶老師演講中提到，在他們的應用場景中，從Go 1.3更新到1.5 1.6并不能緩解遇到的GC問題；或許是号稱“解決了GC問題”的Go 1.5 1.6無視了該應用場景。不清楚這是不是個例，好像Dropbox也遇到類似的情況（也用Go 1.3）。我的另一篇博文有其他開發者回報Go之GC問題。
在這個現場交流環節我犯了一個比較嚴重的技術性錯誤。我不應該提及“GC的問題”，而隻需提及“GC較大的運作時開銷”，這樣能更好的銜接演講内容，同時營造更好的溝通環境——而不是對立情緒。
演講結束後，有中興公司的同行私下找我咨詢Rust成功應用案例，同時抱怨C語言的記憶體安全痛點。我順勢擺出Rust“兩個半”大型成功案例：Rust編譯器，Servo浏覽器引擎，Cargo項目建構管理器；再加上Redox作業系統和Maidsafe安全網絡。一時之間沒想起來還有，Dropbox的Magic Pocket，Piston遊戲引擎。
2016年6月23日更新：大會現場照片
2016年6月26日更新：明星講師禮品，山地車
很榮幸獲得主辦方評選的明星講師榮譽，感謝InfoQ/極客邦。