Web Developers 學習 Rust 語言?是時候了!

莫力全 Kyle Mo
9 min readNov 13, 2021

--

slides 內建的愛心怎麼有點不像愛心…

前陣子在準備 iT 邦幫忙鐵人賽JSDC 分享基本上佔用了我大多數的時間,到現在這些事情都告一個段落後我才有空靜下心來研究一些之前放在學習清單裡的技術,其中最大的一項應該就是 Rust language 了,但是發現身邊有在接觸 Rust 的人並不多,於是決定寫一篇相對輕鬆的推坑文,希望能夠推坑更多的 Web Developers 一起進入 Rust 這個美好(誤 XDD)的世界。

Rust 語言簡介

Rust 是由 Mozilla 主導開發的 System Programming Language,它融入了一些流行的高階語言的特性,卻又能達到接近 C++ 的效能,因此 Rust 也常被稱作「現代版的 C++」。

Rust 主打「Performance 與 Memory Safety & Efficient」,關於效能,其中很大一部份原因跟 Rust 不依賴 Garbage Collector 機制來管理記憶體有關,這點稍後也會有案例來佐證。而有寫過 C 或 C++ 或是有稍微接觸過的朋友一定知道開發者有很大的自由可以操作指標與記憶體,然而這使得在開發 C 與 C++ 時需要面對一些潛在的風險。而 Rust 透過嚴格的編譯器與自身 borrowing 與 ownership 的管理機制,在 compile 階段就能夠判斷程式的撰寫方式是否會有潛在風險而決定要不要報錯,當然這提高了 Rust 的入門門檻,但卻大大減少了 runtime error 的可能性,應用的穩固性與安全性也就大幅提升。

熟悉 JavaScript 開發生態的讀者應該也切身體會到有 npm 這樣的套件管理工具帶來的好處,Rust 也提供類似的套件管理工具 Cargo,並且可以在 Crate.io 這個網站找到想要使用的套件,開發體驗十分不錯。

那 Rust 語言可以應用在哪些領域呢?作為 System Language,它當然可以扮演與 C, C++ 類似的角色,但這不代表它不能拿來開發應用,以本篇的受眾 Web 開發者來說,最在意的應該是它能不能拿來開發 Web 應用,答案當然是肯定的,讓我們繼續看下去。

當然一個程式語言的語法是否符合自己胃口也蠻重要的,這邊就簡單貼上一段簡單的 Rust Code 讓各位自行感受囉!(我個人還蠻愛的啦)

為什麼 Web Developers 值得去學習 Rust 語言 ?

學會 System Programming 相關知識

一般來說軟體開發可以粗略分為「System Development 系統開發」與「Application Development 應用開發」,Web 開發者在做的就屬於 應用開發類別。系統開發需要理解比較多軟硬體的底層知識,也需要例如 C、C++ 這樣比較 low level 的 System Programming Language 才能做開發,像 Web 開發者熟悉的 JavaScript 能做到的事相較 System Programming Language 就少了許多。

Rust 是一門吸收 C、 C++等系統語言與各種高階語言優勢的 Modern System Programming,Web 開發者學習 Rust 可以補足一些關於系統底層較缺乏的知識,成為更好的軟體工程師,也可以為自己的職涯開拓更多可能性。

WebAssembly

如果你有在關注 Web 開發,一定跟我ㄧ樣都對 WebAssembly 充滿期待。

我們來看看維基百科對於 WebAssembly 的介紹:

WebAssembly 是一種新的低階程式語言,可在今日的網頁瀏覽器中被執行 — — 它是低階的類組合語言,具有嚴謹的二進位格式,能以接近原生應用程式的效能執行,並提供如 C/C++/Rust 等語言一個構建目標,使它們能在 Web 上被執行。他也被設計為可與 JavaScript 共存,允許兩者一同工作。

(如果不清楚 WebAssembly 的讀者可以參考我在今年鐵人賽的文章。)

而 Rust 則是擁有對 WebAssembly first class support 的特性,toolchain 相對於其他可以開發 WebAssembly 的語言完整許多,因此在開發速度與體驗上一定也會有一定的優勢,因此 Rust 目前普遍被認為最適合開發 WebAssembly 的程式語言。

我們甚至可以用 Rust 開發整個前端專案

Rust 當然有許多 Server-Side 的 framework,比如說最廣為人知的 actix-webrocket,但是你知道 Rust 也可以拿來開發整個前端應用嗎?(我知道這很令人震驚)

