I've used F# on several projects, and right now we're building all our infra with it. AI does very well it these days.

AI isnt quite as creative and clever coders as humans though, but thats true for any language you direct it at, but its a bit more obvious for higher level languages like F#.

AIs write pretty good F#, but there simply isn't very much of a reason to use F# over C# since Microsoft basically uses F# as an experimental test bed to test .NET features before bringing them into C#. Plus, annoyingly, F# doesn't interop well with existing C# projects which there is even less of a reason for existing .NET shops to adopt F#.

Motion shifted to C# around August of last year. Part of the reason, I suspect, is that the CTO (Hi Chander!) is an OCAML fanboy and F# was the most practical platform alternative.

We shifted all new product backend build to C# (because at this time last year, we were still "AI assisted" and deemed F# too foreign for most devs to read well), but all internal tooling was built on F#.

By maybe May of this year? We had multiple F# backend codebases, fully AI generated. Only one person on the entire team had worked with F# by hand. Several things work in F#'s favor even though it has a lot less representation in training: 1) the people that write F# really love F# so the code out in the wild is going to be better quality (hunch), 2) F# is a bit more terse/dense than C# and less noise in context, 3) F# benefits from the same tooling stack, 4) F# type system is still a bit more expressive than C#.

I know C# deeply so I know what good looks like and I know how to get agents to write good C#. F# I'm less familiar with, but we had great success with it.

Built the massive enterprise backend of a super app fully in F#. From my experience, AI was able to write idiomatic F# code since Opus 4.8 (all models started doing very decent things around that period).