我最近一直在和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