根据您的实际经验、白皮书或其他受人尊敬的可参考研究，F# 目前是否是企业级/企业级报告的可行工具？
注意：在投票以“非建设性”结束此问题之前，请阅读底部的内容。
背景
我目前在一家大型公司工作，该公司大量使用许多不同的报告工具，包括（但不限于）SAS、Cognos、SSRS，甚至还有少量的 COBOL。每个工具都有其应有的地位，其中许多工具在大多数方面在功能集等方面是等效的。我们的大多数工具都能够相对轻松地输出到 PDF、Excel 和数据库，并且在这些情况下工作得非常好。
不幸的是，我的组织和许多人一样，使用 Excel 电子表格，无论喜欢还是讨厌它，我们都花了很多时间编写 .NET 控制台应用程序，以便从 Excel 电子表格中提取信息并将信息插入到 Excel 电子表格中。（我对争论这种方法的优点或缺点不感兴趣。它就是这样，我无法改变它。）
与上面列出的报告技术一样出色，但当涉及到电子表格的高级 ETL 时，它们却是平淡无奇。它们只是不是为此而设计的，虽然它们非常擅长将报告格式化为 Excel 电子表格，但它们并不擅长更新现有电子表格或以某种非常特定的方式提取数据（仅提取以红色突出显示的值，例如）。因此，我们最终编写了大量 .NET 控制台应用程序来完成这一点。（再一次 - 对辩论这种方法不感兴趣。它就是这样。我知道 - 我也不喜欢它。）
在我看来，.NET 是一个出色的框架，并且足够灵活，可以处理几乎所有的编程任务，因此理论上我们可以处理 .NET 中的所有报告。但是 - 尝试处理 .NET 中的所有报告需要很长时间。我们必须自己编写所有样板文件。我喜欢利用我们已经拥有的实际报告工具的强大功能、简单性和稳健性。
因此，我们最终为单个任务编写了两个应用程序 - 例如，一个 SAS 作业从多个数据源加载数据，进行转换并将结果存储在永久或临时位置，以及另一个 .NET 作业执行结果并将它们加载到电子表格中。（我知道。）
在过去的几年里我看到和听到了很多关于 F# 的观点，我自己也涉足了一点。我在大学学习了 OCAML，我喜欢函数式编程。当需要时，我很乐意在单一平台（如果不是单一语言）上完成特定报告的所有编程。不过，问题是 F# 语言和 .NET 框架是否已为企业级报告做好充分准备——我说的是必须准确有效地运行的报告。微软肯定在卖力，但我想知道是否有人在其他报告技术方面有经验，是否真的在生产环境中尝试过。它与其他报告技术相比如何？能否轻松集成到企业环境中？你是如何解决安全问题的？做得对，F# 需要什么样的内存配置文件（我们说的是数百万条记录）？它能很好地处理表格数据吗？它有效率吗？维护起来有多容易（尤其是在代码增长的情况下）？需要什么样的第三方附加组件、插件等才能使某些东西正常工作（或者它可以开箱即用地完成大部分工作）？与其他报告系统（类似结果）相比，需要多少工作（编程时间等）？
如果您没有使用 F# 的经验，或者如果您只使用 F#，那么我对您的意见并不特别感兴趣 - 我想听听那些实际上已经弥合了差距并且可以从经验中联系到机会和将 F# 用作大数据（数百万条记录，输出为各种格式）的报告引擎的缺陷。
我已经看到了一些已经涵盖了其中一些领域的问题：
但他们已经几岁了。之后的几个版本，F# 能胜任吗？还是我是一只在错误的树上吠叫的狗？
编辑
只是为了清楚起见，我对 F# 的新的信息丰富的编程特别感兴趣。在 F# 3.0 之前，它只是一项有趣的技术，但 F#最近添加的使用数据库类型提供程序及其查询表达式的功能使其看起来像是其他报表创作技术的可行替代方案。微软当然暗示它是。
一个可接受的答案将包含实施 F# 中内置的企业级报告引擎的第一手资料（或对文档案例研究的参考），以及与其他报告技术的任何性能增益或损失等的比较。它没有不必太详细 - 足以让普通（称职的）经理相信 F# 是适合/不适合批量/批量数据处理的技术。已经完成了吗？谁干的？结果如何？实现有多复杂（相对于类似技术）？它表现良好吗？
为什么我要问一个主观的问题？
像大多数优秀的 stackoverflow 成员一样，我经常投票关闭主观问题。根据常见问题解答，应该避免主观问题，但不能完全禁止。常见问题解答链接到我试图遵循的关于重大主观问题的六个指南。请在投票结束此问题之前阅读这些指南。