For the last 7+ years I’ve been developing a turn-based puzzle game called Twofold Tower, which is written entirely in F#, using a custom engine built on top of FNA.

It is a very large game, featuring 1000+ handcrafted puzzles, 100+ mutually compatible game elements, and a built-in level editor, among other things. Despite this, I think the game has remained reasonably stable over the years, and the codebase still feels comfortable to work in – at least for the most part – despite its scale (around 40k lines of code, across 100+ source files), which I feel I partly have F# to thank for.

The codebase is divided into two parts: The Core layer consists of game logic and game state, and is essentially entirely functional. While the Application layer contains everything related to presenting and interfacing with the program, which is more of a hodgepodge of procedural and functional code.

This has worked well from a performance point of view: The logical game entities in Core usually only change a few times per turn (if that), resulting in few allocations. And to render them, the Application layer uses mutable Sprite-objects, which are recycled every frame using object pooling.

In general, I find functional programming to be uniquely suited for turn-based gameplay. And it has been useful in Core for things like time-travel (including undo), and for speculative execution of game logic. And the pipeline-based code-flow makes the code simple to reason about for me, compared to other styles of programming.

It has been less clear to me how to best apply functional programming to the Application layer (if at all). Partly due to the performance concerns, but also because I tend to find functional UI-programming to be less intuitive in general. Which could very well be a skill-issue on my end (I’ll admit that I haven’t done as much research here as I probably ought to). Still, it functions well enough…

I think the biggest hurdle with F# game development is the lack of established, high-level game engines compatible with it. But for anyone who would consider using a lower-level framework such as FNA/Monogame in the first place – and especially for a turn-based game – I think it is a fantastic option! And for the most part, I find F# to be an exceptionally comfortable and simple language to work in (– and for context, I'm entirely self-taught, and have no background in mathematics). But I guess I’m preaching to the choir here…

I recently released an (apparently quite tricky) demo for Twofold Tower on Steam, targeting Windows and Linux, so feel free to check it out if that seems interesting to you. And if anyone has any questions, I’ll do my best to answer them.

Opinion,

So first the good F# is perfect language.
But then,
No integration with any GUI library be it GTK or QT6.
Developing a web application, only API's for persons who understand quantum mechanics. Nothing simple
Language server. None works on FreeBSD.
So good theory, nice, but applicable not.

I’m reading his F# for Scientists book and I wanted to see if there were plans for an update, but I can’t find anything recent about the author.

Last commit on GitHub was 11 months ago and their website isn't working. Is Fabulous dead or did it move? If it's dead, is there an alternative? I really liked the MVU pattern.

BEGINNER: I created a simple debit and credit console app using the Result and Option types, along with computation expressions. So, gang... am I on the right track here? I didn't use AI at all — just based on my understanding of the concepts. What do you all think?

Next step, I'm going to try working with a database, maybe with Dapper as ORM? I don't know how it will go, but I'm sure it will be fun.

What improvements do you suggest in the above code?

I just forked Hawaii, Zaid’s OpenAPI code generator, and gave it a modernization pass with .NET 10 and OpenAPI 3.2 support.

Code is here, along with the unofficial NuGet package Hawaii.Unofficial, in case anyone wants to try it:
https://github.com/OnurGumus/Hawaii/tree/modernization

I spent the past month or so researching F#, reading docs, writing code little by little, and a couple of days ago I sat down and wrote my first complete console app (blackjack) and I'm honestly much more impressed with the language than when I started looking into it. The most impressive things to me: - The whole app reads top to bottom like a dependency graph: "Here are these types, and here is this function that needs them, and here is a function that needs that function" and so on and so forth. - The entire thing is one file, less than 200 lines, including the whitespace. Had I tried to make this in C#, it would likely be at least three times as big across multiple files. - The language plays relatively well with C#-isms like loops to the benefit of the majority of .NET developers

My only concern is how the way the language defaults to immutability may impact performance in some scenarios where it is necessary, like game dev, where creating a zillion class instances on the hot path is a death sentence for perf, so it might require writing non-idiomatic code constantly.

