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.

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#.

I also agree with this. When we were internally finalizing on C#/F#, I showed the CTO that most of what he liked about F# was already possible in C# (though requiring third party libs like OneOf or Dunet) with the benefit that C# syntax is more familiar for most folks. With 15, I think they are even closer now.

One of my favorite things about F# is what some would consider a deficiency: that within a project, files must be ordered and you may only refer to a symbol defined earlier, with the sole exception of types which are explicitly declared together in a single statement (`type X = ... and Y = ...`).

This in contrast to C# where, within one .csproj, there is no "order" and all classes and methods are able to mutually reference one another.

The F# way creates an annoying housekeeping step of maintaining file order, and would be a nightmare to do with manually edited .fsproj files (I have only ever written F# with an IDE), but IMO, it is worth it. On the reading side, it makes it easier to understand how a project you've never read before is structured, since you know the order of the F# source files also must be the bottom-to-top layering of the code. On the writing side, it sometimes causes one to rethink the architecture and simplify it to minimize the number of mutual declarations.

The advantage of F# over C# is defaults and baggage. The FP story in F# is great. In C# it’s possible.

That's a good way to put it. C# can be made closer to F#, but it has to be done so explicitly.

That might be true. But I still think code and ideas are more clearly expressed in a higher level language like F# still. Even though C# has adopted a lot of features from F# over the years, F# is still a lot cleaner to read and write with its excellent type inference and super minimalist syntax.

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).

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#.

Seems very good at it; for a while in my F# project I didn't know how to tell claude code on the web how to install it, but claude still made code that worked fine - its COT said, paraphrasing: "no F# compiler here so I will check this code by inspection". Later I learned how to make F# available there - in claude.md tell it to install the ubuntu dotnet runtime via apt, which includes F#. May not be needed anymore though.

when I realised I didn't have time to actually finish my own programming language (there was a big change needed in the type checker and it would have taken months with how much I can use a computer atm), I let claude something like 98% of the work, and it worked very well. The code comments are awful, but the code is ok. recently i have just let it have a go, and the code has grown more than I care for, but generally it has been doing well: https://github.com/bjoli/Bjolang