[benrjackson]

Currently you can't target iOS, Windows store & WebGL with F#. For these platforms Unity uses an IL to C++ transpiler which doesn't work with F#. This might change in the future (one of the Unity devs submitted an IL2CPP issue in the F# github repo a few weeks back).

Desktop platforms work fine.

F# doesn't have the Unity editor and project support that C# & UnityScript have. In practice this isn't much of an issue.

There are few things to be mindful of:

1. The F# target platform must be changed to Unity's .net 3.5 equivalent. Similarly, full framework support must be enabled in Unity.

2. VS debugger support requires turning off optimisations and running a post build step to convert between Microsoft's pdb format and Mono's mdb. The debugger itself is actually far more stable for F# than for C#. 3. Unity profiler support requires adding the compilation symbol 'ENABLE_PROFILER' to the F# project.

[danbolt]

I've heard that the Mono runtime in Unity is a bit old and doesn't support tail calls as some of the newer stuff.

I haven't had much luck finding concrete evidence though. Is this an issue with Unity and F#?

[benrjackson]

The Mono runtime Unity uses is, I think, a fork of Mono 2.8. The tailcall op wasn't implemented in Mono until 2.10 (again, I think). The tailcall op is essentially ignored by Unity Mono.

To date, we haven't had a single stack overflow in our 10k LOC app.

I should mention that the style of programming we are using is alot more imperative than the typical F# program. Any potentially large collection is an Array, C# list or Dictionary. F# immutable lists (and maps) are still used in most areas where data sizes are known to be small and allocations are not so important.

The Mono runtime used by Unity has a very inefficient non generational garbage collector (conservative Boehm). A generational GC wasn't introduced until 3.x. Unfortunately this tends to lead to a less functional and more 'allocate once and reuse' style.

The Mono JIT also produces code which is often an order of magnitude slower than MS .net (which itself is slower than coreclr).

Despite these caveats - a significant proportion of code can be written in a purely functional style and good performance can still be achieved.

[danbolt]

That's exciting to know. I hope to give F# and Unity a try sometime soon, then!

I remember the XNA C# runtime on the Xbox 360 required similar strategies with memory as well. It's nice to see garbage collectors improve as time goes on.