隨著 WebAssembly 的發展,出現了一些 Rust based 的前端框架,顛覆了以往只能用 JavaScript 來開發前端的刻板印象(但我認為 JavaScript 依舊不會輕易被取代),其中比較火紅的是 yew 這個 component based 的框架,我們來看看官方的介紹稍微感受一下它到底是什麼樣的專案

關於更多 Rust 在 Web 開發領域相關的 frameworks 可以參考這個 repo

Most loved Language

根據 Stack Overflow 的調查,Rust 是 2021 年最受開發者喜愛的程式語言。

所以我說關於 Rust 的職缺…

嗯…台灣目前幾乎沒有 Rust 相關的職缺…

就算有,也會發現大部分都是區塊鏈開發相關的職缺,而且數量也非常少,可以說現在要只靠 Rust 在台灣找到一份不錯的工作是非常困難的。那為什麼還要推坑?講白了就是我非常看好它未來的發展,現在已經有許多科技巨頭開始使用 Rust 在做開發,我認為未來兩三年後 Rust 在台灣會慢慢流行起來。加上剛剛提過的 WebAssembly,不難想像 Rust 的未來只會更加茁壯。

(不過如果你是急著找工作,目前可能就不適合把全部希望都寄託在 Rust 上囉,當然,要直接挑戰有在用 Rust 的科技巨頭也是可以的啦 XDD)

哪些企業已經在使用 Rust 後看到不錯的成果 ?

與其看一些玩具等級的應用,不如來看看目前有哪些大型企業或應用在使用 Rust 後獲得了不錯的效益,甚至得到超乎他們原先預期的成果。

  • Discord

Discord 我想大家都有使用過,其中有一個官方稱作「Read States」的服務,主要功能是追蹤使用者在哪些 Channel 看過哪些訊息,光看功能就知道是一個需要頻繁操作確保資料的即時性且需要盡量保障速度的服務。這個服務原本是用 Go 語言開發的,但 Discord 團隊發現這個服務每一段時間效能就會出現一些瓶頸,trace 一下後發現原因出在 Go 語言的 Garbage Collection 機制,Go 語言在 GC 上與 JS 一樣是開發者不可控的,一段時間就會強致執行的狀況就產生了週期性的效能瓶頸。Discord 團隊在嘗試了許多方式後依然沒辦法解決這個問題。最後它們嘗試使用 Rust 來重新開發這個服務,Rust 的 memory efficient 特性相當完美的解決這個問題,甚至在其他方面比如說 CPU 使用量的表現也勝過原先使用 Go 開發的版本。

  • Next.js Rust Compiler

Next.js 將 Compiler 以一個基於 Rust 的工具 SWC 重構後,大大的減少 build 與 hot module refresh 所需要的時間,提升了開發者體驗。有興趣的讀者可以參考這篇官方文章

Rust 免費學習資源推薦

這應該是我看過最完整的 Rust 影片教學頻道了,從基礎概念到進階概念都有涵蓋,不過比較少實戰應用的教學影片,但還是十分建議剛學習 Rust 這門語言的朋友可以去看看。

又被 Rust 開發者稱作「The Book」,是非常詳盡的官方文件。

近期由微軟推出的 Rust 教學影片(夠大咖了吧😂),內容是專門為 Rust 初學者製作的,非常值得一看。

以上推薦的學習資源都是偏向 Rust 語言基礎與特性,如果你跟我ㄧ樣之前沒有學過 C, C++ 這類 System Programming Language,在剛開始學習 Rust 時會比較辛苦,不過在學習這些基礎時也會深刻感受到 Rust 的獨特性與許多優點,所以撐下去把基礎打好吧!

結語

Rust 從首次公開後 10 年也這樣過去了,也許之前就跑去學有點操之過急,但現在我會說:「是時候了!」以 Web 開發者來說,WebAssembly 的漸漸成熟帶來了非常多可能性,對 WebAssembly First Class Support 的 Rust 當然就成了首選,除了 WebAssembly 以外,Server Side、Compiler 、Cloud 都有很多適合 Rust 發揮的空間。此外也出現越來越多使用 Rust 開發獲得成功的案例,在 GitHub 上也可以看見越來越多使用 Rust 開發的開源專案。我認為現在就是個值得開始學習 Rust 的時間點,一起進入這個語言奇幻的世界裡吧!

--

--

莫力全 Kyle Mo
莫力全 Kyle Mo

Written by 莫力全 Kyle Mo

什麼都想學的雜食性軟體工程師 🇹🇼 (https://github.com/kylemocode) 合作與聯繫 📪 oldmo860617@gmail.com IG 技術自媒體:@kylemo.webdev.life

Responses (1)