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＃是功能語言的不好選擇

回答

相關問題