7 ms·

Agreed 100%, C# is obviously a second-class citizen and I'm not going to waste my time with GDScript. It really is a shame because there are so many things to l

Agreed 100%, C# is obviously a second-class citizen and I'm not going to waste my time with GDScript. It really is a shame because there are so many things to like about Godot, but the litany of issues with C# support due to their focus on GDScript has just soured the whole thing for me. Unity is just not an option as far as I'm concerned due to their bizarre licensing fiasco (and their own mountain of technical issues). So it's Monogame/FNA for me I suppose.

cardanome 8mo ago
> I'm not going to waste my time with GDScript. The GDScript hate is so odd. If you know any scripting language you know GDScript. How much time are you wasting when it takes one afternoon to learn? And nowadays it even has gradual typing support for those that are scared of dynamic types. I have seen C# devs coming to Godot being super prejudiced against GDScript and then end up using GDScript anyway because it is just more pleasant to use.
- neonsunset 8mo ago
  [dead]
- krapp 8mo ago
  I don't hate it, but I don't like it either. Mostly because I don't like the Python-style use of significant whitespace. But functions aren't first class citizens, making closures and lambdas awkward, type hinting isn't supported everywhere (such as with callables). I could probably come up with more petty gripes if I opened up a project and played with it. "pass" is an abomination to God. It's a lot better than it used to be and it gets the job done but I still find it ugly and awkward as a language. A more general complaint I have is that Godot tries to load every script regardless of whether it's actually included in the game hierarchy.
- eatsyourtacos 8mo ago
  >for those that are scared of dynamic types. If you aren't scared of dynamic types for any type of semi-large project (like a game..) then you aren't qualified to talk about much.
  - foxygen 8mo ago
    Why?
    - BoorishBears 8mo ago
      Without agreeing (or disagreeing) with their larger point, dynamic types become more of liability as a project gets larger Like "schemaless" database applications, there's always types/schema somewhere: the choice is if they'll be explicitly defined at the place of construction, or implicitly spread out across all the places data happens to flow in your application. And the more places there are, the more spread out they'll be. Static typing is also really nice for game dev since proper unit tests are harder (but not impossible) compared to your average CRUD app.
      - cardanome 8mo ago
        The other side of the argument is that dynamic typing is great for prototyping and can allow for more compact code. The discussion is exhausting because many people don't understand the difference between weak typing and dynamic typing. You basically never want weak typing but dynamic typing has legit uses. Yes JS is both weakly and dynamically typed and that sucks but Common Lisp shows you can have very strong typing and dynamic types. Lots of very complex software has been writing in dynamically typed languages. The whole Erlang/Elixir world is dynamically typed though Elixir is getting gradual typing. There is a good reason gradual typing is getting popular, you get the best of both world. You can prototype quickly and then add types and make everything more solid later. (Which also why you want to always use a statically typed language in the corporate world because there is never a "later" and the bigger the team the more important it is to have the lang enforcing discipline. But not every programming is corporate.) People that are dogmatic about static typing show their immaturity. The older I get the more I realize that there is no right or wrong way to program, everything it tradeoffs and "it depends".
        BoorishBears 8mo ago
        Exactly which part of my comment seems dogmatic? You literally start your comment by reaffirming my point (prototyping, like when you tend to have a smaller code base?) Feels like you replied to a comment you imagined based on past interactions, not anything I actually wrote.
- TulliusCicero 8mo ago
  Still doesn't have full static typing support to my knowledge, which is a dealbreaker to me. The other things are that it just has less support for structuring your code in different ways, and of course the performance is vastly worse. My game does some state space exploration for the enemy AI, so having code that runs an order of magnitude slower just doesn't work for me.
  - cardanome 8mo ago
    It has support for typing Arrays and Dictionaries these days. Yes, nested Arrays are still a problem but I am sure they will get to it. As for performance well the GDExtension support has also gotten much better. You can always go down to C++, Rust, Nim, Zig or whatever. It is really easy to set up.
    - TulliusCicero 8mo ago
      But then I have to code in those other languages, languages that require manual memory management that I'm not as familiar with. C# is many times faster than gdscript, and I don't have to think about memory hardly at all. And it's easy enough to code the whole game in it.
      - cardanome 8mo ago
        You can use C#. It is well supported except for the (currently) missing web target and Microsoft is funding C# support so it will not get abandoned. You can also use other garbage collected languages. I once tried the Lua bindings and they worked fine. The problem with C# is that its garbadge collection is not really suited for game dev. The creator of the Mono runtime actually calls using C# his Multi-million dollar mistake and instead works on swift bindings for Godot: https://www.youtube.com/watch?v=tzt36EGKEZo https://www.youtube.com/watch?v=tzt36EGKEZo But if you really love C# nothing is stopping you. I prefer GDScript.
        TulliusCicero 8mo ago
        I know, I already use C# for Godot. My original comment was just to explain why I don't use gdscript. Swift might be cool too, I've only used it a bit but I liked what I saw.
plomme 8mo ago
I'm developing a game in Godot using C# and my experience with it is very good. I guess it depends on how deeply you integrate with Godot. I try as far as its possible to write my game headless. My opinion may change when I have gotten to the point of actually shipping a game though, so this take needs a grain of salt.
- cheeseomlit 8mo ago
  For me the real headaches emerged when I started writing [Tool] classes in C# for scripting within the editor itself. I don't know enough about the lower level nitty-gritty stuff to explain it, but I basically had to close and re-open the editor every time I recompiled. It had something to do with not being able to load assemblies, for example if I had a Tool script which referenced a sqlite library. There were also some concerning instances of Exported properties losing their saved values, though in that case they can at least be restored from previous versions of the .tscn file from version control
  - bob1029 8mo ago
    I find it amusing how Unity gets hate for domain reloading when it's this inevitable.
