其實比較Akka和goroutine並不太合適，二者不是同一個層面的東西。應該比較Akka的Actor模式和Go的CSP模式。

二者都是透過訊息通訊的機制來避免競態條件，但具體的抽象和實現上有些差異。

CSP模型裡訊息和Channel是主體，處理器是匿名的。也就是說傳送方需要關心自己的訊息型別以及應該寫到哪個Channel，但不需要關心誰消費了它，以及有多少個消費者。Channel一般都是型別繫結的，一個Channel只寫同一種類型的訊息，所以CSP需要支援alt/select機制，同時監聽多個Channel。Channel是同步的模式（Golang的Channel支援buffer，支援一定數量的非同步），背後的邏輯是傳送方非常關心訊息是否被處理，CSP要保證每個訊息都被正常處理了，沒被處理就阻塞著。Actor模型裡Actor是主體，Mailbox（類似於CSP的Channel）是透明的。也就是說它假定傳送方會關心訊息發給誰消費了，但不關心訊息型別以及通道。所以Mailbox是非同步模式，傳送者不能假定傳送的訊息一定被收到和處理。Actor模型必須支援強大的模式匹配機制，因為無論什麼型別的訊息都會透過同一個通道傳送過來，需要透過模式匹配機制做分發。它背後的邏輯是現實世界本來就是非同步的，不確定（non-deterministic）的，所以程式也要適應面對不確定的機制程式設計。自從有了並行之後，原來的確定程式設計思維模式已經受到了挑戰，而Actor直接在模式中蘊含了這點。從這樣看來，CSP的模式比較適合Boss-Worker模式的任務分發機制，它的侵入性沒那麼強，可以在現有的系統中透過CSP解決某個具體的問題。它並不試圖解決通訊的超時容錯問題，這個還是需要發起方進行處理。同時由於Channel是顯式的，雖然可以透過netchan（原來Go提供的netchan機制由於過於複雜，被廢棄，在討論新的netchan）實現遠端Channel，但很難做到對使用方透明。而Actor則是一種全新的抽象，使用Actor要面臨整個應用架構機制和思維方式的變更。它試圖要解決的問題要更廣一些，比如容錯，比如分散式。但Actor的問題在於以當前的排程效率，哪怕是用Goroutine這樣的機制，也很難達到直接方法呼叫的效率。當前要像OO的『一切皆物件』一樣實現一個『一切皆Actor』的語言，效率上肯定有問題。所以折中的方式是在OO的基礎上，將系統的某個層面的元件抽象為Actor。如果純粹從排程的層面分析，正如 @邱鵬滔 的回答，Akka是線上程池基礎上實現排程的，但執行緒是有限的，所以Akka的Actor中要避免任何阻塞操作，要麼用Akka提供的非同步框架，要麼透過Future-callback機制，轉換成回撥模式。而Goroutine是使用者態的執行緒，建立和切換成本都比較小，可以把非同步的callback機制轉換為同步模式，對開發比較友好些。更詳細的分析請參看我的文章： 併發之痛 Thread，Goroutine，Actor