我想尝试在 F# 中开发 ASP.NET 和 ASP.NET MVC 应用程序。我喜欢使用函数式语言，在我看来，函数式范式比命令式编程更适合 HTTP 和 Web（当然 F# 可以同时做到这两点）。
我只是打算在一些个人项目中尝试使用 F#，但我希望最终 F# 将被视为 C# 的有效替代品，适用于合适的商业 ASP.NET 项目。
目前在 ASP.NET 中使用 F# 有哪些陷阱和粗糙的边缘？一个明显的缺点是 F# 比 C# 更晦涩难懂，因此 F# 的代码示例和经验丰富的程序员较少。
我还应该注意哪些其他潜在问题？
【问题讨论】：
标签： asp.net asp.net-mvc f#
就我个人而言，我是 F# 的忠实粉丝。我的 NDjango 解析器/渲染引擎是用 F# 编写的。
但是尝试在 F# 中做所有事情可能很困难。要添加到您的列表中还没有的东西：
不支持可视化 设计师 - 既不是网络表单也不是 表格。你可以写 当然，手动适当的代码
没有代码完成
在 F# 中调试可能是一项挑战，尤其是因为匿名闭包
由于类型推断，编译器诊断可能会产生误导 - 一个错字可能会在遥远的地方产生深远的影响
我最大的烦恼是“文件顺序问题”规则。您必须指定文件的编译顺序
这绝不是一个完整的列表。另一方面，人们可能希望在最终版本中解决其中的一些问题。
尽管有所有列出的（和未列出的）问题，但我喜欢使用 F# 进行编程 - 有时它为编码提供了令人耳目一新的视角，而且我已经开始在我的 C# 代码中使用受 F# 启发的一些技巧。
只是不要在里面发疯
【讨论】：
这是家庭项目还是工作项目？如果是为了工作，您需要考虑其他人介入和维护您的代码的能力 - 与有能力的 C# 人员相比，F# 开发人员并不多。
【讨论】：
mmmmm f#，另一个敢说名字的白肉。去吧，F#，正如凯先生所说的“它的未来！”。至于陷阱......噗！，什么陷阱，你只是创造了没有chuff和Objects的东西。
C# 很棒，它也有它的位置。但正如您正确指出的那样，它不适合网络编程。在这件事上，ASP.net 提供的事件也没有冒烟和镜像。
往下走。想想 HttpHandlers 和 REST。你不需要 MVC 的东西。它和想法，而不是产品。
前端 GUI 与后端无关。你真的需要 ASP.net 吗？ JSON/REST/POX ......在考虑这些的情况下开发你的中间层，你应该没问题。远离 WCF 的得体和下流。
关于可维护代码的注释。小道大火。为什么成为你不想成为的人。如果他们的想法不像你，那么你希望他们在身边吗？
当我从事项目时，想法驱动产品而不是技术，当然也不是大众或暴民。大型组织只为一个原因迎合暴民，这与推动艺术和欧元无关。
消息和管道是我在当前环境下会使用的。当环境支持时，事件是很棒的，但是网络的异步特性是否有助于考虑一个带有时钟滴答的处理管道并检查事情是否已经完成。
.Net 对一件事有好处。带有数据库和逻辑的中间层。至于前面。用别的东西。更多韦比。
为什么只是 F# 带来了一流的整个射击比赛。从 php、python、ruby、clojure、haskell 等中选择很多......
F# 不仅仅是它本身，而是它所代表的东西，它是在多核多线程、多进程的新时代和绝望时代的一种旧思维方式。
作为我曾经听过的一首歌说“我不在乎他们的不同想法 不同的想法对我有好处”
【讨论】：