F＃是功能语言的不好选择

对我而言，我认为F＃是一个不好的选择，因为它在幕后使用线程。对我而言，由于上下文切换等原因，线程太“沉重”了。F＃是功能语言的不好选择

我可以看到为什么Erlang是一个不错的选择，因为它使用轻量级的过程。

我错了吗？

来源

2010-05-21 dagda1

有效的问题，而是 - 更改为社区Wiki或将您的问题限制为线程实现。 – 2010-05-21 08:51:03

我认为如果你定义你正在寻找的品质而不是仅仅说“不好”，那么它就不那么主观 – 2010-05-21 08:51:50

过程比线程更昂贵。我没有看到你的观点。 – leppie 2010-05-21 08:59:30

我不明白你在问什么。

F＃不使用“幕后线程”，或者至少不超过任何.NET进程。实际上，F＃的async工具使得编写非消耗线程的非阻塞I/O程序（与具有更困难的无线/非阻塞编程模型的C＃/ VB相比）更容易。（当然，通常情况下，你不仅仅选择一个任意方面来比较两件事情，然后决定'X比Y好'。除了线程/过程模型之外，编程语言还有更多的不同。）

你喜欢看

http://blogs.msdn.com/dsyme/archive/2010/02/15/async-and-parallel-design-patterns-in-f-part-3-agents.aspx

最后三段是值得引用：

事实上，很少有超视距呃.NET或基于JVM的语言在.NET早期支持轻量级活动代理 - 由于线程的成本，因此它被称为 “不可能”。在这种情况下，F＃的整合在2007年 ‘异步{...}’可以作为仍觉突破出现在应用语言设计 - 它允许轻巧，成分异步编程和上下文活性剂一个工业接受和可互操作的编程平台。随着阿克苏姆语言原型（这已经在F＃有影响力的），F＃已经证明，一个异步语言的特点是通过对僵局的可行方法，以破“我们使线程轻量级与否”是目前bedevils的工业运行时间系统设计为。

F＃异步编程可以被看作是一个实施复会，并有很多前兆这里，例如OCaml的分隔的延续，一元并发哈斯克尔的嵌入和论文强调对于复会的重要性并发。

您可以在Linux/Mono/Mac 和Silverlight上使用 .NET 2.0,3.5,4.0上的F＃异步代理。事实上，即使使用F＃异步编程，您也可以使用将F＃转换为使用 WebSharper平台的Javascript。请享用！

来源

2010-05-21 08:56:30 Brian

自2006年以来，erlang拥有SMP，因此它也使用了幕后的线程。Erlang中的进程或AF＃中的异步任务都不对应于OS线程;两个运行时在需要时都使用线程，并在适当的地方使用较轻的机制。

来源

2010-05-21 09:01:36

为什么要投票？过程/任务是否使用线程实现并不重要 - 实现的质量或语言的表达性将成为区分它们的更好理由。 – 2010-05-21 09:11:49

如果你想获得一些有用的反馈，你应该指定你感兴趣的场景。然而，函数式编程是不是线程或进程 - 它更多的是表达的算法，并使用不同的编程模式，所以使用线程/进程是比较功能语言的一个非常奇怪的标准。

最重要的是，F＃并行编程只是一个图书馆的问题，并有很多选择：

F＃async布赖恩提到允许您实现轻量的消息传递并发
PLINQ允许您编写声明式数据并行计算
任务为您提供了一个细粒度的基元，用于执行al在小任务ARGE数量平行
线程（很少使用）给你完全控制了接近操作系统级

在另一方面，二郎几乎迫使你使用一个单一的库用于并发编程（这是由语言直接支持的）。对于许多领域（如电信应用）来说，这可能是一个不错的选择，但对其他一些情况来说，这可能太严格了。我并不是说Erlang有什么不好的地方 - 你当然也可以用它编码许多其他更高级别的并发编程范例。我只是说，将语言绑定到单个并发编程模型（并使用它来比较语言）通常是错误的方法。

来源

2010-05-21 11:39:48

F＃是功能语言的不好选择

回答

相关问题