Search Unity

F# scripting in Unity

Discussion in 'General Discussion' started by Kiou-23, Feb 5, 2019.

?

Would it be a good thing for Unity to adopt a functional programming language such as F#

  1. yes

    65 vote(s)
    58.0%
  2. no

    36 vote(s)
    32.1%
  3. what is F#

    11 vote(s)
    9.8%
  1. jyfc

    jyfc

    Joined:
    Feb 19, 2016
    Posts:
    10
    I presented the OO in F# bit as an interoperability option, in practice I imagine mainly data processing funcs, not OOP, in F#, and these functions are called in C#. They're not being interchanged, but you are using their strengths appropriately with something like this.

    Of course, you can use however much C# and F# as you want.

    F#/C# interop is pretty common and supported if you google it. I'm not sure what you mean when you say it's weird. Is there something I'm missing?
     
    GameDevCouple likes this.
  2. Antypodish

    Antypodish

    Joined:
    Apr 29, 2014
    Posts:
    7,237
  3. GameDevCouple

    GameDevCouple

    Joined:
    Oct 5, 2013
    Posts:
    2,427
    Actually If you check I had already edited the bit about C# < > F# usage out as its not really a bad or good thing. The rest of my points still stand :)

    That said, most of us that have used unity for a number of years remember the boo and unityscript days. There are good reasons why we are trying to have a single language instead of fracturing across multiple. It adds a ton of overhead to everything for unity themselves, especially documentation.

    In general, while F# is nice for a really small subset of people, it just doesnt warrant the amount of overhead to implement and maintain it. I am not seeing anything in this thread that counteracts that point, and that point has been the same since it was first suggested a number of years ago.

    So really if you want F#, better to start coming up with some hard evidence based reasons as to why it would be more beneficial than detrimental to add it other than the fact that you and some other users like it etc etc.

    Note I have nothing against F# and actually quite enjoy the language, but that doesnt mean I think it has a place in unity because it really doesnt. We need less fracturing of the community and teams working on it , not more. Things were a mess back in the day of 3 supported languages and have gotten miles better since then. I for one dont want to go back to that.
     
    vakabaka likes this.
  4. vakabaka

    vakabaka

    Joined:
    Jul 21, 2014
    Posts:
    1,153
    Yes, I can remember how awful that was, as i have started to learn Unity and there were different languages. One simple ask, how to do something and many answers in different languages.
    Lol, and this is the point, why i am trying to speak English here and not Russian or German. It is just better to have one language. :rolleyes: Ok, i am not against F# (never read about it) but then the F# should be the only one language in the Unity.
     
    GameDevCouple and Antypodish like this.
  5. Ryiah

    Ryiah

    Joined:
    Oct 11, 2012
    Posts:
    15,310
    Unite Copenhagen had multiple talks covering multiple aspects of Unity DOTS. Early on in the talk covering the Unity Burst compiler he shows a demonstration of code running through the normal C# compiler and taking approximately 9ms to execute, and then he shows the same exact code running through Unity Burst (a custom C# compiler) and taking 4ms.

    I have read a few of the articles concerning general performance between C# and F#, and while there are wins on both sides none of them are anywhere near what Unity's Burst compiler is capable of. By the way the difference above is from just one part of Unity DOTS in action. He doesn't use ECS or the Unity Job System.

    Which means that the 22.5x performance increase is not only single-threaded (due to not using the Job System) but isn't taking full advantage of memory and cache bandwdith (due to not using ECS). For any alternative languages to have any chance of being picked up they would have to be able to achieve this with just their compilers.

     
    Last edited: Oct 23, 2019
    GameDevCouple likes this.
  6. joshcamas

    joshcamas

    Joined:
    Jun 16, 2017
    Posts:
    984
    As a programmer this triggers me XD. I think programming is here to stay for most games that have any future. Plus ECS is still programming, just a different structure than OOP
     
    Last edited: Oct 24, 2019
  7. Antypodish

    Antypodish

    Joined:
    Apr 29, 2014
    Posts:
    7,237
    Hipo didn't say there wont be any programming. But made point is, lot of process will be automated. Is now already anyway, to certain extent.
     
    hippocoder and GameDevCouple like this.
  8. GameDevCouple

    GameDevCouple

    Joined:
    Oct 5, 2013
    Posts:
    2,427
    Unfortunately I have to agree with hippo, a lot of stuff will become offloaded to graphs as time goes on.

    I am not saying that programming will disappear, but rather a lot of boilerplate will be set up using node graphs instead and then programmers can hand edit this.

    I dont think its anything to feel threatened by as a programmer, it gives you more power not less. Instead of doing all the boilerplate and functionality and optimisation, you will allow the designers to do the boilerplate and get a prototype working, and our jobs will shift to focusing on making it robust, scalable and optimised. In short, more time to do the things that are more "programmer-y" instead of faffing around setting up things in the scene, inspector and writing prototypes before getting to the meaty stuff.

    Its the same with all the shadergraph malarky. Right now even though I prefer to write code by hand, a lot of the time I will author a quick graph in shadergraph as a "sketch" and then open up the generated c# and use that as a base. It saves me writing all the standard shader boilerplate I normally would, and stops me getting bogged down with all the macro nonsense and "where did they move this HLSL to now?!".

    Dont worry, programming isnt going anywhere in the unity context of things, moreover I dont ever see writing code being completely overshadowed by graphs and I dont think @hippocoder meant that either, more that the things that make sense for graphs will be done by graph instead of code. We all write code every day that has bits that would make more sense layed out visually, while there are other bits we write that would be a mess visually no matter how you organised it.

    Its just another tool for your toolbox :) I doubt an engineer would get worried about a fancy new wrench that cuts out a lot of manual work that was done before, and neither should we ;)
     
    Last edited: Oct 24, 2019
    hippocoder, vakabaka and Antypodish like this.
  9. iamthwee

    iamthwee

    Joined:
    Nov 27, 2015
    Posts:
    2,158
    #bringBackBoo
     
  10. hippocoder

    hippocoder

    Digital Ape Moderator

    Joined:
    Apr 11, 2010
    Posts:
    26,438
    People can be as triggered or upset as they like, it's the same as standing in front of a tsunami and shouting "no! I don't like you!" for all the good it will have.

    Unity allows shader graphs to be node based, but at any point you can just throw a function node in and code stuff right there, in the graph.

    As for it being applied to CPU code, performance and so on.. have you seen the garbage people are coding on these forums? Endless bugs, it's pure swill. These people with their 0 released games think they're really hot stuff but the fact is graphs will save them, from themselves.

    We're not there yet and it will take a few years before the balance of performance, code and graphing comes together, but it will, and there aren't any drawbacks. Solving 99% of user needs is more important than never having it.

    Only an idiot thinks that's bad.
     
  11. GameDevCouple

    GameDevCouple

    Joined:
    Oct 5, 2013
    Posts:
    2,427
    Also, having messed with the DOTs visual scripting ealier today, I can say with some confidence that it will also save you from API changes!
     
  12. joshcamas

    joshcamas

    Joined:
    Jun 16, 2017
    Posts:
    984
    I see it as watching people hallucinating a tsunami ;)

    I super agree that most game's shader code will be replaced with graphs, I wasn't talking about shader graph, sorry! But the visual scripting end. The meat of the game. I really doubt that many sizable games will be built with the visual scripting at the core. I really really really doubt it. UE4 has had blueprints for a long time, and very very few games that actually release are pure or even close to pure blueprints. The biggest issue is simply how much code a game requires: graphs just don't scale that large. But that's okay, since that's not what graphs are for! Graphs aren't designed to replace coding, it's meant to enhance its weaknesses, aka prototyping (especially for artists), as well as higher level logic such as tools for level designers, writers, and quest designers to use. I personally am very excited about the latter.
     
    hippocoder likes this.
  13. Ryiah

    Ryiah

    Joined:
    Oct 11, 2012
    Posts:
    15,310
    Blueprints are meant to be an alternative to normal coding, but normal coding was never that difficult to begin with. What is difficult will be DOTS for people that are only just barely able to write normal code which just so happens to be the majority of Unity's audience.
     
  14. joshcamas

    joshcamas

    Joined:
    Jun 16, 2017
    Posts:
    984
    Maybe I missed something, is DOTS harder to write?
     
  15. Ryiah

    Ryiah

    Joined:
    Oct 11, 2012
    Posts:
    15,310
    Yes and no. I fully expect most programmers to pick it up without too much trouble, but everyone else will be a different story because it requires approaching the code with a completely different mindset. OOP is a paradigm intended to model the real world but you're no longer using OOP with DOTS.

    Additionally, to take full advantage of Units DOTS, you need to be able to write multi-threaded code as well as code within the limited subset of C# features that is supported by Burst. Both of these I believe will be as rough for non-programmers as writing ECS code.

    Below is a link to the Unite Copenhagen video covering converting your game to DOTS, and when he asked questions about how to approach DOTS in the beginning a good number of people were getting them wrong.

     
    hippocoder likes this.
  16. joshcamas

    joshcamas

    Joined:
    Jun 16, 2017
    Posts:
    984
    Interesting, that makes sense, OOP is pretty easy to explain to anyone. I wonder if we'll figure out better ways to explain ECS as times goes on, that would be nice : )
     
  17. iamthwee

    iamthwee

    Joined:
    Nov 27, 2015
    Posts:
    2,158
    Anything that is multi-threaded in general is harder to write just purely from an abstract level.

    When I was using nodejs, understanding the concurrency paradigm took a long time.

    IMO the hard part isn't making it multi-threaded / concurrent, it is figuring how to pass that data back to the requisite methods / functions once it has finished its task.

    Or as someone once put it.

    "Synchronous programming is like a waiter taking an order going to the kitchen, and then waiting for the chef to make the dish then return it to the customer. It's a blocking operation. The waiter can't take another order until the first dish has been made and served.

    Asynchronous programming is like a waiter taking an order going to the kitchen, then going back to the restaurant to take more orders. The hard part is knowing when the chef has finished making each dish and distributing it to the customers."
     
    Last edited: Oct 24, 2019
  18. iamthwee

    iamthwee

    Joined:
    Nov 27, 2015
    Posts:
    2,158
    If you had said spaghetti tsunami I would have liked your post :D
     
    joshcamas likes this.
  19. angrypenguin

    angrypenguin

    Joined:
    Dec 29, 2011
    Posts:
    12,470
    But that's beside the point. The fact that Blueprints are there as a core system saves a bunch of people a bunch of work, and that matters far more than whether or not it's "pure" or other things are used as well.
     
  20. GameDevCouple

    GameDevCouple

    Joined:
    Oct 5, 2013
    Posts:
    2,427
    @Ryiah thank you kindly for linking that. I am not sure how but I managed to watch every other video from that Unite EXCEPT that one, and it really was a goldmine of info regarding DOTS. I really really like how they explained using DOTS from an applied perspective in a real world scenario, as it sometimes gets troublesome working out what should and shouldnt be DOTS. I am feeling much more empowered now to give a go at converting some of my heavier systems to DOTS in my current game, without feeling bad that some of it will still be using monobehaviours etc. Huzzah!
     
  21. iamthwee

    iamthwee

    Joined:
    Nov 27, 2015
    Posts:
    2,158
    I thought this was a super quick and interesting intro.



    Although I find the idea of indie devs using massive instances of Game objects oxymoronic IMO.
     
  22. Murgilod

    Murgilod

    Joined:
    Nov 12, 2013
    Posts:
    6,758
    You should take a look around some of the game projects you can find just by browsing github. A lot of indie devs use loads of gameobjects for everything.
     
    Last edited: Oct 26, 2019
    Ryiah likes this.
  23. AndersMalmgren

    AndersMalmgren

    Joined:
    Aug 31, 2014
    Posts:
    5,406
    The cost of GameObjects without components has negligible cost. It's when you start to add components and more so conponents with collision and update methods that you start to see performance hits.
     
  24. Murgilod

    Murgilod

    Joined:
    Nov 12, 2013
    Posts:
    6,758
    I'm not sure how to tell you this but uh

    most people aren't just slapping empty gameobjects in the scene
     
    joshcamas likes this.
  25. AndersMalmgren

    AndersMalmgren

    Joined:
    Aug 31, 2014
    Posts:
    5,406
    I do all the time from categorize my scene to configure hand to object rigs.

    Also you can use native unity stuff without conponents, like mesh renderers and the like.
     
  26. Murgilod

    Murgilod

    Joined:
    Nov 12, 2013
    Posts:
    6,758
    Traversing the stack and even excessive use of child components has a performance effect.

    Also a mesh renderer is a component.
     
  27. AndersMalmgren

    AndersMalmgren

    Joined:
    Aug 31, 2014
    Posts:
    5,406
    Yes but it's a native component it does not need to pinvoke. You can have thousands of GameObjects in a scene as long as you don't have managed conponents on each and everyone of them that does method calls every frame.

    Unity uses quadtrees and similar to remove those objects that are not relevant. Here is a scene from our game that contains several thousands gameobjects.



    The problem is in batching and drawcalls not gameobjects
     
  28. Murgilod

    Murgilod

    Joined:
    Nov 12, 2013
    Posts:
    6,758
    What, exactly, are you even trying to argue here?
     
  29. iamthwee

    iamthwee

    Joined:
    Nov 27, 2015
    Posts:
    2,158
    Unity DOTS


     
  30. jam40jeff

    jam40jeff

    Joined:
    Dec 29, 2019
    Posts:
    1
    C# has been slowly but surely gaining features from F#, and the trajectory of this shift has been getting faster. Unfortunately, the C# syntax for these features is often much less readable than the corresponding F# syntax.

    https://www.calvinallen.net/csharp-8-is-old-news-onward-to-csharp-9/

    Although the author doesn't point it out, features 2 through 5 are directly ripped from F#.

    Even for OOP, often times F# makes things easier than C#, especially with implicit generics and the ability to partially specify a generic type (for example Dictionary<string, _>, where the _ will be inferred.). This makes calling methods with multiple generic parameters where only one of them needs to be specified as you can just fill in the rest with _, whereas in C# you have to specify all of them or none of them (if all can be inferred.)

    I have been using C# since it was released, and F# as well for a while now. I do believe that F# is objectively a better language for most applications. That being said, if Unity does not want to support more than one language officially, it would makes zero sense to switch away from C# at this point. As far as the possibility of supporting both, I know this was a problem in the past when 3 languages were supported, but I wonder if the fact that both C# and F# are .NET languages which interop fairly well would mean that it could be more feasible.
     
    Last edited: Dec 29, 2019
  31. r618

    r618

    Joined:
    Jan 19, 2009
    Posts:
    868
    they've scrapped the effort completely for now, it was highest voted feedback item one time btw
    after superpig & co. had a look at it it got removed ]
    I believe one of the, or main reason, was not entirely straightforward transition to ECS and support compared to C# (and maybe slightly different build system)
     
  32. Murgilod

    Murgilod

    Joined:
    Nov 12, 2013
    Posts:
    6,758
    The highest voted feedback for ages was a new terrain system and it was like that for 8+ years. Maybe it was the highest voted in the recently voted, but nah. Also, just because it was high voted doesn't mean it was really under anything past "vague consideration." Feedback was never really a regularly used thing.
     
  33. r618

    r618

    Joined:
    Jan 19, 2009
    Posts:
    868
    it indeed was nearing the end and I think terrain state changed

    it wasn't under *any* consideration until somebody from UT actually looked it and decided it's worth to be removed completely - as with the whole feedback domain after all
     
  34. pat205

    pat205

    Joined:
    Jan 24, 2020
    Posts:
    2
    It would be nice to have F# in Unity. I'm Scala Developer with C# background and what I can add to this discussion is that functional languages like Clojure, Scala/F# are basically syntactic sugar for Java/C# that facilitates functional-style programming. Both F# and C# have the same runtime it is just all about the fact that F# has concise syntax and supports some abstractions that it is much longer to write them in C#. Hence the runtime is the same adding it to Unity should be straightforward. Probably F# works similar to Scala - function after compilation is nothing more than a class with the apply method.

    What hasn't been said in the discussion is that OOP was invented to make it easier to work in teams. You can design a system "by drawing objects on a board", thinking about how they change and discussing with your colleagues, invent some design patterns and draw UML diagrams so everyone in the team can understand them. We think in categories of objects so it is a very "mind friendly" model. FP, on the other hand, has one design pattern: functions and its foundations in math that scares some people. You write functions, apply functions and basically that's it. Functions don't change. Some people have a problem with decomposing problems and writing it in terms of small functions. In C# you could write FP programs the just by creating class per method, using a lot of lambdas and overusing static, final keywords - yet that would create a lot of unnecessary lines of code because of its syntax. Because of the abovementioned teamwork side of OOP - it absolutely dominated marked. Why struggle with the mental burden of functional programming when you can hire 10 developers that will eventually find the way. The fact that is is being used by academia is only because it is considered smarter, FP is older (they need to teach a little bit of history...) plus as a researcher, you usually work alone or small teams of smart people so they pick the tool that makes them most productive (usually).

    About performance, FP is not the most performant way due to the fact that immutability enforces a lot of copying of data structures - it is sometimes "cheaper" to just mutate some variable than copy whole object with the updated field. As trade-off immutability makes it completely safe to do high performant parallel computing and you never have any problems with nulls because once you declare it is initialized and it will never become null. Moreover, Scala and F# aren't purely functional languages so in case of performance issues you can always optimize and use a mutable state. For FP programmers it's kind of disgusting but sometimes such optimization can really have a powerful impact. Functional languages are performant in a different way - the speed of writing code, because code is shorter, less to read, less to write, declarative nature makes it easier reason about and you are free of most of the bugs that C# developers will make.

    In my opinion, OOP might be better suited for game dev - games have a lot of objects that change a lot - think for example about a change of 3D position over time for 1000 objects. F# code for something like this woudn't look nic.e Yet it would be nice to have in Unity alongside its brother C# because there are some usages when F# can shine like event-based stuff, parallel processing, machine learning, some async tasks/jobs, and UI. They have full interop, same runtime. Now we don't have any choice but I hope that one day we will have it and Unity will be the game engine that supports both C# and F#.

    One last thing that I had no idea to which paragraph to add:
    FP is much easier to test because of its purity and avoidance of side effects. Yet from my experience, C# developers and Unity ones especially aren't exactly the type of developer who cares and writes a lot of unit tests.
     
  35. koirat

    koirat

    Joined:
    Jul 7, 2012
    Posts:
    191
    I vote against any request for unity team that is not a bug fix or delivery of promised (long ago) feature.
     
    joshcamas likes this.
  36. pat205

    pat205

    Joined:
    Jan 24, 2020
    Posts:
    2
    If logic is not convincing anyone - maybe greed will do. F# is one of the top-paying technologies. If we could use it in unity to solve non-trivial problems (a lot of stuff in games is related to maths & physics) we would learn it well and we could earn more.

    upload_2020-2-15_15-23-5.png
     
  37. Murgilod

    Murgilod

    Joined:
    Nov 12, 2013
    Posts:
    6,758
    Logic isn't convincing people because there isn't any, and greed isn't going to convince anyone in this case because there isn't any in that argument either. By that logic, Unity should use Clojure. F# brings nothing to the table worth the tech and monetary expense of adding a second language to Unity.
     
  38. Antypodish

    Antypodish

    Joined:
    Apr 29, 2014
    Posts:
    7,237
    Logic says, if everyone using C#, would switch to conjure, or F#, or any other arbitrary language, weight of payments would shift opposite way round. C# would then become higher paid opportunities due to demand.

    Question is, how many really opportunities is there, for any arbitrary language. If let's say only 5 jobs for F# or conjure, or else, then is no worth really risk or effort. Unless person can gurantee high competitive quality, to offer.
     
  39. hippocoder

    hippocoder

    Digital Ape Moderator

    Joined:
    Apr 11, 2010
    Posts:
    26,438
    The graph above says top paying. It doesn't say it's a numerical superiority. Top paying for a handful of people is probably the worst business decision in the world for a company seeking mass adoption.

    C# is a natural step from C, then C++. It's also heavily pushed by Microsoft, trivial to understand and so on.

    As Unity has built Unity 2.0 (DOTS) on top of C#, any other language is not going to happen. Plus it is not difficult for any professional to switch languages.

    Graphs which state language xyz is the place to be have no bearing at all on this particular industry. I mean, for AI you're not going to suddenly see F# winning. You're going to see Python winning.

    In game dev, C++ has the biggest hold ever, and this trickles down to C# fairly easily. I don't think F# is going to be a thing for Unity, even if all the stats said it should be.

    Node stuff is the most inclusive and wide-reaching. Providing one can dip in and code a custom node from time to time, I'm not seeing why it wouldn't be the dominant way to develop rich media apps.
     
    Ryiah likes this.
  40. r618

    r618

    Joined:
    Jan 19, 2009
    Posts:
    868
    I agree with everything you wrote (except C# doesn't have final keyword ,) - in theory; in practice:

    F# syntax is almost ideal for typical DOTS usage - that is transformations of linear immutable structures - but this: 'FP is not the most performant way due to the fact that immutability enforces a lot of copying of data' is _pretty_ important here
    I think burst operates on IL, but e.g. F#'s different im/mutability memory model probably makes it hard to directly support the language, involves different tooling and build system, and separate support in burst compared to existing and evolving C# one

    Despite looking like 'this should be easy to add' in practice might require non trivial effort since the assumptions burst makes in order to emit the most optimal code are not easily transferable I guess
    So it's not feasible right now, due to practical reasons

    / btw newer C# language versions adopt many features from F# directly, though at the price of more verbose syntax no doubt ), but it's at least something right /
     
  41. neginfinity

    neginfinity

    Joined:
    Jan 27, 2013
    Posts:
    7,097
    "Top paying" might indicate that there is a very small number of people that actually use the language. Small number of specialists calls for higher salaries.

    Honestly I'd prefer C++ bindings over F#.
     
    MNNoxMortem likes this.
  42. MNNoxMortem

    MNNoxMortem

    Joined:
    Sep 11, 2016
    Posts:
    455
    I actually believe we are moving back to COBOL. It's just very subtle and not so easily noticeable.
     
unityunity