bj-rn 8mo ago
Did you check out Stride? https://www.stride3d.net https://www.stride3d.net

cardanome 8mo ago

> I'm not going to waste my time with GDScript. The GDScript hate is so odd. If you know any scripting language you know GDScript. How much time are you wasting when it takes one afternoon to learn? And nowadays it even has gradual typing support for those that are scared of dynamic types. I have seen C# devs coming to Godot being super prejudiced against GDScript and then end up using GDScript anyway because it is just more pleasant to use.

neonsunset 8mo ago
[dead]
krapp 8mo ago
I don't hate it, but I don't like it either. Mostly because I don't like the Python-style use of significant whitespace. But functions aren't first class citizens, making closures and lambdas awkward, type hinting isn't supported everywhere (such as with callables). I could probably come up with more petty gripes if I opened up a project and played with it. "pass" is an abomination to God. It's a lot better than it used to be and it gets the job done but I still find it ugly and awkward as a language. A more general complaint I have is that Godot tries to load every script regardless of whether it's actually included in the game hierarchy.
eatsyourtacos 8mo ago
>for those that are scared of dynamic types. If you aren't scared of dynamic types for any type of semi-large project (like a game..) then you aren't qualified to talk about much.
- foxygen 8mo ago
  Why?
  - BoorishBears 8mo ago
    Without agreeing (or disagreeing) with their larger point, dynamic types become more of liability as a project gets larger Like "schemaless" database applications, there's always types/schema somewhere: the choice is if they'll be explicitly defined at the place of construction, or implicitly spread out across all the places data happens to flow in your application. And the more places there are, the more spread out they'll be. Static typing is also really nice for game dev since proper unit tests are harder (but not impossible) compared to your average CRUD app.
    - cardanome 8mo ago
      The other side of the argument is that dynamic typing is great for prototyping and can allow for more compact code. The discussion is exhausting because many people don't understand the difference between weak typing and dynamic typing. You basically never want weak typing but dynamic typing has legit uses. Yes JS is both weakly and dynamically typed and that sucks but Common Lisp shows you can have very strong typing and dynamic types. Lots of very complex software has been writing in dynamically typed languages. The whole Erlang/Elixir world is dynamically typed though Elixir is getting gradual typing. There is a good reason gradual typing is getting popular, you get the best of both world. You can prototype quickly and then add types and make everything more solid later. (Which also why you want to always use a statically typed language in the corporate world because there is never a "later" and the bigger the team the more important it is to have the lang enforcing discipline. But not every programming is corporate.) People that are dogmatic about static typing show their immaturity. The older I get the more I realize that there is no right or wrong way to program, everything it tradeoffs and "it depends".
      - BoorishBears 8mo ago
        Exactly which part of my comment seems dogmatic? You literally start your comment by reaffirming my point (prototyping, like when you tend to have a smaller code base?) Feels like you replied to a comment you imagined based on past interactions, not anything I actually wrote.
TulliusCicero 8mo ago
Still doesn't have full static typing support to my knowledge, which is a dealbreaker to me. The other things are that it just has less support for structuring your code in different ways, and of course the performance is vastly worse. My game does some state space exploration for the enemy AI, so having code that runs an order of magnitude slower just doesn't work for me.
- cardanome 8mo ago
  It has support for typing Arrays and Dictionaries these days. Yes, nested Arrays are still a problem but I am sure they will get to it. As for performance well the GDExtension support has also gotten much better. You can always go down to C++, Rust, Nim, Zig or whatever. It is really easy to set up.
  - TulliusCicero 8mo ago
    But then I have to code in those other languages, languages that require manual memory management that I'm not as familiar with. C# is many times faster than gdscript, and I don't have to think about memory hardly at all. And it's easy enough to code the whole game in it.
    - cardanome 8mo ago
      You can use C#. It is well supported except for the (currently) missing web target and Microsoft is funding C# support so it will not get abandoned. You can also use other garbage collected languages. I once tried the Lua bindings and they worked fine. The problem with C# is that its garbadge collection is not really suited for game dev. The creator of the Mono runtime actually calls using C# his Multi-million dollar mistake and instead works on swift bindings for Godot: https://www.youtube.com/watch?v=tzt36EGKEZo https://www.youtube.com/watch?v=tzt36EGKEZo But if you really love C# nothing is stopping you. I prefer GDScript.
      - TulliusCicero 8mo ago
        I know, I already use C# for Godot. My original comment was just to explain why I don't use gdscript. Swift might be cool too, I've only used it a bit but I liked what I saw.

plomme 8mo ago

I'm developing a game in Godot using C# and my experience with it is very good. I guess it depends on how deeply you integrate with Godot. I try as far as its possible to write my game headless. My opinion may change when I have gotten to the point of actually shipping a game though, so this take needs a grain of salt.

cheeseomlit 8mo ago
For me the real headaches emerged when I started writing [Tool] classes in C# for scripting within the editor itself. I don't know enough about the lower level nitty-gritty stuff to explain it, but I basically had to close and re-open the editor every time I recompiled. It had something to do with not being able to load assemblies, for example if I had a Tool script which referenced a sqlite library. There were also some concerning instances of Exported properties losing their saved values, though in that case they can at least be restored from previous versions of the .tscn file from version control
- bob1029 8mo ago
  I find it amusing how Unity gets hate for domain reloading when it's this inevitable.

bj-rn 8mo ago

Did you check out Stride? https://www.stride3d.net https://www.stride3d.net