enricosada
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
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
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
- 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...
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.
- 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 )
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...
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)
VSCode (with ionide), vim (vim-fsharp binding), emacs (fsharp-mode) already support it, with full intellisene. VSCode also support debugging.
About the aspnet stack, same future limitation of C#, as discussed on the post. But there are also alternative web stack, like Suave.
"/path/to/file"
|> File.ReadLines
|> Seq.iter (printfn "%s")
the printfn can be expanded as function, instead of partial app "/path/to/file"
|> File.ReadLines
|> Seq.iter (fun line -> printfn "%s" line)Debugging in vscode is coming soon (before rtm), works already in dev version
And lots of good tutorial/ideas
Or use VS2017-rc, to use f# 4.1 with .NET framework
Or use .NET Core sdk and .net core https://github.com/dotnet/netcorecli-fsc/wiki/.NET-Core-SDK-... the default templates use new f# 4.1
Ionide in vscode support .net core (both project.json and msbuild sdks), atm there is a temporary issues with rc4, but feel free to use a previous sdk (are really similar, no need to stay bleeding edge, and will be fixing sooner than later).
See wiki https://github.com/dotnet/netcorecli-fsc/wiki for more info about f# and .net core, or new sdk (all version, with how-to and workaround if needed)
Or there is also a new attempt (https://github.com/dustinmoris/AspNetCore.Lambda) to use api similar to suave, more integrated with asp.net core itself (security/auth/etc).
- xamarin works with f# and support it: https://developer.xamarin.com/guides/cross-platform/fsharp/f...
- use react native (with fable to transpile f# -> js): https://github.com/fable-compiler/fable-react_native-demo
for web you can use:
- suave (http://suave.io)
- aspnet core (or aspnet core mvc)
both works with .NET, .NET Core and Mono
- use Suave (https://suave.io/), best from f#, works on .netcore too
- use Aspnet Core Mvc (just `dotnet new -l fsharp -t web` in dotnetcore), or just aspnet core
The only ide who support f# and .net core is VSCode (with Ionide extension who add f# support)
see
- https://github.com/dotnet/netcorecli-fsc/wiki/.NET-Core-SDK-... for LTS of .net core 1.0 (project.json)
- https://github.com/dotnet/netcorecli-fsc/wiki/.NET-Core-SDK-... for msbuild based (latest bits)
- how can you set a property to null? if setting to null is going to be used the old value - there is no structural equality - only for properties with reference types, value types non nullable (like int) cannot be used like that
It's really lovely when a tool written in another tech (Python there) can be used/extended with others stack/tech, because was written as language agnostic. That should be a rule for good design in oss tooling. Not starting using language specific communication, but extensibile from day0 in design (obv default language can be bundled)
ide are good (intellsiense/debugging), especially vscode, but sdk works already from command line and text editor.
about docs, check the new docs website (oss, accept pr):
- https://docs.microsoft.com/en-us/dotnet/articles/core/
- the getting started doc https://docs.microsoft.com/en-us/dotnet/articles/core/gettin... has tutorial for everyone (cli/vs/vscode/xam), and all os. is not vs centric
after that as usual
- dotnet restore
- dotnet build
- dotnet run
- dotnet pack
- dotnet publish
- dotnet test
the cli is the same, the dotnet/cli team added other commands too (dotnet msbuild, dotnet clean, and more in development using an extensibility to install global commands)
But for some components is ok to contribute there:
- mono(xamarin) was already migrating to use open source components like the bcl (corefx) after the initial open source of code by ms. It's like dont write two times the same stuff.
- coreclr: the .net core runtime
- corefx: the standard library (base class library like io etc), used by .net fw (win) and .net core and partially by mono
- roslyn: that's the c#/vb compiler, also mono is trying to reuse that
- cli: it's the sdk for building projects. Can the project system changed? yes, but not needed now (.net core it's boostrapping another xplat runtime so need tools). as a personal note, the cli team doesn an awesome job to make it easy to contribute
and some notes:
- asp.net is a web framework, it's used a lot, nice ppl contribute. who like servicestack/nancy/suave, use that instead.
- fsharp (http://fsharp.org/) was and is already driven by community, and lang decision are in repo https://github.com/fsharp/fslang-design by community and lead by @dsyme
And you should also check dotnet foundation pulse and community projects (like Nancy/Nunit/Akka.net/mbrace).
Lots of the work done by ms can be useful for others, see Kestrel server (damn fast) who can be used by other web projects like Suave (https://github.com/SuaveIO/suave is a lib, not a framework :D)
- dnx was the predecessor of cli, and replaced by it (good job by aspnet team to boostrap xplat on netcore)