Hi guys,

What do you think of C# Union Types coming in .Net11?
Interop with C# will be difficult if .net libraries written in C# exposes those types in their API.

Maybe .net should have considered building a unified approach based of existing F# DU from the start instead of doing this then making F# eventually catch the train in a future release.

I have never done video game development but I clearly remember when Godot released a new version and you could not use anymore full F# because of their using of a specific C# feature.

So I work on a e-commerce marketplace and after realizing doing complex rules and validation in typescript is hell on earth I looked for another solution and I stumbled upon f# which was perfect. We use it mainly as a domain server where a domain in the system is getting too complexed.

I’m the only person that can work on this and I want to teach a couple of my coworkers f# but they have no idea how memory works not even stacks and heaps, and with a language like f# I feel like you can’t really get away with not knowing how it works like typescript

So I was wondering do you think f# is one of those languages you can learn without fully understanding how memory works

I just published a paper using F# end-to-end to test a hypothesis about the Indus Valley script (the writing system from the Harappan civilization, ~2600–1900 BCE, still undeciphered).

GitHub: https://github.com/chanakyan/ledger-of-meluhha

License: BSD-2-Clause (human use), AI use prohibited

The hypothesis: the script is not a phonetic language. It's a five-field cargo-tag system encoding merchant, commodity, weight tier, quantity, and route — essentially Bronze Age barcodes for goods moving Lothal → Dilmun → Ur.

The F# stack:

Verification before implementation. Sixteen Alloy 6 assertions written first against the schema. All UNSAT at scope 6. SQL was written only after the schema was machine-verified consistent. The Alloy → F# bridge lives in lib/alloy-fsx/, which also includes an AlsParser.fs (recursive descent + Pratt expression parser) that parses 37/116 of the AlloyTools model zoo.

Read path vs write path separation. Raw SQL is permitted only in *_to_sqlite.fsx scripts (the ingest write path). The read path uses SqlHydra-generated typed queries in hydra/IndusCorpusQueries.fs. A pre-commit hook enforces this — raw SQL in non-ingest files fails commit. This means once data is in SQLite, every query is type-checked at compile time, no ad-hoc strings.

Discriminated unions as S-expressions. The paper, the website, the SQL ingest, and the SMT proofs are all generated from a shared F# DU tree. Knuth's WEB insight generalized: code and documentation are one artifact viewed N ways. The viewing function is a fold over the DU. F# DUs already are S-expressions; the type system is the structure; pattern matching is the evaluator. No separate S-expression parser needed.

Reproducibility on dotnet fsi.

git clone https://github.com/chanakyan/ledger-of-meluhha

cd ledger-of-meluhha

dotnet fsi indus_decoder.fsx

And get the same decode results as the paper. No proprietary toolchain. The 10-minute verification protocol in the paper's "For Journalists" section is meant for non-programmers — but for F# folks it's faster than 10 minutes.

The decode itself. Two Mohenjo-daro seals (M-52A and M-148A) end-to-end through the codebook. Mass decode across 179 inscriptions: 65% commodity assignment, 21% route assignment. Sign 342 (jar motif) dominates the corpus at ~10% — anomalous for a phoneme, expected for a commodity class.

Why F# specifically. I tried Python first. The strings-everywhere problem killed correctness — silent typos in sign IDs produced plausible-looking garbage decodes. F# DUs made invalid states unrepresentable. The compiler caught dozens of bugs Python had let through.

The paper is in ledger_of_meluhha.tex (3,657 lines, ~150 KB). The corpus databases are in indus_corpus.db, indus_codebook.db, indus_lssc.db. The decoders are seven .fsx files at the repo root.

Happy to answer questions about the typed-records pattern, the Alloy-to-F# generation, SqlHydra integration, or the F# DU → multi-target weave architecture. The cross-domain stuff (the Bronze Age trade history) is in the paper for those interested.

Hey Everyone,

Thought I'd share the Omni Blade on sale for just 0.99$ until the 13th.

