Each year we’ve had an incredible Advent full of F# and Christmas spirit.

Advent 2017 is coming, this year we have 52 free slots. Do not to lose your chance to reserve a slot and spread your thoughts and love to F# with the community. A lot of amazing initiatives developed this year: Fable, Rider, Ionide, SAFE, Visual F#& VS15, dotNET Core, VS for Mac, Expecto, Azure Functions, new F# books and much more! Join F# Advent Calendar today!

Rules

Rules are very simple:

Choose F# related topic for your blog post and reserve the slot on Twitter or leave a comment to this post. Please note that you do not have to announce the topic until the date.

As the author of what is now becoming an infamous PR, I thought that it’d be an idea to document my thoughts regarding both my motivations for it, as well as my thoughts on the reactions to it from all sides since then.

What’s #nugate?

tl;dr – a tiny and innocuous PR to the NuGet gallery that showed how to install NuGet packages when using Paket was closed abruptly by the NuGet team with an inadequate explanation, and then apparently ignored, despite large community feedback.

The Paket PR

Just a bit of background first on the PR. The idea came when looking at the new version of the NuGet site (which looks much nicer than the current one, I must say) and noticing a “tab view” for how to add a given package to your solution using either NuGet or the dotnet CLI. I thought that this might be…

F# is a functional-first programming language that comes with a substantial object-oriented feature set. It is so feature-complete in fact, that almost any C# class can be ported over to F# code with little substantial alteration.

However significant, this subset of the language is seeing limited appreciation from the community, which I suspect is partly fuelled by the known criticisms of OOP and partly by a desire to be different than C#. After all, this is a functional-first language so we can just replace all our classes with functions. There is also the opinion that OOP in F# merely serves as a compatibility layer for .NET, so it’s really only there to cover those unfortunate scenarios of having to use a library that accepts interfaces.

Enabling Abstraction

One of the most important aspects of maintaining a nontrivial codebase is controlling complexity. Complexity can be contained by partitioning code into logically…

Exception handling is an error management paradigm that has often been met with criticism. Such criticisms typically revolve around scoping considerations, exceptions-as-control-flow abuse or even the assertion that exceptions are really just a type safe version of goto. To an extent, these seem like valid concerns but it is not within the scope of this article to address those per se.

Such concerns resonate particularly well within FP communities, often taken to the extreme: we should reject exceptions altogether, since code that throws is necessarily impure. In the F# community, this opinion is in part realized by advocating alternatives like result types and railway-oriented programming. In essence, these approaches follow the Either monad found in Haskell, but often intentionally avoiding the use of do notation/computation expressions (since that’s just interpreted exception semantics).

The TL;DR version of the approach is that we define a union type for results that looks…

Update (11/28/2016): Dear writers, this year we are going to make an e-book from #FsAdvent posts and to raise money for a good cause (read more here). If you do not allow to use your post, please let me know.

Each year we’ve had an incredible Advent full of F# and Christmas spirit.

Advent 2016 is coming, do not to lose your chance to reserve a spot and spread your thoughts and love to F# with the community. Have you done something special this year? Do you have any unique experience you are willing to share? Have your project incredibly evolved this year? Are there any good ideas for the post, but you didn’t have time to write it? The time has come – it is right now! You have a chance to share your story with the globe! Join F# Advent Calendar and hurry up!

Rules

Rules are very simple:

Choose F# related topic for your blog post and reserve the date on Twitter or leave a comment to this post. Please note that you do not have to announce the topic until the date.

Last week I announced a new library, TypeShape, with claims that it provides a practical way of doing generic programming in F#. I’m following up with this blog post to elaborate why I believe this to be genuinely useful, and how it could benefit the day-to-day life of the working .NET developer.

The pain of Reflection

Almost everybody who has worked with .NET will at some point need to dabble in the murky ways of reflection. Reflection is needed in scenaria where we need to access data in an indirect fashion, or where circumvention of the type system is necessary.

For example, assume that we have defined the following static method

Assume now that we would like invoke that method, with a value whose type cannot be known at compile time. In other words, we want to define a function

First of all, there is no such thing as “the fastest” serializer, it is all contextual.
But under some conditions, I would however argue that Wire is, by far, the fastest of all the .NET serializers out there.

Given the following POCO type.

Round tripping one million objects of this type, that is, serializing and then deserializing a million objects using Wire with all optimizations on, completes in about 550 milliseconds on my personal laptop.

