事件起因是 AWS 前幾天釋出的一篇部落格：。
在這篇文章裡，AWS 舉例的時候將 Rust 和 Go 進行了對比。文章提到了早期 Discord 的一項關鍵 Go 服務存在問題，原本這是一個非常簡單的服務，但它的尾部延遲 (Tail Latency) 非常慢。AWS 認為原因在於 Go 是一種垃圾回收 (GC) 語言，因此當物件被建立和釋放時，垃圾回收器每隔一段時間就需要停止程式的執行並執行一次垃圾回收。當垃圾回收器執行時，會導致程序無法響應請求。
為了解決此問題，Discord 決定嘗試用 Rust 重寫這個服務。測試結果顯示，使用 Rust 重寫後的速度提升超 10 倍，最慢的尾部延遲時間也降低至為原來的約 1%。
下圖是執行過程中 CPU 和響應時間的峰值，左邊為 Go 實現的版本，右邊為 Rust 實現的版本。
Go 開發團隊 leader Russ Cox (rsc) AWS 在這裡的比較對 Go 存在嚴重的誤導。他認為，AWS 的文章將兩者進行對比時，將 Go 版本的資料與在使用新的資料結構和更多記憶體後的 Rust 版本資料放在了一起，還特意圈出「ms」和「µs」時間刻度。rsc 表示，這要麼是 AWS 對 Discord 的原貼存在誤解，要麼就是公然地說謊。
因為，他們展示 Go 伺服器和同級別 Rust 伺服器的對比時，圖表資料來源既有原始的版本，也包括重寫資料結構和提供額外記憶體後的情況。AWS 的文章卻對此進行了故意的歪曲。
而且 AWS 參照的 Discord 資料當時使用的 Go 版本還是 Go 1.10，但現在 1.18 版本很快就推出了。在這 8 個重要版本的迭代過程中，Go 團隊改進了許多功能，對因 GC 而引起的中斷也提供了極大的改善（這正是當時 Discord 面臨的問題）。
除了這個，rsc 認為 AWS 參照的一份「的真實性也十分可疑。
rsc 表示，AWS 的文章對 Rust 的描述公正客觀，但對 Go 卻存在誤導性的描述。他認為 Rust 和 Go 不是零和的博弈關係。Rust 十分優秀，所以他更願意關注 Go 和 Rust 相互補充並進行良好合作的方式。比如這個案例：