F# is a "functional-first" language. You can learn about all of the different types of expressions, along with functions.
The F# compiler -- which is open source -- compiles your programs into IL, which means that you can use F# code from any .NET compatible language such as C#; and run it on Mono, .NET Core, or the .NET Framework on Windows.
Pattern Matching is a powerful feature of many functional languages as it often allows branching to be handled very succinctly compared to using multiple if/else if/else style statements. However given enough options and "when" guards, Pattern Matching can also become verbose and difficult to understand at a glance.
When this happens F#'s Active Patterns can be a great way to give meaningful names to the matching logic, which simplifies the code and also enables reuse.
In all cases when extending types and modules, the extending code must be added/loaded before the code that is to call it. It must also be made available to the calling code by opening/importing the relevant namespaces.
Library demo projects @GitHub
Māris Krivtežs wrote two great posts on this topic:
I feel that none of these XAML application styles benefit much from functional programming. I imagine that the ideal application would consist of the view which produces events and events hold current view state. All application logic should be handled by filtering and manipulating events and view model, and in the output it should produce a new view model which is bound back to the view.
MailboxProcessor maintains an internal message queue, where multiple producers can post messages using various Post method variants. These messages are then retrieved and processed by a single consumer (unless you implement it otherwise) using Retrieve and Scan variants. By default both producing and consuming the messages is thread-safe.
By default there is no provided error handling. If an uncaught exception is thrown inside the processor's body, the body function will end, all messages in the queue will be lost, no more messages can be posted and the reply channel (if available) will get an exception instead of a response. You have to provide all error handling yourself in case this behavior does not suit your use case.