对我而言，我认为F＃是一个糟糕的选择，因为它在幕后使用线程。对我而言，由于上下文切换等问题，线程太“沉重”。
我可以看到为什么Erlang是一个很好的选择，因为它使用了轻量级的过程。
我错了吗？
答案 0 :(得分：23)
我不明白你在问什么。
F＃不使用'幕后线程'，或者至少不比任何.NET进程更多。实际上，F＃的async工具使得编写不使用线程的非阻塞I / O程序变得更加容易（与具有更难的无线程/非阻塞编程模型的C＃/ VB相比）。
（当然，通常你不只是挑选一个任意方面来比较两件事，然后决定'X比Y更好'。编程语言不仅仅是一个线程/流程模型。）
您可能喜欢阅读
最后三段值得引用：
实际上，很少有其他.NET或 支持基于JVM的语言 轻质反应剂根本 - 在早期的.NET中据说是 “不可能”，因为成本 线程。在这种背景下，F＃的 在2007年整合了“async {...}” 可以看作有点像 应用语言的突破 设计 - 它允许轻量级， 组合异步编程和 在一个环境中的反应性因子 工业上接受和 可互操作的编程平台。 随着Axum语言原型 （对F＃有影响力），F＃ 已经证明是异步的 语言特征是一种可行的方法 突破“我们这样做的僵局” 使线程轻量化或不“那个 目前bedevils工业运行时 系统设计。
F＃异步编程可以看作是 实施恢复，和 这里有许多前兆，因为 示例OCaml分隔延续， Haskell嵌入monadic 并发和论文强调了 关于恢复的重要性 并发。
您可以使用F＃异步代理 Linux / Mono / Mac上的.NET 2.0,3.5,4.0 并在Silverlight上。的确，你可以 F＃时甚至使用F＃异步编程 被翻译成Javascript使用 WebSharper平台。享受！
答案 1 :(得分：12)
自2006年以来，erlang已经拥有了SMP，所以它也“在幕后使用线程”。 erlang中的进程和F＃中的（AFAIK）异步任务都不对应于OS线程;两个运行时都在需要时使用线程，并在适当的时候使用更轻量级的机制。
答案 2 :(得分：10)
如果你想获得一些有用的反馈，你应该指定你感兴趣的场景。但是，函数式编程不是关于线程或进程 - 它更多的是表达算法和使用不同的编程模式，所以使用线程/进程是比较函数式语言的一个非常奇怪的标准。
最重要的是，在F＃中，并发编程只是库的问题，有很多选择：
async 允许您实现轻量级消息传递并发另一方面，Erlang几乎迫使您使用单个库进行并发编程（该语言直接支持）。对于许多领域（例如电信应用）而言，这可能是一个不错的选择，但对于其他一些情况，它可能过于严格。
我并没有对Erlang说任何坏事 - 你当然可以使用它来编码许多其他更高级别的并发编程范例。我只是说将语言绑定到单个并发编程模型（并使用它来比较语言）通常是错误的方法。