Asynchronous Programming in F#

Analogy categoryAnalogies

The Async<'T> Type and Async Workflows

F# provides asynchronous programming through the Async<'T> type and the async { } computation expression, predating and conceptually similar to C#'s async/await but with an important difference: an Async<'T> value is a cold, composable specification of work that does nothing until it is explicitly started, whereas a .NET Task<'T> is typically hot and begins running as soon as it is created. This makes Async<'T> values safely reusable and combinable — the same async workflow can be started multiple times, run in parallel with others, or composed into a larger workflow without accidentally triggering side effects early.

🏏

Cricket analogy: A bowling machine set up before a Sachin Tendulkar net session sits loaded and ready but fires no balls until someone presses start, just as an F# Async<'T> sits fully specified but inert until Async.RunSynchronously or Async.Start triggers it, unlike a .NET Task<'T> that starts pitching the moment it's created.

Async Workflow Syntax

Inside an async { } block, let! awaits an Async<'T> and binds its result, do! awaits an Async<unit> for its side effect, and return! both awaits and returns another async workflow's result in tail position, mirroring await in C#. To actually run a workflow you call Async.RunSynchronously to block the current thread until completion, Async.Start to fire-and-forget on the thread pool, or Async.StartAsTask to bridge into a .NET Task<'T> for interop; since F# 6, the task { } computation expression is also available and produces genuine Task<'T> values directly, which many teams now prefer for ASP.NET Core code because it avoids conversion overhead.

🏏

Cricket analogy: A commentator narrating a run chase says 'and now waiting for the throw to reach the keeper' before continuing the call, exactly how F#'s let! pauses the workflow to await an Async<'T> before binding its result and moving to the next line.

Composing and Cancelling Async Workflows

Async.Parallel takes a sequence of Async<'T> workflows and runs them concurrently, returning an Async<'T[]> that completes when all finish, while a for/do! loop composed sequentially runs workflows one after another; both patterns keep exception handling straightforward because a try/with inside an async { } block catches exceptions from any let! or do! within it, just like synchronous code. F# async workflows also support cooperative cancellation via CancellationToken — Async.RunSynchronously accepts an optional token, and Async.StartWithContinuations lets you supply separate success, exception, and cancellation callbacks for fine-grained control over fire-and-forget work.

🏏

Cricket analogy: Running DRS reviews for a stumping and a no-ball simultaneously from two different camera angles, then combining both verdicts before the umpire announces the final decision, mirrors how Async.Parallel runs multiple async workflows concurrently and waits for all of them before returning combined results.

Bridging Async<'T> and Task<'T>

Because most of the .NET ecosystem — HttpClient, Entity Framework Core, ASP.NET Core middleware — exposes Task<'T>-returning APIs, F# async code frequently needs to cross the boundary: Async.AwaitTask converts a Task<'T> into an Async<'T> so it can be used with let! inside an async { } block, while Async.StartAsTask goes the other direction, turning an F# async workflow into a Task<'T> that C# callers or ASP.NET Core action methods can await directly. Choosing between async { } and task { } in new F# code often comes down to whether the surrounding code is F#-idiomatic (favoring async) or tightly integrated with .NET libraries (favoring task to avoid repeated conversions).

🏏

Cricket analogy: Converting a locally kept scorebook tally into the official ICC-format scoresheet so international match referees can read it mirrors Async.StartAsTask converting an F# Async<'T> into a .NET Task<'T> that C# code can await.

fsharp

open System.Net.Http

let httpClient = new HttpClient()

// async workflow: cold until started
let fetchPage (url: string) : Async<string> =
    async {
        let! response = httpClient.GetAsync(url) |> Async.AwaitTask
        response.EnsureSuccessStatusCode() |> ignore
        return! response.Content.ReadAsStringAsync() |> Async.AwaitTask
    }

// running several fetches concurrently
let fetchAll (urls: string list) : Async<string[]> =
    urls
    |> List.map fetchPage
    |> Async.Parallel

let results = fetchAll ["https://example.com"; "https://example.org"] |> Async.RunSynchronously

Because Async<'T> is cold, let results = fetchAll urls above defines the workflow but runs nothing yet — only the trailing Async.RunSynchronously actually starts execution. This is the opposite of a .NET Task<'T>, which begins running the instant it's created, and it's the reason F# async values can be safely stored, passed around, and started more than once.

Calling Async.RunSynchronously inside code that's already running on a UI thread or inside another async context can deadlock or waste a thread-pool thread waiting, exactly like calling .Result or .Wait() on a Task in C#. Prefer Async.StartAsTask plus await at the outermost boundary, or stay within async { }/task { } all the way down.

Async<'T> is a cold, reusable workflow specification; Task<'T> is hot and starts immediately on creation.
let!, do!, and return! inside async { } await and bind the results of nested async work.
Async.RunSynchronously, Async.Start, and Async.StartAsTask are the three main ways to actually execute an async workflow.
Async.Parallel runs a sequence of async workflows concurrently and collects all results into an array.
try/with inside async { } catches exceptions from any let!/do! in that block, just like ordinary synchronous code.
Async.AwaitTask and Async.StartAsTask are the standard bridges between F#'s Async<'T> and .NET's Task<'T>.
F# 6+'s task { } computation expression produces real Task<'T> values directly, often preferred for .NET-heavy interop code.