I work for a tech company that does more prototyping than product shipment. I just got asked what's the difference between C# and F#, why did MS create F# and what scenarios would it be better than C#.
我在一家技术公司工作，这家公司做的样机比产品发货多。我刚被问到c#和f#的区别是什么，为什么MS创建f#，它会比c#更好。
I've been using the language for a while now and I love it so I could easily go on about the great features of F# however I lack the experience in C# to say why we should use one over the other.
我已经使用这门语言有一段时间了，我喜欢它，所以我可以很容易地继续讨论f#的伟大特性，但是我缺乏c#的经验来说明为什么我们应该使用它。
What's the benefits of using C# vs F# or F# vs C#?
使用c# vs f#或f# vs c#有什么好处?
8 个解决方案
#1
86
General benefits of functional programming over imperative languages:
函数式编程比命令式编程的一般好处:
You can formulate many problems much easier, closer to their definition and more concise in a functional programming language like F# and your code is less error-prone (immutability, more powerful type system, intuitive recurive algorithms). You can code what you mean instead of what the computer wants you to say ;-) You will find many discussions like this when you google it or even search for it at SO.
您可以更容易地表达许多问题，更接近它们的定义，更简洁地使用f#这样的函数式编程语言，并且您的代码更不容易出错(不变性、更强大的类型系统、直观的重新排序算法)。你可以把你的意思写出来，而不是电脑想要你说什么;-)你会发现很多这样的讨论，当你谷歌，甚至搜索它的时候。
Special F#-advantages:
特殊的f#的优势:
-
Asynchronous programming is extremely easy and intuitive with
async {}-expressions - Even with ParallelFX, the corresponding C#-code is much bigger异步编程对于异步{}表达式是非常简单和直观的——即使是使用ParallelFX，相应的c#代码也要大得多
-
Very easy integration of compiler compilers and domain-specific languages
非常容易集成编译器编译器和特定领域的语言。
-
Extending the language as you need it: LOP
根据需要扩展语言:LOP
-
的计量单位
-
More flexible syntax
更灵活的语法
-
Often shorter and more elegant solutions
通常更短更优雅的解决方案
Take a look at this document
看看这个文件
The advantages of C# are that it's often more accurate to "imperative"-applications (User-interface, imperative algorithms) than a functional programming language, that the .NET-Framework it uses is designed imperatively and that it's more widespread.
c#的优点是，“命令式”应用程序(用户界面、命令式算法)通常比函数式编程语言更准确，它使用的. net框架是按需求设计的，而且更广泛。
Furthermore you can have F# and C# together in one solution, so you can combine the benefits of both languages and use them where they're needed.
此外，您可以将f#和c#一起放在一个解决方案中，这样您就可以将两种语言的优点结合起来，并在需要的地方使用它们。
#2
36
It's like asking what's the benefit of a hammer over a screwdriver. At an extremely high level, both do essentially the same thing, but at the implementation level it's important to select the optimal tool for what you're trying to accomplish. There are tasks that are difficult and time-consuming in c# but easy in f# - like trying to pound a nail with a screwdriver. You can do it, for sure - it's just not ideal.
这就像是在问锤子的好处是什么。在一个非常高的级别上，两者本质上做的都是相同的事情，但是在实现级别上，为您要实现的目标选择最优工具是很重要的。有些任务在c#中既困难又耗时，但在f#中却很简单——比如用螺丝刀敲钉子。你可以做到，当然——这并不理想。
Data manipulation is one example I can personally point to where f# really shines and c# can potentially be unwieldy. On the flip side, I'd say (generally speaking) complex stateful UI is easier in OO (c#) than functional (f#). (There would probably be some people who disagree with this since it's "cool" right now to "prove" how easy it is to do anything in F#, but I stand by it). There are countless others.
数据操作是我个人可以指出f#真正的亮点和c#可能难以处理的一个例子。另一方面，我认为(一般来说)复杂的有状态UI在OO (c#)中比函数(f#)更容易。(可能有些人不同意这个观点，因为现在“证明”在f#中做任何事情是多么容易，但我支持它)。有无数的人。
#3
27
- F# Has Better Performance than C# in Math
- f#在数学上比c#有更好的表现
- You could use F# projects in the same solution with C# (and call from one to another)
- 您可以使用c#在同一个解决方案中使用f#项目(并从一个到另一个调用)
- F# is really good for complex algorithmic programming, financial and scientific applications
- f#非常适合复杂的算法编程、金融和科学应用
- F# logically is really good for the parallel execution (it is easier to make F# code execute on parallel cores, than C#)
- f#逻辑上对并行执行非常好(在并行内核上执行f#代码更容易，而不是c#)
#4
27
To answer your question as I understand it: Why use C#? (You say you're already sold on F#.)
按照我的理解来回答你的问题:为什么要使用c# ?(你说你已经被f#说服了。)
First off. It's not just "functional versus OO". It's "Functional+OO versus OO". C#'s functional features are pretty rudimentary. F#'s are not. Meanwhile, F# does almost all of C#'s OO features. For the most part, F# ends up as a superset of C#'s functionality.
首先，它不只是“功能性vs . OO”。这是“功能+面向对象与面向对象”。c#的功能特性非常基本。f#的不是。同时，f#几乎完成了c#的所有OO特性。在大多数情况下，f#最终成为c#功能的超集。
However, there are a few cases where F# might not be the best choice:
然而，有些情况下f#可能不是最好的选择:
-
Interop. There are plenty of libraries that just aren't going to be too comfortable from F#. Maybe they exploit certain C# OO things that F# doesn't do the same, or perhaps they rely on internals of the C# compiler. For example, Expression. While you can easily turn an F# quotation into an Expression, the result is not always exactly what C# would create. Certain libraries have a problem with this.
交互操作。有很多库对f#不太满意。也许他们利用了f#不做相同的某些c# OO，或者他们可能依赖于c#编译器的内部。例如,表达式。虽然可以很容易地将f#引语转换为表达式，但结果并不总是c#将创建什么。某些库对此有问题。
-
Yes, interop is a pretty big net and can result in a bit of friction with some libraries.
是的，interop是一个很大的网络，可能会与一些库产生一些摩擦。
-
I consider interop to also include if you have a large existing codebase. It might not make sense to just start writing parts in F#.
我认为interop还包括如果您有一个很大的现有代码基。用f#开始写部分可能没有意义。
-
-
Design tools. F# doesn't have any. Does not mean it couldn't have any, but just right now you can't whip up a WinForms app with F# codebehind. Even where it is supported, like in ASPX pages, you don't currently get IntelliSense. So, you need to carefully consider where your boundaries will be for generated code. On a really tiny project that almost exclusively uses the various designers, it might not be worth it to use F# for the "glue" or logic. On larger projects, this might become less of an issue.
设计工具。f#没有。这并不意味着它不可能有任何代码，但是现在你不能用f#代码来创建WinForms应用。即使在支持它的地方，比如在ASPX页面中，你也无法获得智能感知。因此，您需要仔细考虑您的边界将在哪里生成代码。在一个几乎只使用各种设计人员的非常小的项目中，使用f#作为“胶水”或逻辑可能不值得。在大型项目中，这可能不再是问题。
-
This isn't an intrinsic problem. Unlike the Rex M's answer, I don't see anything intrinsic about C# or F# that make them better to do a UI with lots of mutable fields. Maybe he was referring to the extra overhead of having to write "mutable" and using <- instead of =.
这不是一个内在的问题。与Rex M的答案不同，我不认为c#或f#有什么内在的东西可以让它们更好地处理一个包含大量可变字段的UI。也许他指的是必须写“mutablecopy”和使用<-而不是=的额外开销。
-
Also depends on the library/designer used. We love using ASP.NET MVC with F# for all the controllers, then a C# web project to get the ASPX designers. We mix the actual ASPX "code inline" between C# and F#, depending on what we need on that page. (IntelliSense versus F# types.)
还取决于使用的库/设计器。我们喜欢使用ASP。对于所有的控制器，使用f#的NET MVC，然后使用c# web项目获得ASPX设计器。我们将实际的ASPX“代码内联”混合在c#和f#之间，这取决于我们在该页上需要什么。(智能感知和f#类型。)
-
-
Other tools. They might just be expecting C# only and not know how to deal with F# projects or compiled code. Also, F#'s libraries don't ship as part of .NET, so you have a bit extra to ship around.
其他工具。他们可能只是期望c#，而不知道如何处理f#项目或编译代码。另外，f#的库不会作为。net的一部分发布，所以您可以发布一些额外的内容。
-
But the number one issue? People. If none of your developers want to learn F#, or worse, have severe difficulty comprehending certain aspects, then you're probably toast. (Although, I'd argue you're toast anyways in that case.) Oh, and if management says no, that might be an issue.
但首要问题是什么呢?人。如果您的开发人员中没有人想学习f#，或者更糟糕的是，他们很难理解某些方面，那么您很可能会很不满意。(不过，在这种情况下，我认为你应该干杯。)哦，如果管理层说不，那可能是个问题。
I wrote about this a while ago: Why NOT F#?
我之前写过这个问题:为什么不是f# ?
#5
6
You're asking for a comparison between a procedural language and a functional language so I feel your question can be answered here: What is the difference between procedural programming and functional programming?
您要求对过程性语言和函数性语言进行比较，因此我认为您的问题可以在这里回答:过程性编程和函数性编程有什么区别?
As to why MS created F# the answer is simply: Creating a functional language with access to the .Net library simply expanded their market base. And seeing how the syntax is nearly identical to OCaml, it really didn't require much effort on their part.
至于MS创建f#的原因，答案很简单:创建一种能够访问。net库的函数式语言只是扩展了他们的市场基础。看到它的语法和OCaml几乎是一样的，他们真的不需要花太多功夫。
#6
5
F# is not yet-another-programming-language if you are comparing it to C#, C++, VB. C#, C, VB are all imperative or procedural programming languages. F# is a functional programming language.
如果您将f#与c#、c++、VB进行比较，那么它还不是另一种编程语言。c#、C、VB都是命令式或过程式编程语言。f#是一种函数式编程语言。
Two main benefits of functional programming languages (compared to imperative languages) are 1. that they don't have side-effects. This makes mathematical reasoning about properties of your program a lot easier. 2. that functions are first class citizens. You can pass functions as parameters to another functions just as easily as you can other values.
函数式编程语言的两个主要优点(与命令式语言相比)是1。它们没有副作用。这使得对程序属性的数学推理更加容易。2。这些功能都是一流的公民。您可以像传递其他值一样，将函数作为参数传递给其他函数。
Both imperative and functional programming languages have their uses. Although I have not done any serious work in F# yet, we are currently implementing a scheduling component in one of our products based on C# and are going to do an experiment by coding the same scheduler in F# as well to see if the correctness of the implementation can be validated more easily than with the C# equivalent.
命令式编程语言和函数式编程语言都有各自的用途。虽然我还没有做任何f#严肃的工作,我们正在实施一个调度组件在一个我们的产品基于c#和要做的一个实验在f#通过编码相同的调度程序,看看实现的正确性可以比与c#当量更容易进行验证。
#7
5
F# is essentially the C++ of functional programming languages. They kept almost everything from Objective Caml, including the really stupid parts, and threw it on top of the .NET runtime in such a way that it brings in all the bad things from .NET as well.
f#本质上是函数式编程语言的c++。他们保留了几乎所有来自Objective Caml的东西，包括真正愚蠢的部分，并把它放在。net运行时之上，这样就可以从。net中引入所有不好的东西。
For example, with Objective Caml you get one type of null, the option<T>. With F# you get three types of null, option<T>, Nullable<T>, and reference nulls. This means if you have an option you need to first check to see if it is "None", then you need to check if it is "Some(null)".
例如，对于Objective Caml，您将得到一种类型的null，选项
F# is like the old Java clone J#, just a bastardized language just to attract attention. Some people will love it, a few of those will even use it, but in the end it is still a 20-year-old language tacked onto the CLR.
f#就像旧的Java克隆版J#，只是一种低级的语言，只是为了吸引人们的注意。有些人会喜欢它，有些人甚至会使用它，但最终它仍然是一个附加在CLR上的20年语言。
#8
5
One of the aspects of .NET I like the most are generics. Even if you write procedural code in F#, you will still benefit from type inference. It makes writing generic code easy.
我最喜欢。net的一个方面是泛型。即使您使用f#编写过程代码，您仍然可以从类型推断中获益。它使编写通用代码变得容易。
In C#, you write concrete code by default, and you have to put in some extra work to write generic code.
在c#中，默认情况下，您编写的是具体的代码，并且您必须添加一些额外的工作来编写通用代码。
In F#, you write generic code by default. After spending over a year of programming in both F# and C#, I find that library code I write in F# is both more concise and more generic than the code I write in C#, and is therefore also more reusable. I miss many opportunities to write generic code in C#, probably because I'm blinded by the mandatory type annotations.
在f#中，您默认编写通用代码。在使用f#和c#进行了一年多的编程之后，我发现我在f#中编写的库代码比我在c#中编写的代码更简洁、更通用，因此也更具有可重用性。我错过了许多用c#编写通用代码的机会，可能是因为我被强制性的类型注释蒙蔽了双眼。
There are however situations where using C# is preferable, depending on one's taste and programming style.
然而，在某些情况下，使用c#更好，这取决于个人的喜好和编程风格。
- C# does not impose an order of declaration among types, and it's not sensitive to the order in which files are compiled.
- c#不会在类型之间强加声明的顺序，而且它对文件被编译的顺序也不敏感。
- C# has some implicit conversions that F# cannot afford because of type inference.
- 由于类型推断，c#有一些f#无法承担的隐式转换。
#1
86
General benefits of functional programming over imperative languages:
函数式编程比命令式编程的一般好处:
You can formulate many problems much easier, closer to their definition and more concise in a functional programming language like F# and your code is less error-prone (immutability, more powerful type system, intuitive recurive algorithms). You can code what you mean instead of what the computer wants you to say ;-) You will find many discussions like this when you google it or even search for it at SO.
您可以更容易地表达许多问题，更接近它们的定义，更简洁地使用f#这样的函数式编程语言，并且您的代码更不容易出错(不变性、更强大的类型系统、直观的重新排序算法)。你可以把你的意思写出来，而不是电脑想要你说什么;-)你会发现很多这样的讨论，当你谷歌，甚至搜索它的时候。
Special F#-advantages:
特殊的f#的优势:
-
Asynchronous programming is extremely easy and intuitive with
async {}-expressions - Even with ParallelFX, the corresponding C#-code is much bigger异步编程对于异步{}表达式是非常简单和直观的——即使是使用ParallelFX，相应的c#代码也要大得多
-
Very easy integration of compiler compilers and domain-specific languages
非常容易集成编译器编译器和特定领域的语言。
-
Extending the language as you need it: LOP
根据需要扩展语言:LOP
-
的计量单位
-
More flexible syntax
更灵活的语法
-
Often shorter and more elegant solutions
通常更短更优雅的解决方案
Take a look at this document
看看这个文件
The advantages of C# are that it's often more accurate to "imperative"-applications (User-interface, imperative algorithms) than a functional programming language, that the .NET-Framework it uses is designed imperatively and that it's more widespread.
c#的优点是，“命令式”应用程序(用户界面、命令式算法)通常比函数式编程语言更准确，它使用的. net框架是按需求设计的，而且更广泛。
Furthermore you can have F# and C# together in one solution, so you can combine the benefits of both languages and use them where they're needed.
此外，您可以将f#和c#一起放在一个解决方案中，这样您就可以将两种语言的优点结合起来，并在需要的地方使用它们。
#2
36
It's like asking what's the benefit of a hammer over a screwdriver. At an extremely high level, both do essentially the same thing, but at the implementation level it's important to select the optimal tool for what you're trying to accomplish. There are tasks that are difficult and time-consuming in c# but easy in f# - like trying to pound a nail with a screwdriver. You can do it, for sure - it's just not ideal.
这就像是在问锤子的好处是什么。在一个非常高的级别上，两者本质上做的都是相同的事情，但是在实现级别上，为您要实现的目标选择最优工具是很重要的。有些任务在c#中既困难又耗时，但在f#中却很简单——比如用螺丝刀敲钉子。你可以做到，当然——这并不理想。
Data manipulation is one example I can personally point to where f# really shines and c# can potentially be unwieldy. On the flip side, I'd say (generally speaking) complex stateful UI is easier in OO (c#) than functional (f#). (There would probably be some people who disagree with this since it's "cool" right now to "prove" how easy it is to do anything in F#, but I stand by it). There are countless others.
数据操作是我个人可以指出f#真正的亮点和c#可能难以处理的一个例子。另一方面，我认为(一般来说)复杂的有状态UI在OO (c#)中比函数(f#)更容易。(可能有些人不同意这个观点，因为现在“证明”在f#中做任何事情是多么容易，但我支持它)。有无数的人。
#3
27
- F# Has Better Performance than C# in Math
- f#在数学上比c#有更好的表现
- You could use F# projects in the same solution with C# (and call from one to another)
- 您可以使用c#在同一个解决方案中使用f#项目(并从一个到另一个调用)
- F# is really good for complex algorithmic programming, financial and scientific applications
- f#非常适合复杂的算法编程、金融和科学应用
- F# logically is really good for the parallel execution (it is easier to make F# code execute on parallel cores, than C#)
- f#逻辑上对并行执行非常好(在并行内核上执行f#代码更容易，而不是c#)
#4
27
To answer your question as I understand it: Why use C#? (You say you're already sold on F#.)
按照我的理解来回答你的问题:为什么要使用c# ?(你说你已经被f#说服了。)
First off. It's not just "functional versus OO". It's "Functional+OO versus OO". C#'s functional features are pretty rudimentary. F#'s are not. Meanwhile, F# does almost all of C#'s OO features. For the most part, F# ends up as a superset of C#'s functionality.
首先，它不只是“功能性vs . OO”。这是“功能+面向对象与面向对象”。c#的功能特性非常基本。f#的不是。同时，f#几乎完成了c#的所有OO特性。在大多数情况下，f#最终成为c#功能的超集。
However, there are a few cases where F# might not be the best choice:
然而，有些情况下f#可能不是最好的选择:
-
Interop. There are plenty of libraries that just aren't going to be too comfortable from F#. Maybe they exploit certain C# OO things that F# doesn't do the same, or perhaps they rely on internals of the C# compiler. For example, Expression. While you can easily turn an F# quotation into an Expression, the result is not always exactly what C# would create. Certain libraries have a problem with this.
交互操作。有很多库对f#不太满意。也许他们利用了f#不做相同的某些c# OO，或者他们可能依赖于c#编译器的内部。例如,表达式。虽然可以很容易地将f#引语转换为表达式，但结果并不总是c#将创建什么。某些库对此有问题。
-
Yes, interop is a pretty big net and can result in a bit of friction with some libraries.
是的，interop是一个很大的网络，可能会与一些库产生一些摩擦。
-
I consider interop to also include if you have a large existing codebase. It might not make sense to just start writing parts in F#.
我认为interop还包括如果您有一个很大的现有代码基。用f#开始写部分可能没有意义。
-
-
Design tools. F# doesn't have any. Does not mean it couldn't have any, but just right now you can't whip up a WinForms app with F# codebehind. Even where it is supported, like in ASPX pages, you don't currently get IntelliSense. So, you need to carefully consider where your boundaries will be for generated code. On a really tiny project that almost exclusively uses the various designers, it might not be worth it to use F# for the "glue" or logic. On larger projects, this might become less of an issue.
设计工具。f#没有。这并不意味着它不可能有任何代码，但是现在你不能用f#代码来创建WinForms应用。即使在支持它的地方，比如在ASPX页面中，你也无法获得智能感知。因此，您需要仔细考虑您的边界将在哪里生成代码。在一个几乎只使用各种设计人员的非常小的项目中，使用f#作为“胶水”或逻辑可能不值得。在大型项目中，这可能不再是问题。
-
This isn't an intrinsic problem. Unlike the Rex M's answer, I don't see anything intrinsic about C# or F# that make them better to do a UI with lots of mutable fields. Maybe he was referring to the extra overhead of having to write "mutable" and using <- instead of =.
这不是一个内在的问题。与Rex M的答案不同，我不认为c#或f#有什么内在的东西可以让它们更好地处理一个包含大量可变字段的UI。也许他指的是必须写“mutablecopy”和使用<-而不是=的额外开销。
-
Also depends on the library/designer used. We love using ASP.NET MVC with F# for all the controllers, then a C# web project to get the ASPX designers. We mix the actual ASPX "code inline" between C# and F#, depending on what we need on that page. (IntelliSense versus F# types.)
还取决于使用的库/设计器。我们喜欢使用ASP。对于所有的控制器，使用f#的NET MVC，然后使用c# web项目获得ASPX设计器。我们将实际的ASPX“代码内联”混合在c#和f#之间，这取决于我们在该页上需要什么。(智能感知和f#类型。)
-
-
Other tools. They might just be expecting C# only and not know how to deal with F# projects or compiled code. Also, F#'s libraries don't ship as part of .NET, so you have a bit extra to ship around.
其他工具。他们可能只是期望c#，而不知道如何处理f#项目或编译代码。另外，f#的库不会作为。net的一部分发布，所以您可以发布一些额外的内容。
-
But the number one issue? People. If none of your developers want to learn F#, or worse, have severe difficulty comprehending certain aspects, then you're probably toast. (Although, I'd argue you're toast anyways in that case.) Oh, and if management says no, that might be an issue.
但首要问题是什么呢?人。如果您的开发人员中没有人想学习f#，或者更糟糕的是，他们很难理解某些方面，那么您很可能会很不满意。(不过，在这种情况下，我认为你应该干杯。)哦，如果管理层说不，那可能是个问题。
I wrote about this a while ago: Why NOT F#?
我之前写过这个问题:为什么不是f# ?
#5
6
You're asking for a comparison between a procedural language and a functional language so I feel your question can be answered here: What is the difference between procedural programming and functional programming?
您要求对过程性语言和函数性语言进行比较，因此我认为您的问题可以在这里回答:过程性编程和函数性编程有什么区别?
As to why MS created F# the answer is simply: Creating a functional language with access to the .Net library simply expanded their market base. And seeing how the syntax is nearly identical to OCaml, it really didn't require much effort on their part.
至于MS创建f#的原因，答案很简单:创建一种能够访问。net库的函数式语言只是扩展了他们的市场基础。看到它的语法和OCaml几乎是一样的，他们真的不需要花太多功夫。
#6
5
F# is not yet-another-programming-language if you are comparing it to C#, C++, VB. C#, C, VB are all imperative or procedural programming languages. F# is a functional programming language.
如果您将f#与c#、c++、VB进行比较，那么它还不是另一种编程语言。c#、C、VB都是命令式或过程式编程语言。f#是一种函数式编程语言。
Two main benefits of functional programming languages (compared to imperative languages) are 1. that they don't have side-effects. This makes mathematical reasoning about properties of your program a lot easier. 2. that functions are first class citizens. You can pass functions as parameters to another functions just as easily as you can other values.
函数式编程语言的两个主要优点(与命令式语言相比)是1。它们没有副作用。这使得对程序属性的数学推理更加容易。2。这些功能都是一流的公民。您可以像传递其他值一样，将函数作为参数传递给其他函数。
Both imperative and functional programming languages have their uses. Although I have not done any serious work in F# yet, we are currently implementing a scheduling component in one of our products based on C# and are going to do an experiment by coding the same scheduler in F# as well to see if the correctness of the implementation can be validated more easily than with the C# equivalent.
命令式编程语言和函数式编程语言都有各自的用途。虽然我还没有做任何f#严肃的工作,我们正在实施一个调度组件在一个我们的产品基于c#和要做的一个实验在f#通过编码相同的调度程序,看看实现的正确性可以比与c#当量更容易进行验证。
#7
5
F# is essentially the C++ of functional programming languages. They kept almost everything from Objective Caml, including the really stupid parts, and threw it on top of the .NET runtime in such a way that it brings in all the bad things from .NET as well.
f#本质上是函数式编程语言的c++。他们保留了几乎所有来自Objective Caml的东西，包括真正愚蠢的部分，并把它放在。net运行时之上，这样就可以从。net中引入所有不好的东西。
For example, with Objective Caml you get one type of null, the option<T>. With F# you get three types of null, option<T>, Nullable<T>, and reference nulls. This means if you have an option you need to first check to see if it is "None", then you need to check if it is "Some(null)".
例如，对于Objective Caml，您将得到一种类型的null，选项
F# is like the old Java clone J#, just a bastardized language just to attract attention. Some people will love it, a few of those will even use it, but in the end it is still a 20-year-old language tacked onto the CLR.
f#就像旧的Java克隆版J#，只是一种低级的语言，只是为了吸引人们的注意。有些人会喜欢它，有些人甚至会使用它，但最终它仍然是一个附加在CLR上的20年语言。
#8
5
One of the aspects of .NET I like the most are generics. Even if you write procedural code in F#, you will still benefit from type inference. It makes writing generic code easy.
我最喜欢。net的一个方面是泛型。即使您使用f#编写过程代码，您仍然可以从类型推断中获益。它使编写通用代码变得容易。
In C#, you write concrete code by default, and you have to put in some extra work to write generic code.
在c#中，默认情况下，您编写的是具体的代码，并且您必须添加一些额外的工作来编写通用代码。
In F#, you write generic code by default. After spending over a year of programming in both F# and C#, I find that library code I write in F# is both more concise and more generic than the code I write in C#, and is therefore also more reusable. I miss many opportunities to write generic code in C#, probably because I'm blinded by the mandatory type annotations.
在f#中，您默认编写通用代码。在使用f#和c#进行了一年多的编程之后，我发现我在f#中编写的库代码比我在c#中编写的代码更简洁、更通用，因此也更具有可重用性。我错过了许多用c#编写通用代码的机会，可能是因为我被强制性的类型注释蒙蔽了双眼。
There are however situations where using C# is preferable, depending on one's taste and programming style.
然而，在某些情况下，使用c#更好，这取决于个人的喜好和编程风格。
- C# does not impose an order of declaration among types, and it's not sensitive to the order in which files are compiled.
- c#不会在类型之间强加声明的顺序，而且它对文件被编译的顺序也不敏感。
- C# has some implicit conversions that F# cannot afford because of type inference.
- 由于类型推断，c#有一些f#无法承担的隐式转换。