From an outsider's perspective, it feels like Ocaml has more active development of features, between the new effects system they added in 5 and all the work Janestreet is doing to let Ocaml developers have more control over performance.

F# is not stagnant thankfully, it gets updates with each new version of dotnet (though I haven't checked what is coming with dotnet 10), but I don't recall anything on the level of the above Ocaml changes in years.

Applicative Computation Expressions are a big deal (added in F# 5). Recent changes have been smaller in scope.

Unfortunately lots of the more advanced stuff seems to be blocked on C# team making a decision. They want a smooth interop story.

But F# remains a solid choice for general purpose programming. It's fast, stable and .NET is mainstream.

Oh yeah I love f#, I need to find more excuses to use it. I just wish it felt like MS was willing to invest more into it. But at least they have not abandoned it and continue to put some resources into its ongoing growth.

Tynan's book is popular, but in my limited experience the first book most people recommend for anyone looking into design is Book of Lenses. Mind you I think both are worth reading. Lenses is just a more systemic and deeper dive.

I need to sit down and give this a proper read, but anyone who wants more of Raph giving insights into game design should check out this old GDC talk he did about Practical Creativity: https://www.youtube.com/watch?v=zyVTxGpEO30

Eh, I'd say it depends.

I write way more algol-derived language code than ML, yet piped operations being an option over either constant dot operators where every function returns the answer or itself depending on the context or inside out code is beautiful in a way that I've never felt about my C#/C++/etc code. And even Lisp can do that style with arrow macros that exist in at least CL and Clojure (dunno about Racket/other schemes).

Personally I'd tweak your last sentence to "return statements in the middle of a function."

Early returns at the very top for things like None if you pass in an Option type don't increase the risk of bugs, but if you have a return nested somewhere in the middle it makes it easier to either write bugs up front or especially have bugs created during a refactor. I certainly have had cases where returns in the middle of a beefy function caused me headaches when trying to add functionality.

Functional languages are not necessarily pure though. Actually outside Haskell don't most functional first languages include escape hatches? F# is the one I have the most experience with and it certainly does.

For what it's worth, Haskell has plenty of escape hatches itself as well.

Interesting that the ECS you linked beats out Flecs .net bindings. I wonder if it is because of copying to/from the dotnet heap.

Looking over the readme.md I find it interesting they don't list dotnet 9 support but they do list 7 so they do seem to support non-LTS versions but skipped 9 (mind you maybe they just didn't update the readme?)

Up until midway through Hades 1 development Supergiant was a c# shop with their own engine on top of libraries (the fact they rewrote their core tech in the middle of a game project that was already available to the public remains insane to me).

First: Godot is rad, and if you're willing to use third party tooling you can even use rust to code your logic (official Godot languages are gdscript, c#, and c++, but the community has added support for a lot more like rust and swift).

Second: building the editor (in Bevy, same way godot's editor is built with the game engine) is an active project so if you think Bevy is interesting it is worth keeping an eye on whenever that gets released.

Yeah I've mostly been keeping an eye on Bevy from a distance for this reason. cart is still willing to break API compat if he finds a better solution (and since it is pre-1.0 I do not blame him). The API breaks and an editor are probably the two biggest features Bevy needs, and the editor is an active project so I'm anxious to see how that goes.