在許多不須要易變性的狀況下，它強制用戶進行易變性。它附帶了一個僞依賴管理器，它缺少獨立項目的獨立版本控制。與大多數其餘流行的系統編程語言(即C、C++、Ada、Fortran和Rust)相比，它的速度很是慢。git
這就是我如今能想到的，很容易就能給大家展現的東西。一旦你深刻研究go，你會發現它會作出一些固有的錯誤設計選擇，它是爲1980年而不是2020年設計的語言。程序員
儘管如此，就像任何曾經使用過go的人都能告訴你的那樣，這是一種很是好的語言。若是我被困在一個只有三種編程語言的島上，我想go會成爲其中之一。github
儘管存在全部的缺陷，但它容許您編寫性能良好的相對無錯誤的代碼。向Go程序添加依賴項一般比向C++程序添加依賴項要順利得多。數據庫
爲何 Go 是棒的編程
這讓我處於一個很是奇怪的位置。 一方面，我能夠談談 Go 有多可怕。 另外一方面， Go 顯然是一種很是好的語言。緩存
爲了弄清楚爲何是這樣的，咱們依然須要回到程序員解決問題的角度，把語言做爲工具來看。安全
不少現代世界的問題看起來都是圍繞着有效網絡通訊，圍繞安全地利用全部硬件線程以及更容易的開發和部署展開的。網絡
最後，漸漸有了一個穩定的趨勢，良好的開源庫滲透到咱們的生活中，其中大多數是簡潔和簡單，適合單一目的。大多數 Node 或 Python 項目都有數百個這樣的依賴項，而大多數 C 和 C ++ 代碼庫都有十幾個。 C 和 C ++ 缺少任何標準化的包管理，所以庫每每是無所不包的總體（參見 QT 和 Boost ），而它們添加新的依賴項很是耗時。併發
開源庫是現代開發人員生涯中的重要組成部分，但全部流行的系統編程語言都缺少包管理。異步
從這個角度來看，Go有一些中心特徵，這些特徵很是讓人驚歎，以致於它們把全部很差的一面都掩蓋了。
-
Go 的實用程序容許您輕鬆下載和使用包。
-
靜態編譯使得在不一樣環境之間移植代碼，而且能夠很容易地創建開發環境。
-
本地異步 I/O 機制容許您能夠輕鬆編寫高性能的網絡代碼。
-
內置通道容許在 [g|c]oroutines 之間輕鬆實現和相對安全的數據傳輸。
-
標準庫和包生態系統包含了開發人員可以須要的大多數庫。
-
對於幾乎全部的使用案例來講，它「足夠快」。彷佛在如 Python 和 Node 這些易於使用的單線程語言，甚至是像 C++ 和 C 這樣的古老而又快速的龐然大物之間找到了一個最佳位置。
或者，說白了， Go 是一種專爲開源庫，大規模並行和網絡計算而設計的語言。
其餘流行語言則缺乏這三個類別中的一個。
Go的全部剩餘問題源於三種設計選擇：
-
垃圾收集，而不是爲其全部資源定義編譯時間的生命週期。 這會損害性能，刪除有用的概念（如移動語義和析構函數），並削弱編譯時錯誤檢查功能。
-
缺少不可變性,除了少數（本機）類型以外。
-
缺少泛型
若解決這些問題，Go無疑會成爲將來的語言。 可是，因爲各類問題，有些與先前的設計決策有關，有些又與設計師的意見有關，其中大部分都未解決。
例如，泛型可能會在2.0上實現，可是當前的實現與其餘特徵（好比接口）重疊，同時使用起來又煩惱而且缺乏特徵（好比，不能用做返回類型）。
或許咱們能夠找到一種「檢查」全部正確語法的語言，又不用忍受那些糟糕的設計決策。
再來看看 Rust 語言
Rust 恰巧是一門解決了Go 全部問題的語言。
基於它的隱式移動語義和借用檢查功能，使它在資源管理領域最終成爲了最安全，最快速而且也最容易使用(這裏是相對來講。好比目前借用檢查比較難用，用過的都知道)的語言。它在編譯期間就能夠捕獲大多數錯誤。
模板和特性(traits)組合給了它接近於C++的編譯時編程能力，甚至某些方面更勝一籌。
最後，Cargo 也是最好的包管理系統之一，它可讓你更容易地使用各類實用的公共庫，而且有內建版本號和項目隔離特性。
換句話說，Rust的極大成功就是基於它更好地解決了Go存在的問題。
可是，Go 作得無比正確的事又有哪些呢？
-
go get 和 go mod與Cargo很是匹配
-
cargo build 默認使用靜態編譯路由，這一點和 go build 基本一致
-
重點來了，Rust 目前尚未原生異步 i/o 機制。可是聽說這個機制立刻就有了。這個機制與 goroutine 所提供的功能差異很大，而是更像咱們所熟知的 Node 和 Python中所使用的語法。
-
Rust 不只提供了線程之間的原生管道(channel)支持，它提供了一套健壯的編譯時線程安全檢查機制。這意味着不管你使用何種數據共享機制都不存在併發錯誤的風險。
-
儘管 Rust 是一門年輕得多的語言， Rust 的標準庫和 go 的差很少同樣豐富，固然除了（再次除了）一些沒有的異步網絡功能以外。當前 Rust 的包(package)生態系統和 Go 的一些方面很像。
-
最後是效率方面。在大部分的場景下， Rust 只比 C 和 C++ 稍慢那麼一丟丟。可是對於它的設計方向來說這只是一個「臨時性的」折扣。Go 將永遠受累於缺少編譯時邏輯和基於 GC 的設計。所以，Go 和 Rust 之間現有的巨大效率差只會越拉越大。
Go 的影響
一旦 async/await 特性被合併到Rust的穩定版中，我認爲Rust就徹底超越Go了，確切地說，在任何方面！(譯者注：借用檢查仍舊是致使Rust難用的一個緣由，最好是有更多的隱式借用或更好的方案)
我認爲直到將Rust真正應用於產品中，人們纔會認識到Rust在測試，調試和程序崩潰等方面爲你節省了多少時間。
Rust和Rust相關的概念進入編程世界越多，人們就會越熟悉它的語法和概念，所以進入的門檻也就越低。
我認爲Rust已經走過了它生命中最危險的時期，它已經逐漸地被接受並做爲主要開發語言。更進一步講，當與其它語言在各方面比較時，它幾乎是完勝其它語言(編者：各類語言特性方面確實是，但易用性上還差些)。簡單講，在大多數狀況下，Rust應該是更好的選擇。
可是人的惰性是不可忽視的一個問題，Rust很難被你們普遍採用的阻力，來自於如何說服開發者轉換到它上面。
這裏，我認爲Go忽然爆發的緣由，也能夠一樣應用於Rust身上。Rust如今愈來愈接近全面爆發了(譯者注：隨着生態成熟，也快到引爆點了)。
一些但願有「現代編程範式」的C&C++開發者，也會喜歡上Rust。
同時，對於一些但願從腳本語言轉到系統編程語言上的那些人來講，這也是最好的選擇，你不但擁有了安全和性能，你還仍舊可使用包管理工具和熟悉的語法。
不管如何，這是個人預測，一旦 async&await 加入到語言中，咱們將有大量的網絡應用程序開發人員涌入Rust。
網絡依賴的高性能開源軟件，如內存緩存，數據庫和反向代理，將開始逐步走向成熟。 不少這樣的項目已經在 go 的生態系統中出現了。
一旦這些開發人員在網絡和併發性方面嗅到了 Go 的簡易性，再加上 C++ 的速度，抽象能力和資源管理，以及頂級的編譯時安全性......
隨後，Web 開發人員和企業團隊將跟隨宣傳。
一切就猶如打開了防洪閘門，不可阻擋。
George Hosu https://github.com/George3d6 我很擅長命名東西，並清楚如何使緩存無效。