enricosada

But if you compare F# with C#, is not just LINQ .Select vs List.map

And i am not speaking about function, who is just a part of why i like F#, not the best one

Is the different defaults who matter, who guide you to an easier code who highlight the domain

- structural comparison vs reference comparison - expression vs statement based - immutability

C# will catchup with some features for sure.

Lot of new C# feature remove boilerplate (file scoped namespace, etc) and is a good trend

But the core defaults will be the same.

That will not push to a single direction (if fact you have LOTS of way to write the thing in C#) while F# try to push to the same way

To do so, C# continue to add thing to the LANGUAGE. Now is a lot more complicated than .NET 2.0

While F# try to do the same, but the language doesnt change.

An example: the async/task.

C# added the async as keyword, plus all needed to make it work, and the compiler generate special code.

F# has built that from the general computation expression feature and (recently) the state machine support.

- FSharp.Core library, who contains most of the types and functions you want to use

- the fsc F# compiler

- the FSharp.Compiler.Service, who is the compiler as a library used by all editors/ide, written to be performant and support the logic of IDE functionalities (find references, etc)

- The Microsoft Visual F# code, who is the F# extension for Visual Studio

So is complicated repo, but for a reason. But nice to work with given the features there

It's really easy to express a domain (with discriminated union and type) and the defaults (immutability, option, removal of boilerplate, high order function to manipulate data, structural comparison not reference) allow me to write correct code, who is readable without too much friction.

Support a repl as first class, so that works too if you like repl driven development

Community is also nice

Type providers works in general, but depends if the type provider library was updated to use latest type provider sdk. Also generative type provider may not works, erasing works

In some scenario support is more stable, other experimental, other are not supported. like every technology.

Because budget is not infinite, you need to prioritize.

Just to show you things happened MS tech related to F# and .NET in the last two years:

- .net core

- .net standard (is not the same as .net core)

- new project system for VS

- new .net sdk (that mean work to support these on VS)

- portable pdb

- F# 4.1

- temporary stuff like project.json, who added work and was replaced

- new .net templating

- F# in VS now use roslyn workspaces (yes, that's big)

- integration of VisualF# powertools in default VS extension

- f# bundled in .net sdk and compiler in .net core sdk

- F# on azure notebooks

- F# on azure functions

- VS 2017

- VS 2017 installer (yes, that was annoying)

And that list is just some of MS technologies, who VF# team need to support/adapt too.

NOTE the list doesnt contains things created from community itself, like Fable. and some of these were added by community

Yes, and there is too:

- UWP

- .NET Native

- Corert

but you need to prioritize and choose your (moving) targets.

So ihmo while UWP can be nice to have (ihmo), was put in a lower priority than the others.

When you choose there are lot of factors:

- time to implement

- unknown

- other things open in parallel scenarios

- support needed to complete/make it usable

Community help a lot the F# development, and also a lot the VS VF# extension, see the repo. Because F# has lot of OSS in the dna.

But that doesnt mean we cannot complain when things need improvements, in some important scenario.

And as a note, the MS VF# project manager was awarded the `F# community Hero award`, that mean the community like and support his work (the award is indipendent and run from community voting)

    "/path/to/file"
    |> File.ReadLines
    |> Seq.iter (printfn "%s")

    "/path/to/file"
    |> File.ReadLines
    |> Seq.iter (fun line -> printfn "%s" line)