{"id":1213,"date":"2024-09-09T18:44:14","date_gmt":"2024-09-09T18:44:14","guid":{"rendered":"https:\/\/rssfeedtelegrambot.bnaya.co.il\/index.php\/2024\/09\/09\/why-is-f-code-so-robust-and-reliable\/"},"modified":"2024-09-09T18:44:14","modified_gmt":"2024-09-09T18:44:14","slug":"why-is-f-code-so-robust-and-reliable","status":"publish","type":"post","link":"https:\/\/rssfeedtelegrambot.bnaya.co.il\/index.php\/2024\/09\/09\/why-is-f-code-so-robust-and-reliable\/","title":{"rendered":"Why is F# code so robust and reliable?"},"content":{"rendered":"

This is a guest post by Vladimir Shchur, lead developer at Access Softek<\/a>. Vladimir is an active open-source contributor, the author of Oxpecker<\/a> and Pulsar.Client<\/a> libraries. He has also published a series of posts on Medium<\/a> and contributed to F# Core<\/a>.<\/p>\n\n

In Access Softek, we\u2019ve been developing software for financial institutions using C# and .NET for two decades, at the same time suffering from lots of bugs. We struggled to implement the Zero Bug Policy<\/a> and had the green light to build one of our new projects, namely EasyCoin<\/a>, in F#, as it was claimed to be a very robust and effective tool.<\/p>\n

The EasyCoin project was challenging, requiring the implementation of distributed transactions with all the possible unexpected outcomes that could happen along the way. The transaction flow included integration with several services, including some internal SOAP ones. The project also required creating a client-facing UI, a web API, an admin site, and a few other elements. The implementation took us about a year and a half for the team of 4 F# full-stack developers, a team lead, a PM and a QA.<\/p>\n

The product has been live for a year, and remarkably, only one user-facing bug has been found so far. I attribute this success to the chosen language. In this post, I will share the specific reasons F# allowed us to write robust code. Some of them may be not applicable to your projects and this also might not mention F# aspects which your company would want to leverage. The following are the particular features that made our company avoid bugs in the software we do and hence make our customers happy.<\/p>\n

Immutability by default<\/h2>\n

F#\u2019s basic blocks \u2014 values and records \u2014 are immutable by default (as in, in F#, it\u2019s easier to write immutable code than mutable code). This is good for thread safety and general code predictability \u2013 since objects don\u2019t change state, components can rely on them without worrying about how other parts of the program might alter them:<\/p>\n

let x = 1
\nx <- 2 \/\/ error, x is not mutable<\/p>\n

type User = { Id: int }
\nlet process (user: User) =
\n user.Id <- 2 \/\/ error, Id field is not mutable
\n user <- { Id: 2 } \/\/ error, user argument is not mutable<\/p>\n

Discriminated unions with exhaustive check<\/h2>\n

Discriminated unions (DU)<\/a> is an F# key feature which lets types hold a closed set of arbitrary data. Importantly, DU match is exhaustive, meaning that adding a case would raise warnings in all not yet handled cases, preventing potential bugs:<\/p>\n

open System<\/p>\n

type LoginType =
\n | Password of string
\n | PinCode of int<\/p>\n

let printLoginType loginType =
\n match loginType with \/\/ warning, not all cases are handled
\n | Password password -> Console.WriteLine(password)<\/p>\n

No nulls by default<\/h2>\n

While many modern languages added some control for doing more null checks to prevent NullReferenceException, F# avoided them from the inception. This means such exceptions are nearly impossible in the end-to-end F# workflows (although, you still need to handle them during interop):<\/p>\n

type User = { Id: int }
\nlet user = { Id = null } \/\/ error, null is not assignable to int
\nlet user: User = null \/\/ error, null is not assignable to record User<\/p>\n

let s1: string = null \/\/ allowed in F# 8 due to interop with C#, warning in F# 9 (when opted in)
\nlet s2: string | null = null \/\/ allowed in F# 9 due to interop with C# and null reference type support (when opted in)<\/p>\n

Idiomatic<\/em> F# way to deal with missing values is using Option<‘T><\/a> type, so that the developer has to explicitly unwrap it and handle the missing value:<\/p>\n

open System<\/p>\n

let numberOption = [1; 2; 3] |> List.tryFind (fun x -> x % 2 = 0)<\/p>\n

match numberOption with
\n| Some x -> Console.WriteLine($”Even number was found: {x}”)
\n| None -> Console.WriteLine(“Even number was not found”)<\/p>\n

No exceptions in the business logic<\/h2>\n

Throwing custom exceptions is one of the popular ways to deal with errors in business logic, however it is also a source of bugs, since there is no way to ensure those exceptions are handled properly. While it is still reasonable to throw exceptions in unexpected cases (like when the database connection fails), you shouldn\u2019t do it in the middle of the business transaction. F# has a dedicated Result<‘T><\/a> type for handling errors, and you can also easily define your more specific DUs:<\/p>\n

type TransactionStatus =
\n | Ready
\n | Pending<\/p>\n

let executeTransaction transaction =
\n if validate transaction then
\n try
\n let isReady = callExternalService transaction
\n if isReady then Ok Ready else Ok Pending
\n with ex ->
\n Error $”Service is unavailable: {ex.Message}”
\n else
\n Error “Transaction is invalid”<\/p>\n

Strict dependency order<\/h2>\n

In F#, all variables, functions, types and files can only depend on variables, functions, types and files defined earlier. The benefits of this are the fact that a circular dependency is not possible by default and extra clarity with \u201cwhat depends on what\u201d, which helps during code analysis and PR reviews:<\/p>\n

open System<\/p>\n

type Person = { BillingAddress: Address } \/\/ error, since the required type is defined below
\ntype Address = { Street: string }<\/p>\n

helloWorld() \/\/ error, the function is defined below
\nlet helloWorld() = Console.WriteLine(“Hello”)
\n<ItemGroup>
\n <Compile Include=”Operations.fs” \/> <!– error, since operations use models defined below –>
\n <Compile Include=”Models.fs” \/>
\n<\/ItemGroup><\/p>\n

Warnings on unused expression results<\/h2>\n

F# warnings will make you think twice about dangling values, where other popular languages would simply ignore that fact, unless they had an external analyzer:<\/p>\n

open System.Collections.Generic<\/p>\n

let people = Dictionary<string, int>()
\npeople.Add(“Jack”, 1)
\npeople.Remove(“John”) \/\/ warning, Remove returns bool value, you need to think about missing case<\/p>\n

Typed primitives<\/h2>\n

F# has a notion of Units of Measure<\/a> which help the compiler to verify that arithmetic relationships have correct units. Among other things, this (together with FSharp.UMX<\/a> package), make it very easy to have your primitives strongly typed with zero cost at runtime:<\/p>\n

open FSharp.UMX<\/p>\n

[<Measure>] type private tenantId
\n[<Measure>] type private transactionId<\/p>\n

type TenantId = string<tenantId>
\ntype TransactionId = string<transactionId><\/p>\n

type Transaction = {
\n TenantId: TenantId
\n TransactionId: TransactionId
\n}<\/p>\n

let getTransactions tenantId transactionId =
\n [
\n { TenantId = tenantId; TransactionId = transactionId }
\n { TenantId = tenantId; TransactionId = tenantId } \/\/ error, TenantId and TransactionId are different types
\n ]<\/p>\n

getTransactions %”myTenant” %”1234″<\/p>\n

Explicit conversions<\/h2>\n

Implicit type conversions are a common source of accidental errors. For example, this code will compile just fine in languages such as TypeScript or C#:<\/p>\n

var x = 1 + “”; \/\/ compiles<\/p>\n

F# compiler won\u2019t allow such implicit conversions and will produce an error:<\/p>\n

let x = 1 + “” \/\/ error, the type ‘string’ does not match the type ‘int’
\nlet y = string 1 + “” \/\/ ok<\/p>\n

Another prominent example of accidental conversion bugs is string interpolation. Let\u2019s say we had this C# code:<\/p>\n

var age = 21;
\nvar displayAge = $”Your age is {age}”;<\/p>\n

Then someone refactored the code and used anonymous type, but forgot to update the interpolation:<\/p>\n

var age = new { Age = 21 };
\nvar displayAge = $”Your age is {age}”; \/\/ no errors or warnings, but wrongly evaluates to “Your age is { Age = 21 }”<\/p>\n

With F#, you can specify<\/a> the type of the \u201chole\u201d to avoid such errors:<\/p>\n

let age = 21
\nlet displayAge = $”Your age is %i{age}” \/\/ ok<\/p>\n

let ageRecord = {| Age = 21 |}
\nlet displayAgeRecord = $”Your age is %i{ageRecord}” \/\/ compilation error, ageRecord is not an integer<\/p>\n

Functional approach to concurrency<\/h2>\n

Reading and writing code with locks is difficult, so actors frameworks are there for help. Actors<\/a> simplify reasoning and reduce shared data bugs by assigning a single owner to data and communicating with each other using messages. Each actor should be able to handle different types of message and they can be conveniently modeled as Discriminated Unions.<\/p>\n

F# has a built-in actor support using MailboxProcessor<‘Msg><\/a>, but you can also easily switch to a more modern Channels library<\/a>:<\/p>\n

open System
\nopen System.Threading.Channels<\/p>\n

type MyMessage =
\n | Start
\n | Print of string
\n | Stop<\/p>\n

let actor = Channel.CreateUnbounded<MyMessage>(UnboundedChannelOptions(SingleReader = true))
\nlet actorLoopTask = backgroundTask {
\n let mutable continueLoop = true
\n while continueLoop do
\n match! actor.Reader.ReadAsync() with
\n | Start -> Console.WriteLine(“Started”)
\n | Print s -> Console.WriteLine(s)
\n | Stop -> continueLoop <- false
\n}<\/p>\n

actor.Writer.TryWrite Start |> ignore \/\/ send 1st message to the actor
\nactor.Writer.TryWrite (Print “Hello world”) |> ignore \/\/ send 2nd message to the actor<\/p>\n

actorLoopTask.Wait()<\/p>\n

Explicit dependency injection<\/h2>\n

OOP projects usually use DI containers for injecting dependencies at runtime, thus dependency resolution bugs often reach production, because real dependencies are not covered by unit tests and missing registration can\u2019t be caught at compile time. With functional architecture, dependencies are passed explicitly as function arguments, which results in:<\/p>\n

Compile time verification, no \u201cunregistered dependency\u201d errors are possible at runtime
\nBetter separation of concerns, different functions only depend on their arguments, not on shared fields (like in constructor injection)
\nEasier testing, since all you need to do is to specify function arguments<\/p>\n

Dependency injection in F# is fully described in this article<\/a>. Example code:<\/p>\n

let notifyUser (env: #IGetUserSettings & #ISendEmail & #ISendSms)
\n userId message =
\n task {
\n let! userSettings = env.GetUserSettings(userId)
\n match userSettings.NotificationType with
\n | Email address ->
\n return! env.SendEmail(address, message)
\n | Sms phone ->
\n return! env.SendSms(phone, message)
\n }<\/p>\n

The bottom line<\/h2>\n

These are just some of the ways that F# helped us write robust and readable code that dropped our bug count to nearly zero. What\u2019s more, F# libraries let you write type-safe SQL (using Type Providers<\/a>), type-safe HTML or IaC (using Computational Expressions<\/a>), type-safe ASP.NET route parameters (using printf module<\/a>), and many more. And it is also worth mentioning that F# brings its goodness not just to .NET, but can run on other platforms with transpilers available to JavaScript and Python using the Fable project<\/a>.<\/p>\n

With that, I\u2019m wrapping up, I hope this article has provided valuable insights and inspired you to explore F# if you haven\u2019t done so already. F# community will be always ready to help in Amplifying F#<\/a>, Slack<\/a>, Discord<\/a>, or X<\/a>.<\/p>\n

The post Why is F# code so robust and reliable?<\/a> appeared first on .NET Blog<\/a>.<\/p>","protected":false},"excerpt":{"rendered":"

This is a guest post by Vladimir Shchur, lead developer at Access Softek. Vladimir is an active open-source contributor, the […]<\/p>\n","protected":false},"author":0,"featured_media":0,"comment_status":"","ping_status":"","sticky":false,"template":"","format":"standard","meta":{"site-sidebar-layout":"default","site-content-layout":"","ast-site-content-layout":"default","site-content-style":"default","site-sidebar-style":"default","ast-global-header-display":"","ast-banner-title-visibility":"","ast-main-header-display":"","ast-hfb-above-header-display":"","ast-hfb-below-header-display":"","ast-hfb-mobile-header-display":"","site-post-title":"","ast-breadcrumbs-content":"","ast-featured-img":"","footer-sml-layout":"","ast-disable-related-posts":"","theme-transparent-header-meta":"","adv-header-id-meta":"","stick-header-meta":"","header-above-stick-meta":"","header-main-stick-meta":"","header-below-stick-meta":"","astra-migrate-meta-layouts":"default","ast-page-background-enabled":"default","ast-page-background-meta":{"desktop":{"background-color":"var(--ast-global-color-4)","background-image":"","background-repeat":"repeat","background-position":"center center","background-size":"auto","background-attachment":"scroll","background-type":"","background-media":"","overlay-type":"","overlay-color":"","overlay-opacity":"","overlay-gradient":""},"tablet":{"background-color":"","background-image":"","background-repeat":"repeat","background-position":"center center","background-size":"auto","background-attachment":"scroll","background-type":"","background-media":"","overlay-type":"","overlay-color":"","overlay-opacity":"","overlay-gradient":""},"mobile":{"background-color":"","background-image":"","background-repeat":"repeat","background-position":"center center","background-size":"auto","background-attachment":"scroll","background-type":"","background-media":"","overlay-type":"","overlay-color":"","overlay-opacity":"","overlay-gradient":""}},"ast-content-background-meta":{"desktop":{"background-color":"var(--ast-global-color-5)","background-image":"","background-repeat":"repeat","background-position":"center center","background-size":"auto","background-attachment":"scroll","background-type":"","background-media":"","overlay-type":"","overlay-color":"","overlay-opacity":"","overlay-gradient":""},"tablet":{"background-color":"var(--ast-global-color-5)","background-image":"","background-repeat":"repeat","background-position":"center center","background-size":"auto","background-attachment":"scroll","background-type":"","background-media":"","overlay-type":"","overlay-color":"","overlay-opacity":"","overlay-gradient":""},"mobile":{"background-color":"var(--ast-global-color-5)","background-image":"","background-repeat":"repeat","background-position":"center center","background-size":"auto","background-attachment":"scroll","background-type":"","background-media":"","overlay-type":"","overlay-color":"","overlay-opacity":"","overlay-gradient":""}},"footnotes":""},"categories":[7],"tags":[],"class_list":["post-1213","post","type-post","status-publish","format-standard","hentry","category-dotnet"],"_links":{"self":[{"href":"https:\/\/rssfeedtelegrambot.bnaya.co.il\/index.php\/wp-json\/wp\/v2\/posts\/1213","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/rssfeedtelegrambot.bnaya.co.il\/index.php\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/rssfeedtelegrambot.bnaya.co.il\/index.php\/wp-json\/wp\/v2\/types\/post"}],"replies":[{"embeddable":true,"href":"https:\/\/rssfeedtelegrambot.bnaya.co.il\/index.php\/wp-json\/wp\/v2\/comments?post=1213"}],"version-history":[{"count":0,"href":"https:\/\/rssfeedtelegrambot.bnaya.co.il\/index.php\/wp-json\/wp\/v2\/posts\/1213\/revisions"}],"wp:attachment":[{"href":"https:\/\/rssfeedtelegrambot.bnaya.co.il\/index.php\/wp-json\/wp\/v2\/media?parent=1213"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/rssfeedtelegrambot.bnaya.co.il\/index.php\/wp-json\/wp\/v2\/categories?post=1213"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/rssfeedtelegrambot.bnaya.co.il\/index.php\/wp-json\/wp\/v2\/tags?post=1213"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}