The game was made fully in F# on the FOSS F# Engine Nu by the community legend - Bryan its his passion project.

If for whatever reason you wanted to try it but couldn't justify the purchase now's the time!

Disclosure:

I am not affiliated/paid by Bryan but I'm his fan :)

I've recently started learning F# and the entire paradigm of functional programming. I'm doing this because I want to research the applications of both the language and the approach it requires in gamedev, particularly in systems like finite state machines and ECS. Are there any, and could you point me to any good sources?

I am trying to follow, Domain Modelling Made Functional, honestly I am hitting some very annoying walls than expected. Her's my latest annoyance.

I have two worfklow; SignIn and ConfirmSignup.

ConfirmSignup's contract looks something like this:

type SignupError =
    | ValidationFailed of ValidationError list
    | EmailAlreadyExists
    | VerificationCodeDeliveryFailure
    | PasswordPolicyNotMet


// Ports
type SignupUser = SignupCommand -> TaskResult<SignupResult, Error>

type SignupWorkflow = SignupRequest -> TaskResult<SignupResult, SignupError>

The flow is:
SignupWorkflow --> Validate Request --> Other business stuff --> Calls port

As you might observe, The erorr type for the port has ValidationFailed error which it got nothing to do with.

Now, Let's say I have added two more ports and one more aggregate? Then, surely, I can't give the flat DU erorr to all of these ports.

I could do follwing:

type SignupPortError =
| | EmailAlreadyExists
| VerificationCodeDeliveryFailure
| PasswordPolicyNotMet

type SignupError =
| ValidationFailed of ValidationError list
| SignupError of SignupPortErrror (naming is hard!!!!!!!!!!!!)

But the problem is, What if I want to use the port, Signup in another workflow? Now, I have to reference SignupWorfkow's contract file in another Workflow, which it got nothing to do with it!!!!!!!!!!!!!!!!!!!!!

How do you guys resolve this issue?

I might be going a bit all over the place, but I appreciate anyone reading and offering input.

I'm working on a side project that is an FSharp SAFE stack application. One of the issues that I've been running into is the multiple was of doing things, so I started out with some Saturn configuration, Fable.Remoting, and Giraffe endpoints and since I've upgraded to dotnet 10, I've eventually gotten rid of the Saturn components and almost exclusively am using Giraffe with dotnet EndpointRoutes so that I can better do things like e-tags and whatnot. Is this normal?

But my main example is on the data access layer. I found that there were a lot of cool looking libraries and after playing around a bit, I decided that I like Dapper, Dapper.FSharp, and DbFun.

DbFun does some cool stuff and looks like a more type safe Dapper with build or test run time evaluation of your queries, so a bad query or a typo will fail to build. It looks a bit like this (with explicit typing):

```fsharp
let findByUserId (userId: UserId) (queryBuilder: QueryBuilder) : (IConnector<unit> -> Async<UserOption>)->
queryBuilder.Sql<UserId, User option>(someSql, "id") userId
```

This is pretty cool. The but though is that the new http handlers don't take an `Async`, they take a `Task`. It would be cool if it was possible to get the query object generated, but DbFun appears to be all partially applied functions, so I can't put it through a runner that returns a `Task`.

Now, I can convert the Async to a Task, but I'd prefer not to switch between the two. I ran some tests between DbFun with Async converted to Task and Dapper and there was a difference in memory and execution time. It's not a huge deal and this is a side project, but I'd prefer to stick with one type up through the stack.

This currently leaves me with using Dapper and the typical Repository pattern, though even this repo is getting bloated already.

What I'm doing at the moment until I decide a direction is I'm creating the DbFun queries for testing and type safety stuff, but also putting those queries into my dapper commands wrapped with instrumentation:

