针对F＃的情况如何？
简单的C＃/ Java代码非常难以并行化，multithreading等。因此，简单的C＃/ Java代码将在一个盒子上使用越来越少的总处理能力（因为现在所有东西都将是多核的） ）。
在C＃和Java中解决这个问题并不简单。 可变性和副作用是在C＃和Java中完成工作的关键，但这正是使多核，multithreading编程变得如此困难的原因。
因此，函数式编程将变得越来越重要。
鉴于J2EE / Ruby世界将在许多function/多核方法中分裂（就像它对其他所有方法一样），而.NET人员都将使用F＃，这种思路表明F＃将在两个方面很大年份。
这种思路有什么问题？ 为什么F＃不会很大？
（编辑）Larry O’Brien在这篇博客文章中指出：“语言方面，在我看来，这是一套C和C ++闪耀的练习 – 至少在multithreading的东西之前。列表处理习语的语言也会最初做得很好，但可能有内存消耗问题（特别是函数式语言）。最后，我认为托管C派生语言（Java和C＃）具有最简单的练习9路径，然后在练习10中面临严重缺陷，其中并发问题起主要作用。在我看来，并发性将成为未来五年专业发展的核心问题，因此这些缺点非常重要。
直接的C＃/ Java代码很难并行化
如果您使用任务并行库，则不会。
F＃是否变得巨大取决于成本/收益是否存在，这一点并不明显。 如果.NET开发人员发现他们可以在1/3的时间内使用function而不是命令式方法编写一些程序（我认为某些类型的程序可能也是如此），那么F＃采用应该有一些动机。
保罗格雷厄姆关于他在一家初创公司使用Lisp的故事说明了这一过程。 Lisp为他们提供了巨大的竞争优势，但Lisp没有接管世界，不是因为它不强大，而是出于其他原因，比如缺乏图书馆支持。 F＃可以访问.NET框架，这给了它一个战斗机会。
- 在SO上询问编程问题，并指明您正在使用F＃。
- 提出相同的问题并指明您使用的是C＃。
- 比较答案。
使用新颖的编程语言是一种计算风险 – 您可能会获得更多内置function和语法糖，但您将失去社区支持，雇用程序员的能力以及解决语言中的盲点问题。
我不是在选择F＃ – 编程语言的每个决定都是你需要解决的风险等式。 如果人们没有承担C＃的风险，我们现在仍然使用VB6和C ++。 这些语言与其前辈相同。 您必须为您的项目决定优势是否大于风险。
function编程比命令式编程更难以理解。 F＃在很多方面都比C＃更难。 大多数“开发人员”不了解函数式编程概念，甚至无法在C＃中编写非常好的命令式代码。 那么他们有什么希望在F＃中编写好的function代码？
当你认为团队中的每个人都需要能够理解，编写，调试，修复等等你选择的语言代码时，这意味着你需要一个非常强大的团队 – 而不仅仅是一个非常强大的人 -能够使用F＃，因为它意味着使用。 周围的人并不多。
加入混合的事实是，有8年的C＃/ VB代码不可能被迁移，并且在C＃/ VB中创建外观和感觉像BCL的库更容易，因为它不容易泄漏像通过公共接口，元组等等，我认为F＃很难获得比强大团队在新的内部项目中使用更多的东西。
对F＃没有任何理由，但你必须了解我们作为开发人员目前处境的情况。
多核架构仍处于起步阶段。 将单线程应用程序更改为parrellel体系结构的主要驱动力需要时间。
由于多种原因，F＃非常有用，并行性是其中之一，但不是唯一的原因。 function编程对于科学目的也非常有用。 这在许多领域都将是巨大的。
然而，你的问题的方式听起来像是你规定F＃已经在打一场失败的战斗，但绝对不是这样。 到目前为止，我和许多科学家谈过使用MatLab之类的东西，而且他们中的很多人已经意识到了F＃，并对此感到兴奋。
我不同意C＃很难并行化的前提。 如果你知道你在做什么，那真的不是。 此外，并行linq将使这更容易。 我希望有一个用于C＃的OpenMP吗？ 当然，但是C＃提供的工具允许你做几乎你想要的一切，如果你足够好（我觉得你甚至不再那么好了）。
- 命令代码比function代码更容易编写。 （至少，它更容易找到能够正确接受命令式代码与function代码的人）
- 有些东西本质上是单线程的（UI *是最着名的例子）。
- 已经有很多C＃/ C / C ++代码，同一个项目中的多种语言使得对该项目的管理更加困难。
就个人而言，我认为函数式语言将变得越来越主流（哎呀F＃本身certificate了这一点），但可能永远不会像C / C ++ / Java / C＃等那样获得通用语言 。 已经或将要。
*这显然是一个有点争议的观点，所以我将扩展它。
在multithreadingUI中，每个UI事件都是异步调度并且在自己的线程上调度（线程的实际管理可能比仅仅创建新线程更复杂，但这与讨论没有密切关系）。
想象一下，如果是这种情况，那么你正在渲染窗口。
- 窗口管理器会要求您绘制每个元素（期望消息或每个元素的函数调用）。
- 每个元素读取其状态（隐式读取应用程序状态）
- 每个元素都吸引自己。
在步骤2中，每个元素必须锁定应用程序状态（或影响显示的子集）。 否则，在更新应用程序状态的情况下，呈现窗口的最终结果可以包括反映两个不同应用程序状态的元素。
这是一个锁定车队。 每个渲染线程都将锁定，渲染，然后释放; 因此他们会连续执行。
现在，假设您正在处理用户输入。 首先，用户非常慢，所以除非你在（一个多个）UI线程上做大量工作，否则好处将不存在; 所以我假设是这样的。
- 窗口管理器通知您的应用程序用户输入（再次，消息，函数调用，等等）。
- 从应用程序状态中读取所需内容。 （这里需要锁）
- 花一些时间来处理一些数字。
- 更新应用程序状态。 （这里也需要锁）
你所完成的只是从显式启动一个工作线程转变为隐含地这样做; 如果你松开锁定你的状态，可能会以潜在的heisenbugs和僵局为代价。
UI api的根本问题在于你正在处理多对一（或一对多，取决于你如何看待它）的关系。 许多窗口，许多元素或许多“输入类型”都会影响单个窗口/表面。 必须进行某种同步，并且当它进行multithreading时，不再有任何好处只是简单。
这种思路有什么问题？ 为什么F＃不会很大？
你假设大群实际上编写需要多核支持的程序 – 或者程序将从并行化中获得显着的好处。 这是一个错误的假设。
服务器端甚至不需要并行语言。 后端服务器处理已经充分利用了多核/处理器支持，因为它具有并发的固有特性（工作在客户端通过线程和进程之间进行划分（例如，一个应用服务器，一个数据库服务器，一个Web容器……）。
这种推理的错误在于它假设一切都按计划进行。
假设在F＃中编写multithreading程序比在C＃编写multithreading程序更容易。 从历史上看，函数式语言并没有那么受欢迎，并且可能有其原因。 因此，虽然通常比命令式语言更容易实现multithreadingfunction，但通常更容易找到人们用命令式语言编程。 这两件事情以某种方式平衡，可能取决于人和应用程序。 一般来说，在函数式或命令式语言中编写multithreading应用程序可能会或可能不会更容易。 现在说还为时过早。
有人假设人们要求有效使用他们的1K核心计算机。 总有一些应用程序可以占用尽可能多的CPU功率，但这些应用程序并不是最常见的应用程序。 人们运行的大多数应用程序现在都不受CPU功率的限制，但是由于本地I / O，网络和用户的延迟。 这可能会改变，但它不会很快改变。
此外，目前尚不清楚大规模多核处理器是未来的潮流。 它们的市场可能相当小，因此芯片制造商将生产更小的芯片而不是更强大的芯片，或者将资源投入到我们目前尚不清楚的其他事物上。
假设F＃将成为function语言的赢家。 作为VS 2010的function语言，它确实具有相当大的优势。 然而，比赛还没有真正开始，而且有足够的时间让事情发生。 可能会发现，F＃.NET并不是编写大规模并行PC的特别好的语言，而且还可能出现其他问题。 当64核处理器经常出现在便宜的笔记本电脑上时，微软和.NET可能不会那么重要。 （这样的变化并不是那么常见，但它们往往会让人感到意外。它们更有可能在概念变化时发生，并且大规模转向function语言也是合格的。）
假设F＃将继续成为主要的Microsoftfunction语言，那么Microsoft编程语言将继续占据主导地位，从大型多核处理器中获得最大性能将是重要的，所有技术论点都不会被业务所淹没惯性，并且在编写大规模multithreading应用程序时，F＃将比C＃和其他类似语言好得多，而且你是对的。 然而，这是一系列假设串联在一起并由合理的原因而不是僵化的逻辑联系在一起。
你似乎试图将未来作为明年技术问题的一系列推理延伸的组合来预测未来，这非常不可靠。
反对它的唯一“案例”（如果存在这样的事情）是大多数现代的专业开发人员使用不同的工具（以及不同的工具类型）。 F＃为游戏带来了一些独特的工具，我们这些拥抱它们的人会发现我们各自的专业人才对其他编程任务很有用 – 特别是那些涉及分析和操纵大数据集的任务。
我所看到的F＃让我感到惊讶。 每一个演示都让我笑嘻嘻，因为F＃让我觉得我从“ 美好时光”中记得的高级版本，当时function性编程更常见（可能更“老’而不是‘好’确定，但这样是怀旧之情） 。
关于技术，有一些值得注意的事情
- 最好的技术解决方案并不总是最受欢迎或最常用。 （而且我不知道F＃是否有用）我认为SQL是最常用的，最常被雇主要求编程语言，而且我的书中并不是一本很好，很酷，快速，友好，有趣的语言。 如果最好的技术解决方案总是“赢”，你如何解释qwerty键盘？ 如果您曾阅读过x86 / x64处理器的“设计”..;）
- 拥有864核心服务器的Azul专门使用Java，未来趋势是更大的服务器。
如果我们假设战斗在C＃和F＃之间，我不认为F＃会在2年内赢得C＃，原因如下：
-
C＃没有的F＃function并不是人们所缺少的function。 例如，我认为Seq.map，Seq.iter，Seq.fold和朋友都很棒，但我没有看到大多数开发人员从foreach切换到这些结构。
-
多核的性能优势与大多数现有程序无关，因为只有少数程序受cpu约束。 对于性能非常重要的程序（例如video游戏），C ++仍将占据主导地位，至少在未来的两年内仍然如此。 在C ++中使用线程并不难，假设可以避免副作用（即使在C ++中也可以决定）。 这不是谷歌正在做的事情吗？
为了让F＃变得非常大，我认为它必须成为教学中使用的主要语言之一，就像Java一样。 这实际上非常有可能，看看学术界如何喜欢function语言。 如果发生这种情况，我认为效果在5年之前不会显现出来。
-
将组件链接在一起并非易事。
-
F＃与.NET类型系统相关联，这比PHP更受限制。 在Strong Typing的土地上，Java可能就在那里。 对于那些不熟悉.NET类型的人来说，这使得入门门槛相当高。
-
单一分配代码很难写; 大多数算法使用典型的图灵机模型，该模型允许多次分配，单一分配代码并不能完全适合我们如何思考的良好模型。 至少，对于我们这些以图灵机代码为生的人来说。 对于那些在那里编写Lambda机器代码的人来说，也许是不同的……
-
F＃与微软有关，后者产生了来自许多极客的仇恨。 他们宁愿使用Lisp或Scheme或Haskell（或其他）。 虽然单声道支持它，但它上次我尝试使用单声道时它不支持它（它很慢）。
-
我们现有的大多数代码都存在于命令式的顺序代码库中，而我们的大多数应用程序都是针对具有副作用的命令式顺序操作。
可以这么说，纯粹的function方法并不能很好地模拟现实世界，因此F＃必须开辟一个能够轻松管理现实世界问题的利基市场。 它不能成为通用语言，因为它不能巧妙地解决通用问题。