Doing the same using MS Bond, which is the second fastest serializer in the benchmark, takes about 830 milliseconds, and this is while being very generous to Bond as it has some very specific prerequisites.Protobuf.NET which is the third serializer on this benchmark completes in about 1360 milliseconds.

Other serializers that was included in the same benchmark was Jil, NetSerializer, FS Pickler, Json.NET and .NET BinaryFormatter.

Tip #1: Use FSharp.TypeProviders.StarterPack

Community agreed to use this repository as master version for the SDK. You may find SDK files committed to other repositories, some of them (like files in FSharp.Data repository) may even be modified, contain new features or latest fixes. Once changes are tested and generalized enough, they will for sure be contributed back to FSharp.TypeProviders.StarterPack. So it is better to use a version from the official repository to be on the safe side.

Tip #3: Create two solution files (*.sln)

You should not store TP project and projects that use TP in one solution, because when you reference TP dll, IDE/Intellisense loads this assembly and locks file on a disk. After that, you will not be able to rebuild your TP anymore until you close IDE.

So, it does not work in a long run and you have to separate your code to two solutions. The first one (let’s say SwaggerProvider.sln) will contain TP source code, tests for parser and for all components that don’t call TP directly. The second one (let’s say SwaggerProvider.TestsAndDocs.sln) will contain tests, which use TP directly and docs that may also use TP dll.

Tip #4: Automate build (using FAKE)

This tip is quite generic and you have to do it for all projects, but it becomes extremely useful for type providers. It’s tedious to open a new solution (IDE instance), when you want to test latest changes – it is much easier to have a build script that rebuilds and tests everything in one click.

Tip #5: Yes, you can debug Type Providers

Debugging of TP does not look an easy task at first sight (and it is really slow in practice), but it is real.

You can start two instances of your IDE. The first one, for a solution with TP code and the second one for code that uses compiled type provider (here is important to check that the second one really references dll compiled by the first one). For the second IDE you can use TestAndDocs solution from Tip #4 or a simple *.fsx script that calls your TP. The last step is to set break point in the first IDE instance and to attach to the second IDE instance process.

This allows you to debug, but you will not be able to modify the code of TP. After each modification, you will need to close 2nd IDE, rebuild dll and repeat all these steps once again.

After that, when you press F5 from your TP project, VS will automatically build your TP, start your instance of VS, attach to a new VS process and open your tests solution in it.

Tip #6: Write tests using FSharp.Compiler.Service

Usefulness of this tip really depends on the TP you are working on, but if you are lucky enough (like I am) and you have an access to a large collection of schemes for your type provider, you can automate testing of compilation of provided types.

But we can go further and check that provided types are “compilable” by F# compiler (there is no collisions in type names, property names, field names and method names).

The one way to do this is to use “Hosted Compiler” feature of F# Compiler Services. This allows us to create a simple script that just instantiates TP for each schema and asks F# Compiler to compile this generated script.

Tip #7: Handling 3rd party NuGet dependencies

You face a dilemma when your TP needs 3rd party dlls: “How to deliver these dlls to a user?” This is a dilemma, because your IDE will not be able to resolve 3rd party dependencies without your participation if you just add them as dependencies to your NuGet package.

This is the case, for example, when your schema is in JSON format and you decided to use JSON.NET to parse it, or in Yaml format and you want to use YamlDotNet.

Option 1. Pack all dependencies inside your NuGet package.

The simplest solution is to put all required dlls in the folder with your TP dll in NuGet package. In this case, there is nothing to do with assembly resolution and it is definitely a good option to start from.

Option 2. Uses AssemblyResolve event handler.

TP.dll that setups AssemblyResolve event handler that helps IDE find assemblies on a hard drive and tells the compiler that TP will be in TP.DesignTime.dll (but doesn’t reference this assembly directly).

TP.DesignTime.dll that contains implementation of TP.

TP.Runtime.dll that contains the code that should exist in run-time and may be used by provided methods.

TP.dll references TP.Runtime.dll but uses nothing from it. Such dependencies do not break intellisense (because it does not need this assembly), but in the same time your provided code will be able to call code from TP.Runtime.dll.

One of available annotators is “Logo Detection” that allows you to find company logo in your image and recognize it.

.NET is not the part of mainstream Google Cloud SDK. Google maintains google-api-dotnet-client that should allow you to authenticate to and call all available services. API design looks slightly not intuitive for .NET world (at least from my point of view).

I spent some time on Google/SO/Github trying to understand how to use OAuth2 in server-to-server authentication scenario with ServiceAccount.json file generated by Google API Manager.

You cannot use this API without billing account, so you have to put your credit card info, if you want to play with this API.