Given that the basic syntax and semantics of a language like F# are already designed to provide exactly what LINQ provides to C#/VB as an add one, why should I be using LINQ when programming in F#? What do I gain, and what might I lose?
Share
Sign Up to our social questions and Answers Engine to ask questions, answer people’s questions, and connect with other people.
Login to our social questions & Answers Engine to ask questions answer people’s questions & connect with other people.
Lost your password? Please enter your email address. You will receive a link and will create a new password via email.
Please briefly explain why you feel this question should be reported.
Please briefly explain why you feel this answer should be reported.
Please briefly explain why you feel this user should be reported.
Given that the basic syntax and semantics of a language like F# are already designed to provide exactly what LINQ provides to C#/VB as an add one, why should I be using LINQ when programming in F#? What do I gain, and what might I lose?
LINQ, from a language perspective (C#’s special from… syntax) is mostly unnecessary since F# is able to represent LINQ-like data transformations very succinctly already. I suspect that much of the remaining purpose of the C# sugar is to reorganize the code so C# can type LINQ queries without forcing the user to provide type annotations or perform eta-expansion manually. This, too, is unnecessary in F#.
As for using the System.Linq namespace in F#, I don’t recommend it. F# type inference becomes extra stupid around member access. I suspect that using System.Linq would require more explicit type annotations than using the corresponding F# library. Even in cases where type inference succeeds, uncurried CLR-style API generally feels heavy and out-of-place in F# compared to the native libraries.