这可能是其他人看到的一个问题，但我正在尝试找到一种为并发编程设计（或支持语言支持）的语言，该语言可以在 .net 平台上运行。
我一直在使用 erlang 进行辅助开发，以了解该语言，并且喜欢获得稳定的并发甚至分布式系统是多么容易。它把我带到了 scala，它也有一个很好的使用 actor 的系统，但是 scala.net 目前似乎没有这个功能（当然这是一个并发系统与分布式系统）。我正在研究的两种 .net 语言是 Axum 和 F#。
这些是我唯一的选择吗？还有其他人吗？而且，如果它们是唯一的选择，那么它们各自的优点/缺点是什么？
Axum 是一个研究项目。一个真正的研究项目，只有来自它的想法才会最终变成产品。（与整体产品化的 F# 不同。）我什至不确定许可证是否允许使用它来开发生产应用程序。
F# 是一个不错的选择。
Clojure 也可以在 CLI 上运行，也是一个不错的选择。
Scala 的 CLI 端口目前正在复活过程中（实际上是由微软提供的官方资助），Scala 的 Actor 库（包括内置库和 Akka）都非常好。
关于上面@wmeyer 的评论：Scala 本身没有任何分布式编程的规定。（Clojure 也没有。）两者通常都依赖于为此目的而存在的无数 Java 框架，例如 Terracotta。然而，Akka确实有用于分布式编程的远程 Actor，并且 Akka 在很大程度上与内置 Scala Actor 库的 API 兼容，可以实现平滑过渡。
Erlang 会很酷。Kresten Krab Thorup 目前正在研究 Erjang，这是 JVM 上的 Erlang 实现，他取得了一些令人印象深刻的成果：在 HotSpot 上运行，Erjang 的可扩展性与 BEAM 相当，有时甚至更好。例如，在具有 10000 个进程的（著名的）进程环基准测试中，Erjang 的启动速度仅比 BEAM 慢一点，但是当您重复运行几次并且 JIT 启动时，它会在大约 3 次运行后超过 BEAM（奇怪的是, BEAM 在 4 次运行后开始减速）。
我很确定您可以在 DLR 和 TPL 上构建一个同样出色的“#rlang”。
我现在实际上正在使用 F# 来进行并发和分布式编程。我认为它运作良好。联合类型使定义静态类型的消息变得容易。.NET 序列化对我们来说太慢了，但使用自定义解析器和反解析器组合器替换它很容易，而且性能现在已经足够好。异步工作流和邮箱处理器使轻松传递消息变得容易。类型推断意味着我的整个代码库很小且易于维护。
我认为 Jörg 已经回答了您关于 Axum 的问题（我对此了解不多），所以我将添加一些关于 F# 的内容 - 需要注意的一点是 F# 并不是真正的并发语言。它只是有很好的库来进行并行开发。最值得注意的选项是：
任务并行库和PLINQ在 C# 中也可用，但在 F# 中可能看起来更好一些，尤其是在您使用不可变数据类型时。在.NET 并行编程中有一些很好的 F# 示例使用这两个示例，我写了一篇关于 F# 版本的博客文章。
异步工作流本质上不是为并发编程而设计的——它们允许您编写一般的非阻塞代码（这在并发编程中非常有用）并且它们允许您编写可以启动和管理的计算。您可以将它们用于：
StartChild方法Async.ParallelMailboxProcessor允许您使用与 Erlang 非常相似的消息传递并发。它基于异步工作流，为您带来一些好处（例如，等待消息是非阻塞的）。总之，我认为为您的任务选择正确的并行编程模型比用于编码它的语言更重要——只要该语言为您提供足够的能力来编码编程模型。在这种情况下，编程模型比语言更能塑造你的思想。Axum基于参与者（消息传递）模型，因此我认为通过一些努力，您可以将 F# 代理包装成看起来与 Axum API 非常相似。
从 .NET 4.5 开始，您可以使用 C# async/await。我试图解释使用 async/await的线程安全、基于 actor 的设计。AsyncWcfLib旨在帮助创建并发或分布式系统。