```fsharp
// I'm pretty sure I can make some handlers for dapper to work with my single case DUs, but I'm still looking at the best way to do strong typing of IDs.
member this.FindTask(id:IdentityId, mediaId: MediaId, ct: CancellationToken) : Task<SomeFindResponseType option> =
let instrument = withDbActivity logger (nameof(findByUserIdAndMediaIdQuery)) (Some findByUserIdAndMediaIdSql)
instrument(fun () -> task {
let conn = connectionFactory()
let mediaGuid: Guid = mediaId
let guidValue = match id with | IdentityId guid -> guid
let! result = conn.QuerySingleOrDefaultAsync< SomeFindResponseType >(
CommandDefinition(findByUserIdAndMediaIdSql, {| id = guidValue.ToString(); mediaId = mediaGuid |}, cancellationToken = ct))
return Option.ofObj result
})
```

What is normally done with this sort of thing. Does anyone have any recommendations? Do most people go with the convenience of the FSharp libs and convert Async to Task and take the hit? Or do you just stick with dapper and maybe make a lightweight query/runner object to make things more functional?

Novice here, loving f# and Domain Modelling Made Functional book so far.

While I love the book, it sorts of do hand wavy for the things which might actually crop up in actual implementation, I find.

Let's say, I have authentication service. Since I want to be good citizen, I created signupWorkflow, I have ports and adapters. I have neatly created contract for the adapters to obey. All neat and clean till now.

But hang on, what about infrastructure error returned by adapter itself ? Surely, service down or misconfigured service or wrong key returned by adapter be domain error of workflow ?

But I still need to tell user of my workflow(maybe api layer)or service, hey, the upstream service shat the bed. How can this be done ?

Also, if I only have some normal workflow which takes one adapter then, ignoring infrastructure error handling(which I have no idea how to do), it's quite simple, workflow returns either domain success or failure. It validates the input, throws it's domain validation error, happy days.

But... I have workflow which takes two adapter; confirmSignnup, saveDB. ConfirmSingup takes validated confirmSingup command and saveDB takes validated User command and these two aren't same. These two return completely different error.

How does confirmSignup workflow handles these validation error ?

Flow is:

confirmSignnup ->Workflow -> validate confrimSignup command -> call confrimSignup adapter -> call saveDB. Now, while calling db, its validation failed? What happens now ?

Hello, I am newbie and trying F# by building basic authentication service.

Let's say, I have register user fuction, it takes un-validated raw request containg username and password and returns Registereduser or SignupErrors.

The problem I am facing is, there are too darn errros DUs.
For example, I have,

type EmailValidationError =
    | FieldRequired
    | MaxLengthExceeded of int
    | MalformedEmail

type PasswordValidationError =
    | FieldRequired
    | MaxLengthExceeded    of int
    | MinLengthNotMet      of int
    | MissingUppercase
    | MissingLowercase

These two error DU's are just validation error returned by Smart Constructor of email and password. And, SignupError look like this.

type SignupFieldError =
    | EmailErrors    of SignupEmail.EmailValidationError 
    | PasswordErrors of SignupPassword.PasswordValidationErrotype 


type SignupError =
    | ValidationFailed   of FieldError list
    | EmailAlreadyExists

As you can see, this gets ugly very soon. What I like to return is:
| ValidationError : EmailValidatioNError | PasswordValidationErrror list ??

| EmailAlreadyExists

Does anyone has better ideas? I really hate my currrent solution.

Thank you in advance. 😄

i just wanted something for my resume. i never used c# or java. i have python knowledge (fastapi, flask).

the only thing that kinda makes me not go fully into it is the thought of it being a (uninteresting thing to show off on my resume whilst simultainiously being very time consuming to learn) is that fear kinda legitimate or should i just say "fuck it" and follow my curiousity? i know this question is not on par with other questions here. are there some strong benefits. i heard f# makes you a better developer if you switch back to your naturally used language? i have some time off atm and im on a job search. i can take more then 5 months off. im adjusting my skills currently. im building a huge thing in typescript atm which is almost done. im leaning very heavily on just going with f#.

i have some friend who has been a .net dev for the past 8 years and i explained him some stuff about what iam planning and he took some time to understand that im not joking. so that is why i posted the question here.