Rust能做后端開發語言嗎

這篇文章主要講解了“Rust能做后端開發語言嗎”，文中的講解內容簡單清晰，易于學習與理解，下面請大家跟著小編的思路慢慢深入，一起來研究和學習“Rust能做后端開發語言嗎”吧！

語言簡介

相對于其他語言來說，Rust屬于最新的一個成員。最早由Mozilla于2014年4月9日發布。Rust是一款高級通用語言，而且屬于少有的一款兼顧開發和執行效率的編程語言。Rust結合了腳本語言的語法結構和C語言編譯執行效率，并且具有類似垃圾回收和數據類型及所有權系統等功能，所以可靠性和高性能運行都屬于Rust的特色。雖然是一個非常年輕的編程語言，但是Rust可以算是最近幾年最流行的編程語言。5月發布的Stack  Overflow  2020開發者調查中，Rust被86.1%開發者選擇為“最喜歡”的編程語言，比第二名TypeScript高出近20%。雖然Rust并不是一個專屬的網絡應用開發語言，但是作為一個以安全著稱的編輯語言，實際上是非常適合網絡開發的。而且因為是編譯型語言，編譯器也能在過程中就安全穩定的問題作出提醒，作為后端網絡開發還是不錯的一個優勢。

來自mozilla的Rust

服務器支持

Rust的通用庫中已經包含了類似TcpListener這樣的網絡通訊庫，可以直接通過調用std : : net  下面的TcpListener來直接監聽Tcp端口，然后再處理Request。這點上與一些腳本型的編程語言比要自由得很多。Rust作為比較流行的編程語言，也有不少第三方HTTP庫來支持Web開發，可以不用再花時間從底層開發，比較熱門的庫像Hyper或者Tide都是被不少Web開發框架用到的。Rust下Web開發框架也不少，比較熱門的有Rocket、Actix-Web、Tower-web、Warp等等框架。因為初次接觸Rust，所以還是先從比較成熟的框架Rocket來作Demo的嘗試，相對文檔會比較完善一些。不過，根據網上的一些討論，Rocket或是Actix-Web雖然比較熱門，但是因為基于比較老的hyper庫，所以可能對于一些功能不支持，例如Rocket不支持Async/Wait功能。不過總的來說Rust對于服務器的支持還是不錯的，而且就算找不到合適的開發框架，也可以從底層開發，雖然比較浪費時間。

Rocket

IDE VS Editor

Rust基本支持主流的編輯器

Rust基本上沒有直接IDE，只是通過插件的方式集合在一些IDE或者編輯器中，Rust對于主流的編輯器基本都支持。因為對于VS  Code比較熟悉也就直接通過VS Code安裝了Rust插件，然后結合通過以下的shell 安裝好Rust以及Cargo，就基本安裝好了開發環境。

curl --proto '=https' --tlsv1.2 -sSf https://sh.rustup.rs | sh

Rust會通過Cargo來處理依賴的庫，而且在編譯的時候來拉取的，因為一些眾所周知的網絡問題，拉取速度非常慢。需要將第三方庫的注冊表網站crates.io換成國內鏡像。修改成國內鏡像的方式，在cargo安裝文件夾下新建config文件，一般cargo的安裝位置如下：

$HOME/.cargo

然后在新建的config文件中加入國內鏡像的信息，例如使用gitee的鏡像的話，文件內容如下：

[source.crates-io] replace-with='crates-cn' [source.crates-cn] registry="https://gitee.com/crates/crates.io-index.git"

不過使用之后，發現gitee的index并不是最新的，就像最新的Rocket版本0.4.5就沒有被收入，所以換成了中科大的鏡像，文件內容可以改成相應的git鏈接，如下

[source.crates-io] replace-with='ustc'  [source.ustc] registry="https://mirrors.ustc.edu.cn/crates.io-index"

雖然說Rust沒有自己的專屬IDE，不過Editor+插件的方式基本可以雷同于IDE，而且整體開發環境的配置還是非常直觀的。

VS Code的Rust插件

RESTful vs GraphQL

