我最近一直在和Go一起工作，我想到了可能相同的CSP模型可以構建到.NET的未來版本中。我不是簡單地談論一個新的庫，它使用現有的線程原語提供了一個通道類型和類似的編程經驗/模型;我的意思是在整個虛擬機和編譯器中實現模型以生成與Go相當的可執行代碼（我相信Go會生成在事件循環中執行的代碼）.NET中的通信順序進程
這是否可行？之前有人談到過這個問題嗎？或者我曾經「喝過太多的助手」。就完全理解這可能如何實施而言，我肯定會對此深感失望。
從一個更熟悉Go比.NET或Microsoft生態系統更普遍的人的角度寫這個，但是試圖使用更多嵌入在該世界中的源代碼。
在Windows生態系統中不包括切換類似於圍棋的調度做一些形式的用戶模式的任務：fibers go back to Windows NT 3.51 it seems，作爲一個稍微更開發者友好的選項，user-mode scheduling，可以用來從自己的代碼調度OS線程。根據我的發現，它們都不會暴露給.NET（1，2）。
在上面關於光纖鏈接的文章中，拉里奧斯特曼解釋了一些原因，他們在2005年已經不再被大量使用。一些原因是Windows API中纖維的具體怪癖，但其他原因更一般地適用於用戶模式調度。執行一次上下文切換最近需要幾微秒;除非您希望每秒處理數十萬個交換機，否則這不會成爲問題。並且由於緩存未命中，即使完全在用戶模式下完成，切換到使用不同數據運行的不同代碼可能會導致延遲幾微秒。來自用戶線程的收益很好，但沒有理由認爲它們是成功的。
您在.NET中確實有異步編程工具，不會創建OS管理的線程，儘管這與用戶管理的線程不同。 async/await使您在執行其他操作時可以在後臺運行I/O操作更加方便，這與異步網絡配置的一些goroutines用途類似（1,2）。在.NET中，people have tried to build coroutines on yield or async/await，但這並不意味着它是一個好主意。
我喜歡Go很多，但正如我建議人們寫Go慣用語Go，我會說在.NET中編寫慣用的C＃等。在這兩種情況下，它可能會很好。
如果做發現自己有你認爲可能涉及線程的一個問題，你可以隨時check on context switch stats看到，如果你真的是做得不夠切換到無所謂，那麼如果是這樣回到你的代碼搞清楚你怎麼可能把事情控制住。當你沒有工作代碼時，擔心後來經常會太早擔心，這完全是理論上的！
一個給你也許@EricLippert –
Go不使用事件循環，而是使用自定義調度程序，就像操作系統用於本地線程的調度程序（goroutines通常稱爲「輕量級」或「綠色」線程），但它在Go運行時內部實現並編譯到任何Go二進制文件中。 – nussjustin
我不是.NET的專家，但'async' /'await'顯示[使得在不產生新的操作系統線程的情況下異步執行某些工作變得方便]（https://msdn.microsoft.com/en-us /library/hh191443.aspx）。我懷疑.NET會像Go一樣的用戶模式線程（像[纖維]（https://msdn.microsoft.com/en-us/library/windows/desktop/ms682661（v = vs.85） ）的.aspx））;變化太大了。但！我不會爲此而出汗。如果你知道.NET是直接寫的。NET代碼，關於結果的配置文件/獲取生產指標，以及選擇性異步ify /如果/看起來可能有用。 – twotwotwo