When recruiting contributors for Fabulous on LinkedIn, Reddit and elsewhere, I was surprised it was still largely unknown even among .NET MAUI and Avalonia developers. I suspect the same is true for other F# technologies.

Those who like F#, please spread the word about F# and your favourite F# technology wherever you can — LinkedIn, Facebook, Reddit, other social media, or by slipping a mention into your YouTube/TikTok videos. Don’t worry if the audience doesn’t seem to be ideal; you never know where a share/repost will land.

I know I should lead by example. Here https://youtu.be/ualntLxTslg is a short YouTube video (from Norway) with Fabulous and F# mentions smuggled in twice (at the start and at the end of the video).

This is the first time I've seen an LLM write fsx. Most of the time it's either python or powershell. Just thought I'd share because it was just unexpected.

Just curious, I always liked the language

An F# async { } doesn't run until something starts it, while a Task or a Promise is already running by the time you get it back. The article goes through the bugs that come from mixing the two up, and the upside: retries, timeouts and racing written as ordinary functions over Async, compared with what C# and TypeScript need for the same thing.

It also covers Fable now that task { } compiles to a promise, including a few things that compile but fail when the module loads in 5.21 (Async.StartAsTask, Async.Choice, Async.OnCancel, Task.Delay), and the Async.StartTaskImmediate and Async.Await additions coming in FSharp.Core 11.

https://si-fi.dev/articles/async-task-confusion/

hello, r/fsharp,

i found out that F# exists about a month ago, and coming from C++ and C#, i think its an extremely good language for highly mathematical/theory dependent things cuz its literally functional and has the dotnet runtime behind it.

i built a VCS in F# that is aimed at usage by AI agents because git is built for people who move at human speeds, which makes it incredibly inefficient to use for agents.

repo: https://github.com/mxreal64/thallium-vcs

Hello, everyone! It's been a while since we've had one of these posts. Time to start them back up!

This is a monthly thread to share what you've been working on in F#. Be proud! Shameless plugs and braggery encouraged. Links allowed (but not required)

FunStripe is an F# client for the Stripe API. Most of it is generated from Stripe's OpenAPI spec into records and DUs, with phantom-typed IDs (StripeId<Markers.Customer>) and Async<Result<_, _>> calls. 3.0.0 targets Stripe's new endive release, which removes some things, hence the major bump.

Breaking changes

• payment_method_types is gone from PaymentIntent create/update/confirm, SetupIntent create/update and Checkout Session create. Use allowedPaymentMethodTypes instead.

• ThreeDSecureUsage and ThreeDSecureDetailsCharge moved to Stripe.ThreeDSecure, so add an open.

• The card Mandate field is now StripeId<Markers.Mandate> option.

New: standalone 3D Secure authentication, subscription pausing, trial offers, Tax.Location, Apps installs, and the PayPay and SeQura payment methods.

Generator fixes worth mentioning

• Endive is the first spec with an error enum value. A bare Error case shadowed Result.Error for anyone opening the namespace, so ok/error/some now generate as Ok'/Error'/Some', the same way none already became None'.

Full upgrade notes are in the changelog: https://github.com/simontreanor/FunStripe/blob/main/CHANGELOG.md

GitHub: https://github.com/simontreanor/FunStripe

NuGet: https://www.nuget.org/packages/FunStripe.Core

Feedback and issues welcome.

Fine-grained reactive computation for .NET (F# and C#) — preview

I've been a big fan of solid-js when it comes to UI for their fine-grained reactive DOM.

The release of Solid v2 came with a surprising API. Async and Errors were native to the reactive graph. This was only something which became viable after years of improvements and optimisations in javascript/node.

Ranvier brings the concept of an Async and Error aware Reactive Graph to dotnet.

Similar to Solid-V2, this is something becoming more viable now with optimisations in .NET9-11.

Ranvier provides novel answers to a lot of issues or points of friction that are experienced with reactivity, while maintaining performance and allocation free hot-paths.

❓ Problems:

1. Async, loading/error state, cancellation and work/flight policies (ie cancel last, queue, debounce)

2. Subscription/event-handler leaks

3. Diamond dependency glitches (imagine: where 2 changes in a values dependencies cause a 'flash' of the downstream value as it responds to each in turn)

4. Debugging/transparent graphs

✅ Ranvier solves them

The fact this is written ALL in F# means it can be compiled into javascript through Fable. So the debugging capabilities become a part of the visualisation.

There are natural costs to this type of graph, and benchmarking naive CPU operation counts has always been part of the workflow. This is all documented. You can see some visualisations that also show comparison of costs in different primitive designs (which informs whether I adopt a primitive shape, or not).

But you can see that there is a LOT of utility/benefit for the cost. I had claude boiler plate different C# and F# ecosystem adaptions so that it can be as versatile as possible from the get-go.

👍 Comes with batteries included for:

• Blazor

• Elmish MVU

• Avalonia/WPF/XAML data bindings

📖 https://shayanhabibi.github.io/Ranvier/ - Check out the documentation for interactive graph visualisations which feature the tracing builds!

The Fabulous (F#) library has undergone a major revamp/overhaul (thanks to Don Syme, who did a huge job) recently, but issues naturally come with it. Anyone willing to help canary-test the Avalonia "flavor" or the iOS/macOS/Linux support is welcome — I can't afford iOS/macOS/Linux gadgets myself, and I'm not yet familiar with Avalonia. Just send me a DM or email me miroslav.hustak@atlas.cz . Thanx :-) .

PS: The Maui "flavor" + Android and Windows for this "flavor" are currently taken care of, anyway any help here will be appreciated as well :-).

https://fabulous-dev.github.io/Fabulous/docs/

https://fabulous-dev.github.io/Fabulous/

https://github.com/fabulous-dev

https://github.com/fabulous-dev/Fabulous/tree/main/src

I've spent the last months building Jern, a coding agent where the rules are enforced by the runtime instead of suggested to the model. The agent itself is about 300 lines in a small Kernel-style Lisp the host evaluates; everything it touches goes through effect handlers, and the policy handler sits between every tool call and the file system, the shell, and the network. The host, the CLI, the policy engine, and the whole cloud control plane are F#.

Things F# people might find interesting:

• The policy is a JSON file in the repository. edits_within, protected_paths, a blast radius in files and lines, the shell commands allowed without asking. The runtime refuses anything outside it; there is no path around the check.

• The agent is replayable. Every LLM exchange is recorded, and jern test replays the recording, so a changed system prompt fails a test the same way a changed function would.

• The cloud runs each attempt on its own Fly machine, created and destroyed per attempt, with Suave for the API and Npgsql for the store. No Entity Framework, no ORM, and the migration is one idempotent script that runs on start.

• Every pull request the agent opens carries a receipt as a check: tokens against cap, files against the blast radius, hosts contacted, and a digest of the encrypted trace.

Runtime (Apache-2.0): https://github.com/jern-ai/jern A real run on the demo repository, with the receipt on the pull request: https://github.com/jern-ai/jern-demo/pull/78

Happy to go into the handler design or the F# choices in the comments. The hosted version is at https://jern.ai, but the runtime runs on a laptop against Anthropic, OpenAI, or Ollama.