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