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