Hi my dear blog readers!

First of all, happy holidays! Now I’m back to joining Sergey Tihon’s F# advent blog 2018 gathering! Smile

My past 2017 advent blog is available here: https://fsharpmonologue.blogspot.com/2017/12/advent-2017-current-state-of-f-4x.html

In this blog entry, I bring you the states of F# news and updates in two major subtopics: the tooling ecosystem, and the community surroundings.

F# state in December 2018

A lot has happened in 2018, particularly the progress that has been made from Microsoft, F# communities, and the whole cool participations on F# github repo.

To increase clarity, let’s start discussing F# tooling ecosystem.

F# tooling ecosystem updates

The F# tooling is basically evolved since 2005 (as research project before integrated in Visual Studio) into these components:

F# Language Specification
F# Compiler
F# Core libraries
F# Compiler Services (since 2013)

Note that although F# Compiler Services derives from F# Compiler, the F# Compiler Services is very important. Because it brings parity with Roslyn as compiler service. It is also a good sample of having the compiler created with the language you want to compile.

Thanks to its flexibility and power, F# Compiler Services can be used as true component, and it is suitable to be used as language services.

Ionide use F# Compiler Services heavily to provide F# support in Visual Studio Code, and it enjoys many features available in Visual Studio.

Now in Visual Studio 2017 from 15.6, these are the noteworthy F# updates:

Versioning model has been changed to decouple from Visual Studio version releases. This brings F# tooling more freedom and flexibility to progress further, although F# tooling is closely related to a VS release, as described in this RFC of F# versioning plan on GitHub. A follow up article by Phillip Carter brings more detail that VS 2017 15.7.x has F# 4.4, and 15.8.x has F# 4.5, like the captured table below. Note: there will be no 4.2, 4.3 version, it will be version 4.5 or later.
Related to previous point, VS 2017 15.7 will have F# 4.5. And this version will be the same version as F# Compiler Service related iteration.
F# supports the same semantic of ValueTuple as Struct tuple (since 15.6). This brings closer compatibility with the .NET class library of ValueTuple in .NET Framework 4.7.
F# supports full file ordering for .NET Core 2.0 or later project (since 15.6)
Realtime multi TFM targeting (a.k.a. multi targeting in .NET team blog, since 15.6). This brings unique experience compared to other language tooling such as C#/VB, because C#/VB doesn’t have this yet!
Go to definition from the member tooltip (since 15.6)
Removal of dependency to Windows 10 SDK (since 15.6). This brings less size and leaner requirement to have F# development.
..and many more in 15.6! For more detail, please visit this official blog post: https://blogs.msdn.microsoft.com/dotnet/2018/03/06/f-language-and-tools-update-for-visual-studio-2017-version-15-6/

This is the versioning illustration:

This is nicely documented as RFC in F# Language Design repo in https://github.com/fsharp/fslang-design/blob/master/tooling/FST-1004-versioning-plan.md

In 15.7, F# tooling keeps updated too. These are the noticeable updates:

New F# template for ASP.NET Core 2.0 project! This is a very amazing progress since 15.5, because now we could create ASP.NET Core using F#
Enabled generating F# AssemblyInfo from properties with the F# compiler in the .NET SDK. This is not trivial but it is closer to C#/VB feature to support common AssemblyInfo infrastructure that common in C#/VB project.

A quick hands-on sample to use F# new ASP.NET Core template is by executing “dotnet new web –lang f#” like this illustration: (I run against .NET Core 3.0 Preview 1)

Now let’s see what’s inside this folder:

Looking at the content of Program.fs, we now see that we have the same quick start from C# template:

This code implies that we use Kestrel by default.

To be maximally applicable to use F# with ASP.NET Core, I recommend to use Visual Studio Code 1.28 with the updated Ionide.

Now, the other wonderful things happened since July 2018 are the updates from communities!

Bonus fun fact of Microsoft F# repo: it uses Azure DevOps since June as the main CIs!

F# community tooling update

These are the best updates from community so far:

Paket now supports .NET Core 2.2 and .NET Core 3.0 as one of its TFM support since 5.181.0.
Fable is reaching version 2.1, and it has tons of bug fixes

That’s it folks!!

Happy holiday and Merry Christmas!

Yes, another speaking opportunities in the last month of 2018! The date was 13th December, 2018.

In this event, I was invited by Hananto, leader of DevOps Indonesia community (also commonly called DevOps-ID). This is the first time I was asked to participate to speak for community beyond or outside my own community!

Therefore, I feel grateful and many thanks to Hananto for this opportunity! Of course, I always welcome for invitations from other community, not just from my own such as MUGI and Lambda Jakarta.

The host, Shopee, has nice arrangements of materials and speakers, not just me. I am glad that I could see one of their engineer presenting the experiences on optimizing internal’s Shopee apps, with basic telemetry and logging.

I bring the topic of having gentle intro on DevOps, not just as concept but also a culture.

It is common in Indonesia that most companies see DevOps as a dedicated team that oversees both Development (Dev) and Operations (Ops), without actually trying to ensure collaborations and interactions between those two. Therefore, frictions are often seen later instead of continuous communication and collaboration.

I also gave quick intros on how easy Azure DevOps to use with Azure using free basic app services, so dev and ops can have the same streamline experience on how basic cycle of DevOps can be simplified but still applicable on both Dev and Ops department.

Here’s the pictorials from the event: