See https://dotnet.microsoft.com/download

Download the Sdk, who bundle both the runtime and the C#/F# compilers (everything you need to build a program) and the `dotnet fsi` REPL

All of that is open source, developed in different repos and bundled there in a nice installer.

Support all platform and can cross compile for other OS

Please do not use Mono, because contains an old version of F# and lots of quirks to use.

The current way is .NET (was called .NET Core, renamed recently) because is cross platform by design, and eventually Mono will be merged 100% there.

Plus is tons more performant and better tooling

C# switch are just syntactic sugar. nice for sure.

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.

If they keep adding features to C# I hope it won't become the Frankenstein monster C++ is.

As a note, the codebase is also huge because contains lot of code:

- 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

For me is that pratically every time, if compile, it works.

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

Appveyor also support stop and RDP in the windows build agents for 60 minutes each build. really nice for diagnose the issues

The F# repl (FSI as fsharp interactive) works in .net core 3.0 preview already, you can do `dotnet fsi` to run it

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

Just adding to Enrico's post here, Type Providers have been fully supported since .NET Core 2.1; some libraries just may not be updated yet.

`dotnet fsi` is planned to be fully released later this year with the .NET Core 3.0 release.

For F#, you can also use F# to transpile f# to clean javascript (will use standard babel and has an awesome interop story with existing npm packages or js libraries), and use electron api as is

https://github.com/fable-compiler/samples-electron

Related, the ionide extension of Visual Studio Code ( https://github.com/ionide/ionide-vscode-fsharp ) is implemented with fable, and used to generate extension of vscode (electron/js based). works really well and power the F# language support of Visual Studio Code

An example of Core Erlang usage:

- fez ( https://github.com/kjnilsson/fez ) is an F# to Erlang compiler (compiling to Core Erlang)

A good intro with some word about core erlang too

https://skillsmatter.com/skillscasts/11312-fez-fsharp-type-s...

About GUI on .NET Framework:

- Windows form works but not perfect. The editor works if you install the template for it, but not the auto generation of code, like double click on button -> handler generated. You write code programmatically. but is used a lot. I use it in the repl (fsi), to generate chart, custom data visualization.

- WPF the same, works, no editor (but codegen is less needed)

- Xamarin support F# ( https://docs.microsoft.com/en-us/xamarin/cross-platform/plat... ) on Forms, etc

Some good from community+MS, because community tried to adapt techonologies and make it more friendly to use in F#

- Xamarin XAML in Elmish style, really more idiomatic ( https://github.com/fsprojects/Elmish.XamarinForms ) from F# creator itself (Don Syme, who now work on xamarin division too)

- WPF and Xamarin xaml can be used with a type provider too for statically type view at compile type ( http://fsprojects.github.io/FsXaml/ )

The only one not yet supported is UWP, because of of .NET Native.

All that without speaking of the gui stack outside .net framework, like electron+fable or just fable+elmish/react/react.native ( https://github.com/SAFE-Stack/SAFE-Nightwatch )

GUI development without designer support is just like time traveling to implementing Turbo Vision and Clipper applications on MS-DOS.

Never understood the mentality for designing UIs by coding instead of visually.

I care for what comes in the box, and is directly supported by Visual Studio and Blend.

If someone needs to lose their .NET GUI tooling productivity to embrace F#, then better wait while C# keeps getting F# most relevant features.

Even C++ has better UI tooling support on Visual Studio than F#.

Depends for what you need GUI. You need it for complex LOB app? So no, editor will be good.

Personally, i write c# and xaml, and i dont use the editor (vs or blend), but i edit directly the xaml.

About f# and gui, depends on use case. For example https://fslab.org/XPlot/ to show graphs.

  let series = [ "bars"; "bars"; "bars"; "lines" ]
  let inputs = [ Bolivia; Ecuador; Madagascar; Average ]
  
  inputs
  |> Chart.Combo
  |> Chart.WithOptions 
       (Options(title = "Coffee Production", series = 
          [| for typ in series -> Series(typ) |]))
  |> Chart.WithLabels 
       ["Bolivia"; "Ecuador"; "Madagascar"; "Average"]
  |> Chart.WithLegend true
  |> Chart.WithSize (600, 250)

this is used to generate programmatically i chart. inside a window with some layout, usually in enough. And i can do testing in the repl.

But yes, if you use editor like c# version, F# is less nice to use. But again, programmatically allow other things, like https://github.com/fsprojects/Elmish.XamarinForms

So depends how much time you edit the view (and why), vs gains in the logic behind the view. For me the global tradeoff, but depends, so you are right.

The only time I have ever felt compelled to design a UI visually is when working with iOS or macOS because the framework is so centered around Interface Builder. When I write a WPF or JavaFX view I am not using Blend/Scene Builder to drag and drop controls, but to have a mostly-accurate preview of what crap looks like without having to build and run.

Yes, it keeps trying to reach parity with native UI design tooling both on desktop and mobile OS.

Is already at the beginning of the article, but should be more visibible how MS Research and Don Syme seen the opportunity to add generics (neeeded for F#) and added that. With design already supporting later addition like variance.

Not just the design, the real implementation too in the existing already complex CLR codebase. And that include lot of areas like NGEN, AppDomains, etc, so is no small feat at all, for a production ready framework already used by lot of developers.

I am programming in .NET Framework from v1.0, the v2.0 (with generics) was a clear cut, so is not something you can add too late because it become pervasive in the framework who leverage it in the design (generics in v2.0, LINQ in v3.0, TPL and Async v4.0) As a note, .NET continue to support non generic collections for backward compatibility, but usage is deprecated.

Really interesting piece of .NET history in https://blogs.msdn.microsoft.com/dsyme/2011/03/15/netc-gener...

> Is already at the beginning of the article, but should be more visibible how MS Research and Don Syme seen the opportunity to add generics (neeeded for F#) and added that. With design already supporting later addition like variance.

I definitely agree, that's why I put it right at the start of the post :-)