5 ms·

I've been getting into F#, specifically for Monogame & Unity, and Scott's website, blog, and videos have been incredibly helpful in introducing F# and highlight

I've been getting into F#, specifically for Monogame & Unity, and Scott's website, blog, and videos have been incredibly helpful in introducing F# and highlighting the strengths of the language. I currently only use F# for fun and games. I hope to use it for an upcoming project however.

pc86 10y ago
I hear it's particularly good for unit tests depending on the domain. I have a coworker who regularly writes his production code in C# and unit tests in F#. He says it's faster but I don't know enough F# to be able to say if that's true or if he just likes using both languages :)
- kemiller2002 10y ago
  Faster in what? They both compile to IL code, and there execution speed is relatively the same, C# has it beat on somethings F# wins in others. Development wise, once you get used to it, I find it much faster. I have to write less code, and it's generally more correct the first time due to the rules it enforces.
  - pc86 10y ago
    I meant faster to actually program the tests, as you alluded to.
  - markatkinson 10y ago
    I was about to mention perhaps they mean faster to write, and also conceptualise, but you nailed it. I find with F# that sure you are writing less actual code, like 1000 characters instead of 2000, but for me the biggest gains from using/thinking in a functional paradigm, and having access to functional tools is in the process of actually tackling problems. The conceptualisation, execution and testing of solutions for these problems for me has been less onerous and more enjoyable with F# than using C#.
20yrs_no_equity 10y ago
What are the limitations of using F# with Unity? Do you have full access to the Unity APIs? Can you write F# scripts and have them run in WebGL or iOS deployment targets? How does it work? F# might just be the thing I'm looking for. And I love the idea of functional programming in unity.
- deleted 10y ago
  [deleted]
- benrjackson 10y ago
  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 10y ago
    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 10y ago
      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.

pc86 10y ago

I hear it's particularly good for unit tests depending on the domain. I have a coworker who regularly writes his production code in C# and unit tests in F#. He says it's faster but I don't know enough F# to be able to say if that's true or if he just likes using both languages :)

kemiller2002 10y ago
Faster in what? They both compile to IL code, and there execution speed is relatively the same, C# has it beat on somethings F# wins in others. Development wise, once you get used to it, I find it much faster. I have to write less code, and it's generally more correct the first time due to the rules it enforces.
- pc86 10y ago
  I meant faster to actually program the tests, as you alluded to.
- markatkinson 10y ago
  I was about to mention perhaps they mean faster to write, and also conceptualise, but you nailed it. I find with F# that sure you are writing less actual code, like 1000 characters instead of 2000, but for me the biggest gains from using/thinking in a functional paradigm, and having access to functional tools is in the process of actually tackling problems. The conceptualisation, execution and testing of solutions for these problems for me has been less onerous and more enjoyable with F# than using C#.

20yrs_no_equity 10y ago

What are the limitations of using F# with Unity? Do you have full access to the Unity APIs? Can you write F# scripts and have them run in WebGL or iOS deployment targets? How does it work? F# might just be the thing I'm looking for. And I love the idea of functional programming in unity.

deleted 10y ago
[deleted]
benrjackson 10y ago
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 10y ago
  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 10y ago
    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.