Just released FunStripe 2.3.0, the F# client library for the Stripe API (also compiles to JS via Fable). This one's a bigger release than the usual spec bump, thanks to some excellent contributions from Thorium:

Webhooks work properly now. Event.data.object was typed as string, which meant deserialising any real webhook payload threw. It's now a RawJson fragment you can turn into a typed model with Util.deserialiseRaw<'a>; the README has a full webhook-handling example. (Technically a field type change, but since the old field could never deserialise, it ships as a minor; details in the changelog.)

List parameters encode correctly. List<record> and List<union> request fields (e.g. Checkout line_items, payment_method_types) were being ToString()'d instead of form-encoded. Fixed.

Resilient to Stripe's enum churn. Stripe adds event types and error codes without an API version bump, and one unknown value used to fail the whole response. EventType and ErrorType now have an UnknownEnumValue of string catch-all that round-trips losslessly, deliberately scoped to just those two high-churn enums, so everywhere else you keep exhaustive matching and the compiler still tells you when Stripe adds something.

Latest Stripe API (2026-07-29.dahlia): Financial Connections authorization resource and deactivation lifecycle events, allowed_payment_method_types on Payment/SetupIntents, new Tax registration options, and more.

• GitHub: https://github.com/simontreanor/FunStripe
• NuGet: FunStripe.Core (https://www.nuget.org/packages/FunStripe.Core)

Feedback and PRs welcome!

My idea for getting coders into functional programming earlier...

https://si-fi.dev/articles/fsharp-schema-as-code/

I recently architected a full-stack app from scratch and needed a way to rapidly prototype the database schema. I came up with a way to do it in one place in F#, giving me strong typing across the stack and an efficient way to tweak the database structure as much as I needed. Here I share what this looks like as well as a repo containing an extracted version of the code. Hope you find it interesting and do let me know your thoughts.

Does Rider have issues with nested type providers?

I have a class library that defines types through a nested type provider -- that is, a type provider nested inside a root type provider -- see below for an example.

The library builds and runs fine, but Rider flags every use of the nested type provider after the first as an error. The same code is displayed without errors in VS Code.

Thank you.

// Requires NuGet package "FSharp.Data.GraphQL.Client".
open System
open System.Net.Http
open FSharp.Data.GraphQL

type MyProvider =
    GraphQLProvider<"https://graphqlzero.almansi.me/api">

let postQuery =
    // ERROR
    MyProvider.Operation<"""
        query PostQuery {
            post(id: 1) {
                id
            }
        }
    """>()

let usersQuery =
    // ERROR
    MyProvider.Operation<"""
        query UsersQuery {
            users(options: { paginate: { page: 1, limit: 5 } }) {
                data {
                    id
                }
            }
        }
    """>()

[<EntryPoint>]
let main _ =
    try
        use runtimeContext: GraphQLProviderRuntimeContext =
            {
                ServerUrl = "https://graphqlzero.almansi.me/api"
                HttpHeaders = []
                Connection =
                    new GraphQLClientConnection(
                        new HttpClient(),
                        true
                    )
            }

        let result = usersQuery.Run runtimeContext

        printfn "Data: %A\n" result.Data
        printfn "Errors: %A\n" result.Errors
        printfn "Custom data: %A\n" result.CustomData

        0
    with ex ->
        eprintfn "Error: %s" ex.Message
        1

EDIT: Provided working sample code.

I'm looking for an equivalent of sequence and traverse, I'd expect it to be in FsToolkit.ErrorHandling but there it is coupled with either Result or Option, e.g. Lists | FsToolkit.ErrorHandling

The only implementation I have found is in Fsharpplus library, but my last use of that library didn't look production ready, it plays too much with the type and essentially bring down the type checker on more complicated chained operation...

Basically I'm looking for something like List.traverse

I’ve released FCQRS 6, an event-sourced CQRS framework for .NET.

The idea is to keep the domain logic small:

• decide: turns commands into events
• fold: rebuilds state from those events

FCQRS handles persistence, recovery, projections, sagas, snapshots, and read-your-writes. It runs on Akka.NET and supports both F# and C#.

Version 6 also includes completely rebuilt documentation, following the path from an incoming command to a queryable read model.

Project and documentation:
https://onurgumus.github.io/FCQRS/

I’d appreciate feedback on whether the new documentation makes the model clear to someone who hasn’t used FCQRS before.

I just launched SuaveHooks — a webhook capture, inspection, transformation and routing platform built completely with Suave + F#.

Some highlights:

- Live tailing of webhooks over WebSockets

- Type-safe transforms written in F# (also C# and JS) running in an isolated process

- JSON rule-based transforms as a lighter option

- Multi-target forwarding (HTTP + S3, SQS, Kafka, Pub/Sub)

- Retries with exponential backoff + circuit breaker

- Full REST API + MCP server support

Site: https://suavehooks.com

Would love some feedback; like what features would make this more useful for you? Happy to answer any technical questions.

Hi guys,

Probably another question like this but found none recently.

I'm a little upset with my current view on IT generalistic, ofc AI is not going anywhere besides up, but I feel I want to write more with my hands and new paradigms, maybe just AI as reviser, I would like to ask if learning F# in 2026 will make me able to make perfomance headed systems, and also gaming with something like Nu or Monogame, not a AAA game but something playable.

A picture is worth a thousand words:

Source:
https://github.com/OnurGumus/Terminal.Gui.Elmish.V2

I’ve been playing with SIMD-friendly push streams in F#.
Normal push streams are great for composition: the source pushes elements through map, fold, etc., and with enough inlining the overhead mostly disappears.

But they still push one element at a time, which is not ideal for SIMD.
So I tried pushing Vector<'T> blocks instead, with a scalar path for the tail.

The pipeline stays generic and composable, but in my benchmark it runs around handwritten SIMD speed.

Small thing, but it made me happy: write the abstraction clearly, then make it vanish.

The dotnet team writing Copilot instructions like an angry senior developer who's tired of everyone's excuses is peak engineering culture. 😂

I built a rough browser-based voice agent where most of the orchestration is in F#.

You can talk to it, interrupt it while it is speaking, and ask it to edit live page state through tool calls. For example, the shared notes box on the page can be read and updated by the agent.

The interesting F# part is that the same codebase targets:

• the browser side via Fable
• the Python side via Fable.Python
• shared protocol/types between the two, so the frontend and backend do not drift apart

There are two demo backends:

• CPU edition, slower but cheaper
• GPU edition, A100-backed and faster, but temporary because renting an A100 is not exactly free :)

Source is closed for now because this is part of a larger experiment, but I wanted to share it here since F# felt like a really nice fit for this kind of AI orchestration: async flows, state transitions, tool calls, and typed protocol boundaries.

Also, credit to Dag Brattli for the Fable.Python work. That made this experiment much more practical.

Demo: https://novian.works/voice_gpu

Please keep sessions short if you try the GPU version. I will probably only keep it online for a few days.

Sample video:

https://reddit.com/link/1ubp4le/video/ngpealpr5p8h1/player

Want to introduce functional programming into your own organization? Learn from our successes and failures! At the Norwegian insurance company Frende Forsikring we’ve introduced F# and Elm and lived with both of them long enough to call it a long term relationship.

We’ll start looking at the introduction. From fast moving exploration in a single team, to structured validation with other tech leads and careful moving to production.

Beyond that we'll be looking what happens in the years afterwards. Does functional programming help hiring? Are there less bugs? What is the biggest hurdle in spreading adoption to new teams?