通過Rust實現RESTful規范的接口，整體來說還是比較直觀的，Rust下比較流行的第三方Web開發框架都會支持路由功能，雖然不同的框架支持的方式不同，不過本質上都是通過掛載一個根路徑，然后通過框架支持的Macro來將不同路徑來指向不同函數來處理，我是用Rocket來做這個RESTful接口的Demo的，除了Rocket服務器啟動和根目錄掛載基本上，就是三行如下的代碼就可以設置好一條路徑：

#[get("/herb/<uid>")] pub fn get_herb(uid:i32) -> Result<Json<Vec<Herb>>, String> {     //數據連接和業務邏輯 }

當然可以將所有路由放在一個模塊內，然后在主程序內調用，類似如下的啟動Rocket服務器就可以運行了

fn main() {     rocket::ignite()         .mount("/", routes![             routes::get_herb         ])         .launch(); }

RESTful接口demo的測試結果

對于GraphQL來說設置上會稍微復雜一點，需要通過第三方的GraphQL庫來實現，我使用了Juniper，同時嘗試了另一個Web開發框架Actix-Web，整體開發效率還是非常快的，主要還是得益于Rust的Macro機制，基本上很多方法都通過Macro來關聯到了相應的對象上，直接在需要的地方調用就可以了。不過對于GraphQL要多一步設置Schema的過程，不過對于處理函數的添加還是比較直觀的，比之前使用Go的時候要更便于維護。在設置完Schema之后，只需要在RootQuery中添加相應的函數就能實現不同的業務邏輯，如下面包含兩個函數，調用全部對象和查詢單一對象的函數：

#[juniper::object] impl QueryRoot {     fn herbs() -> Vec<Herb> {         use crate::schema::herbs::dsl::*;         let connection = establish_connection();         herbs           .limit(100)           .load::<Herb>(&connection)           .expect("Error loading members")     }     fn herb(_uid:i32) -> Vec<Herb> {         use crate::schema::herbs::dsl::*;         let connection = establish_connection();         herbs         .filter(uid.eq(_uid))           .load::<Herb>(&connection)           .expect("Error loading herbs")     } }

GraphQL接口demo的測試結果

經過這兩個不同規范的，Rust高開發效率的特性非常好的體現了，只要熟悉了Rust語言規范之后，整體開發效率還是非常高的，很多代碼會通過Macro機制省略了。如果選擇Rust的話，感覺使用GraphQL的機會會更高，畢竟RESTful和GraphQL之間的開發成本差不多，那么GraphQL的自由度就更高了。

數據庫連接

Diesel使用起來還是比較方便的

我使用了Diesel這個比較流行的數據庫連接框架，是設置和初始化的過程中，體現出了Rust比較類似其他系統語言的地方，在安裝了Diesel命令行工具之后，只需要通過下面幾行命令行就能直接設置好數據庫以及migration的配置

//安裝diesel_cli，最后的參數是根據使用的數據庫來設置的 >cargo install diesel_cli --no-default-features --features mysql  //將數據庫連接數據添加到項目根目錄的.env文件中 >echo DATABASE_URL=mysql://username:password@localhost/database_name > .env  //然后設置就可以了 >diesel setup

這樣diesel會了連接到數據庫服務器，如果數據庫不存在的時候，會自動生成一個數據庫。然后通過新建一個migration來添加數據庫中的表

>diesel migration generate migration_name

這樣就會在項目根目錄下migrations文件下生成當前時間為前綴的文件夾，其中有兩個文件，up.sql  存放新建表需要的sql語句，down.sql存放up.sql內相關新建語句的銷毀語句，例如：

//up.sql CREATE TABLE IF NOT EXISTS herbs (   uid int PRIMARY KEY AUTO_INCREMENT,   cn_name varchar(255) NOT NULL,   en_name varchar(255) DEFAULT NULL,   latin_name varchar(255) NOT NULL,   botanic_name varchar(255) DEFAULT NULL,   part_used varchar(255) NOT NULL,   common_name json DEFAULT NULL,   country_of_origin json DEFAULT NULL,   description text,   harvest_season varchar(255) DEFAULT NULL,   grow_duration varchar(255) DEFAULT NULL )  //down.sql DROP TABLE herbs

添加好相應的SQL語句，在運行如下命令就基本上設置好了Diesel

