Comparisons to typescript/node (which I have more ai hours in, but equal experience)
Pros:
* type system is less flexible which simplifies things for the ai
* mostly functional code
* the language hasn’t evolved as much as others because it’s had a strong foundation of features for a while, leading to the corpus containing fairly common themes
Cons:
* smaller corpus
* no reliable hot reloading, which causes annoying iterations of starting a server in the background to test, then forgetting to stop it and hitting errors from starting it again. It does this even when attempting to prompt against it
* Struggles with some breaking changes and interfaces for dotnet things (using old apis, installing old versions of packages)
* file ordering dependency messes with its flow. Usually has to stop to reorder things every once in a while. Can create a mess in the fsproj
Overall my “tier-list” so far has f# below typescript, but above a number of other environments (Kotlin/jvm, Ruby, c#).
Last week I wrote out a 2 page prd for a small service and it got about 95% of the way there (not including tests). If you’re promoting doesn’t have to do with web framework stuff, or you have a repository with existing patterns, it does pretty well.
I gave it a task of “write an inertiajs 2.0 server compatibility library for the oxpecker framework” with a few extra things to create an example test and verify with the playwright mcp. It struggled pretty hard and didn’t end up anywhere close to what I had in my head.
So I’d definitely say that directing it more than vibing would yield a higher chance at success.
> then forgetting to stop it and hitting errors from starting it again
This one is easy to fix. Give it a script that both kills the old process and starts the new one. Then it can't forget. This is what I do; categorically solved the problem.
For me, AI code generation for F# has been pretty good! There's one annoying thing Opus/Sonnet do (honestly don't remember what other models do): use old syntax for array indexing.
values.[index] // Old way of indexing required a .
values[index] // Supported for awhile now
That's the "biggest" issue I run in to, and it's not that big of a deal to me.
Yesterday, it did try to hallucinate a function that doesn't exist; compilation failed, so the agent changed the function to a fold and everything was hunkey-dorey.
Pros:
* type system is less flexible which simplifies things for the ai
* mostly functional code
* the language hasn’t evolved as much as others because it’s had a strong foundation of features for a while, leading to the corpus containing fairly common themes
Cons:
* smaller corpus
* no reliable hot reloading, which causes annoying iterations of starting a server in the background to test, then forgetting to stop it and hitting errors from starting it again. It does this even when attempting to prompt against it
* Struggles with some breaking changes and interfaces for dotnet things (using old apis, installing old versions of packages)
* file ordering dependency messes with its flow. Usually has to stop to reorder things every once in a while. Can create a mess in the fsproj
Overall my “tier-list” so far has f# below typescript, but above a number of other environments (Kotlin/jvm, Ruby, c#).
Last week I wrote out a 2 page prd for a small service and it got about 95% of the way there (not including tests). If you’re promoting doesn’t have to do with web framework stuff, or you have a repository with existing patterns, it does pretty well.
I gave it a task of “write an inertiajs 2.0 server compatibility library for the oxpecker framework” with a few extra things to create an example test and verify with the playwright mcp. It struggled pretty hard and didn’t end up anywhere close to what I had in my head.
So I’d definitely say that directing it more than vibing would yield a higher chance at success.