1樓：傑林修
其實大部分語言能做的事，彙編都能完成呢……要設計chan，明顯就是語言的設計場景會大量使用到chan。
不光光是chan，還有對應的select語法呢，兩個放一起就大概能知道設計的意圖是什麼。
大家都是圖靈完備的語言，能不能完成什麼不重要。
怎麼更快更穩定心智負擔更小的解決目標場景才重要。
2樓：蔣甬杭
先說結論：用sync肯定可以實現channel。
比如用sync包實現乙個互斥單向佇列，表面上看就相當於乙個channel。
至於go設計channel，這個是和go的核心特性——協程（go routine）有關的。go設計之初就是衝著實現CSP模型（基本上就是那句「通過通訊來共享記憶體」的出處）去的。
這意味著會有大量的併發實體和共享資料，這就需要有乙個能低開銷大量建立的併發實體，以及高效能的互斥佇列。
go的方案是routine（協程）和channel。多個協程同時訪問乙個channel的時候，由golang的排程器保證協程之間能順序（即互斥/每次乙個）訪問channel。
「routine+channel」不必用到系統核心排程，效能比「執行緒+互斥鎖」高得多。
關於「不要通過共享記憶體來通訊，而應該通過通訊來共享記憶體」這句話的本質理解，可以參考這篇回答。
如何理解 Golang 中「不要通過共享記憶體來通訊，而應該通過通訊來共享記憶體」？
3樓：2012
不同的程式設計正規化。 sync包那套不是最適合併發程式設計的（是傳統命令式程式設計模型，並不是天生為併發場景設計的），可以學習下Go語言背後CSP理論（更加適合對併發場景建模，並且是圖靈完備的）。
4樓：尚墨
參考我這篇文件了解下 sync包和channel +goroutine的不同應用場景
5樓：
通常來講，你可以用chan更快更好的現實需求。使用chan還是鎖還是原子量取決於你的時間，能力和效能指標。
chan的概念可以模擬於http api這樣的東西，也帶著一點微服務的感覺。
你可以從乙個chan裡源源不斷取出東西，而不需要關心chan的另一邊到底是什麼。當與go程結合時，擴充套件傳送端和接受端的數量會比使用鎖的時候更容易。像死鎖之類的問題使用chan的話更難遇到。
（當然如果你用chan傳送指標，或者多個chan協同工作的時候還是需要多考慮一些。但我個認為心智負擔還是小於鎖）
心智負擔下降的代價就是chan的開銷會比鎖更大一些（粗略測試10%以上），同時chan中存在資料時，接收端被喚起的時機也較為不可控，如果你希望極限效能，那麼應該考慮使用鎖。
如果你繼續看原始碼的話，你會發現鎖其實也是基於原子量實現的，如果你的能力足夠，甚至可以直接使用原子量代替鎖。
6樓：水軍代號9527
本來就是乙個很普通的生產消費者概念，用來做做事件驅動啥的挺好用的。
被go宣傳成銀彈 ，甚至宗教化，真是無言以對。
go這門語言從誕生開始的宣傳，就帶著一種眾生皆醉我獨醒的裝逼味道。
一句又一句似是而非披著「禪」外衣的slogan，騙取一波又一波的中二年紀沒見過太多世面的程式設計師的狂熱。
7樓：daemon4meng
其實 channel 原始碼裡面確實用到了 sync 包，但你能手動實現不妨礙別人把這個問題抽象出來解決共性問題對吧？
其次，這是乙個抽象維度的問題，channel 引入通道這個概念後可以方便事件的產生與處理解耦，大家面向 channel 程式設計即可，在不強要求同步的場景下是可以提公升效率
為什麼go語言語法要這樣設計呢
linfn golang 的設計者認為這樣在表達複雜型別時具有更好的可讀性禁止隱式型別轉換有助於減少 bug 用 while do while 會增加 golang 的關鍵字,這違背 golang 25 個關鍵的賣點 在 golang 中,i 是乙個語句而不是乙個表示式,區分字首自增和字尾自增沒有意...
為什麼要設計使用者等級？
已上回答都是站在非使用者角度，但區分等級這件事的受眾是使用者，我們為什麼要對使用者做分群？這個回答應來自使用者的需求，站在使用者角度考慮這個策略到底是怎麼產生的 我個人認為對使用者分群，是為了滿足不同使用者對產品 服務不同層次的要求 Case 你是乙個開麵館的，你提供的選單就是服務，有的人一碗面就滿...
圍棋為什麼翻譯成Go？
Daytun豚 因為西方陰差陽錯的從日本首次接觸到了圍棋，而並不是從它的發源地中國。從wikipedia上引用一下 Weiqi was introduced to Korea sometime between the 5th and 7th centuries CE,and was popular ...