>diesel migration run

也可以通過以下命令來重置數據庫

>diesel migration redo

Diesel會直接在項目根目錄下的schema.rs文件中根據數據庫表的結構生成好相應的數據結構。然后通過diesel支持的Macro，建立同樣結構的struct就可以直接調用數據庫中的數據條了。例如對于可以查詢的數據條，可以在struct定義之上添加如下的Macro

#[derive(Queryable)] struct Herb {     uid: i32,     cn_name: String,     en_name: String,     latin_name: String,     botanic_name: String,     part_used: String,     common_name: String,     country_of_origin: String,     description: String,     harvest_season: String,     grow_duration: String, }

這樣就可以直接通過在相應的業務邏輯中通過filter，load等查詢函數了。

整體來說Diesel在開發過程中非常簡潔明了，就算初次接觸的話，也是能直接掌握，對于之后比較復雜的數據庫操作自由度不確定是否足夠，不過對于一般項目的數據操作還是足夠的。

語言結構

Rust的語言結構同時是優勢也是劣勢。對于初次接觸的時候，Rust的語言結構非常令人疑惑，主要是其中的一些調用符號，比如->, : :,  <>等等，不過熟悉之后就會覺得這些符號也算比較直觀，而且在不同場景使用不同的符號讓代碼的可讀性反而提高了。

然后Rust高開發效率的特性也通過Macro機制體現的淋漓盡致。通過不同derive  Macro設置可以直接將相應的抽象函數添加給struct，這樣可以少寫很多代碼。例如下面我給這個struct添加了數據庫查詢(Queryable)的同時，添加了JSON的Serialize和Deserialize的功能。這樣在查詢出數據條可以直接調用JSON的map函數來生成JSON字符串。

#[derive(Serialize, Deserialize, Queryable)] pub struct Herb {     pub uid: i32,     pub cn_name: String,     pub en_name: String,     pub latin_name: String,     pub botanic_name: String,     pub part_used: String,     pub common_name: String,     pub country_of_origin: String,     pub description: String,     pub harvest_season: String,     pub grow_duration: String, }

這個對于RESTful接口非常有用，可以將數據庫的查詢結果直接map然后返回。

總的來說，一開始會覺得Rust是比較復雜的編程語言，不過熟悉了之后，還是非常喜歡Rust簡潔的代碼結構和高效的開發體驗。

文檔社區

作為一個比較熱門的編程語言，Rust的開發社區還算是比較活躍的，不過因為畢竟Rust還是一個非常年輕的編程語言，很多第三方框架也都比較年輕，  有些框架還都沒有完全達到1.0版本，而且文檔相對也是比較簡單的。不過Rust的穩定性應該會延展到第三方框架的開發上的，雖然大型項目可能不一定適合，但是絕大多數項目還是可以支持到的。

文檔也是同樣的問題，作為比較年輕的語言，除了官方文檔以外，文檔或是解決方案相對會少不少。而且很多文檔還是以英文為主還沒有中文化。但是以開發社區的活躍度來看，應該不需要多少時間就會出現很多文檔和問題解決方案出現。

總結

作為一個主要面向系統開發的語言，一開始的確會因為Rust的復雜度而有點無從下手，不過熟悉了之后的確能感覺到Rust的高開發效率特性。而且，作為編譯型語言來說，執行效率應該沒有任何問題，不過因為過于年輕，Rust下支持的第三方開發框架還不算穩定，可能會出現一些Bug。不過通過有限的幾個Demo開發來看，還是勝任一個普通項目的后端支持的。而且和Go一樣，作為比較年輕的編輯語言，未來的發展空間還是比較大的。雖然只是接觸了1個多星期，也沒有非常深入的開發過，但是我的確已經喜歡上這個語言了，不愧為Stack  Overflow最受歡迎編程語言的殊榮。

感謝各位的閱讀，以上就是“Rust能做后端開發語言嗎”的內容了，經過本文的學習后，相信大家對Rust能做后端開發語言嗎這一問題有了更深刻的體會，具體使用情況還需要大家實踐驗證。這里是億速云，小編將為大家推送更多相關知識點的文章，歡迎關注！