4 ms·

So the decision for slow interop is caused by choosing to have parity between GDScript and C# because the former forces the types to be heap-allocated...and com

So the decision for slow interop is caused by choosing to have parity between GDScript and C# because the former forces the types to be heap-allocated...and community might dislike a performance-friendly change which will break the parity in favour of C#. To be honest, if Godot embraces it becoming the Noah's Ark for Unity developers and prioritizes C# over GDScript to improve performance, it could be good both for Godot and C# ecosystems, and more emphasis on the ability to use very rich selection of libraries written for .NET would not hurt either.

xmonkee 3y ago
I've only briefly played around with Godot, but how does one get type-assisted autocomplete on variables and methods? Is there a type-hinting for the IDE? Kind of broke it for me. Maybe I should've tried C#.
- janosdebugs 3y ago
  In GDScript you kind of get code completion. Kind of. 50% of the time it doesn't give anything useful.
- jackmott42 3y ago
  If you use C# then you can use Visual Studio or Rider or VSCode and get that
  - deleted 3y ago
    [deleted]
- rsstack 3y ago
  You have to make sure you opt into the type-safe GDScript. It's not easy. There's an IDE feature that highlights lines that are not type-safe but the default color is a hard-to-see grey. I changed it to be red ("Line Number Color" is the one for untyped lines), and then fixed all typing issues. Then, autocomplete works as does cmd+click to go to definition.
- TazeTSchnitzel 3y ago
  There is optional static typing. If you write type declarations, the editor will not only give better code completion, but it will use type inference to find errors statically where possible, and the runtime will check for the remaining type errors. In this way it's more sophisticated than almost all other dynamically typed languages!
shmerl 3y ago
What about other bindings, like with Rust?
- meepmorp 3y ago
  Apparently (per the article) the C++ bindings use the same API as c# and GDScript. Presumably rust would have the same limitations, unless you wrote a whole new API just for it.
  - shmerl 3y ago
    Sounds like something they can improve then.
Dudester230602 3y ago
The history is cyclical here it seems: https://blog.unity.com/community/unityscripts-long-ride-off-into-the-sunset https://blog.unity.com/community/unityscripts-long-ride-off-...
dandellion 3y ago
I went into Godot thinking I'd hate GDScript and switch to C# pretty fast because I already knew it. Now I love GDScript, if I ever need performance I'll probably just go straight for C++.
- talloaktrees 3y ago
  I think this is correct... you can even go with Rust instead of C++
- syntheweave 3y ago
  This is the Godot way of doing it. It encourages just getting your hands dirty if you need the engine to do something very specific. The architecture is made with the understanding that you eventually want to transition from script implementations to native ones, but that you'll ship with the game being somewhere in between. And the architecture has been set up with generous amounts of glue(which is the overhead encountered in OP) to make the transition uneventful. And while it's desirable to optimize the glue and make scripting fast, that's also a much larger engineering project; Unity did it by spending big.
  - Rapzid 3y ago
    You don't need to spend big though to address the issues author highlighted. Pretty straightforward API changes. After a design is decided on just some tedious typing work. Heck, it could be dog piled easy enough.
- plopz 3y ago
  The author of the article seems to say that even the c++ api version is a heap allocated dictionary, so you would still take the perf hit
- lynzrand 3y ago
  C# strikes the balance between speed and dynamic features IMHO. Especially for games that need mod support (which is not that uncommon at all), using C# allows for the modders to easily interface with existing code, while still getting near-native performance thanks to the type system and JIT. C++ code in such case would be too rigid to be modified and hard to interface wth.
badsectoracula 3y ago
> community might dislike a performance-friendly change which will break the parity in favour of C#. The community will dislike a change that will drop GDScript, check the Godot subreddit submission (linked by the article), a ton of comments were pro-GDScript and how easy and fast (development-wise) it is to use. If that change can happen without affecting GDScript i doubt anyone would have any negative thoughts. There have been a couple of suggestions in the subreddit post on how that could happen and the Godot developers seem to be thinking about it.
- __loam 3y ago
  It is pretty shitty how people seem to be coming into Godot and immediately shitting on GDScript without trying to understand why it was built that way, and I say that as someone who shit on GDSCRIPT initially.
  - Rapzid 3y ago
    "People" will always do shitty stuff. Also, "people" will get overly defensive about challenges to their status quo and world view.. That said, how prevalent is the former vs the later really?
  - sankhao 3y ago
    How long are they supposed to spend to start appreciating it enough to tolerate 20x performance penalty to core engine functions ?
    - tourmalinetaco 3y ago
      It’s not about spending time, it’s about being ignorant of GDScript’s use cases. It’s like if people went into Python communities and shat all over it because C is faster. It’s true, but it misses the point that iterating in Python is leagues faster and is fast enough for a large section of projects.
      - jayd16 3y ago
TazeTSchnitzel 3y ago
GDScript is in a much better place than most scripting languages because the compiler actually has quite a lot of static type information. If they invest in unboxing optimisations and a JIT, it can definitely become competitive with C#.
- jayd16 3y ago
  I can't help but think this is delusional. Microsoft has put massive effort and funding into C# and I just don't see how Godot, being much more niche, can reach that level of investment.
  - TazeTSchnitzel 3y ago
    If they targeted the .NET VM they'd be able to make use of a lot of that investment. But they don't really need to. There's a lot of low-hanging-fruit for performance, and narrowing the gap is more important than outright parity.
Rapzid 3y ago
Here is a discussion from the proposal repo I found with the topic of improving C# support: https://github.com/godotengine/godot-proposals/discussions/4007 https://github.com/godotengine/godot-proposals/discussions/4... . One of the first comments was quick to point out that in a poll from back then 81% of users used GDScript primarily. They followed up with saying: > As far as I know, the only reason why Godot got C# support is because of Microsoft's grant (and of course neikeq enthusiasm ). It's my impression poking around that a lot of the community, at least at the time, had a hard time imagining that for Godot to gain serious mainstream adoption as THE OSS game engine, the project would need to focus on the what the development makeup would be at that future time and how they can attract those crowds. So, the user makeup of now may not look like the makeup of then. Further down though somebody points out: > Most people using Godot will make toy projects. That is the same for all other engines and developer tools as a whole. C# is crucial in serious projects, at least in 3D which is where I spend most of my time. Having first-class support for it (both in terms of tutorials in the documentation as well as in the engine) will go a long way towards making better-performing games for developers making serious projects. This post has been timely as I've been checking out Godot going through a massive 12 hour tutorial but using C# instead of GDScript; because of course. The entire time my mind kept wandering back to this quote I've seen posted various places: > C# is faster, but requires some expensive marshalling when talking to Godot. I kept thinking "but why?! C# has excellent interop support and should be able to map directly over Godot's types. That seems like it's going to be a serious limitation long term..". EDIT: That said, I'm very impressed with Godot in general and a lot of the C# integration. They are making pretty good use of source generators making a lot of string magic replaceable with type-checked property accesses. Signal creation and exporting properties to Editor members works this way; cool! I think they will end up working through the worst of these interop perf issues.
- trinovantes 3y ago
  That poll seems highly biased How many people have tried godot/gdscript, hated it, and never came back? They're not the people who are answering the survey
  - Rapzid 3y ago

xmonkee 3y ago

I've only briefly played around with Godot, but how does one get type-assisted autocomplete on variables and methods? Is there a type-hinting for the IDE? Kind of broke it for me. Maybe I should've tried C#.

janosdebugs 3y ago
In GDScript you kind of get code completion. Kind of. 50% of the time it doesn't give anything useful.
jackmott42 3y ago
If you use C# then you can use Visual Studio or Rider or VSCode and get that
- deleted 3y ago
  [deleted]
rsstack 3y ago
You have to make sure you opt into the type-safe GDScript. It's not easy. There's an IDE feature that highlights lines that are not type-safe but the default color is a hard-to-see grey. I changed it to be red ("Line Number Color" is the one for untyped lines), and then fixed all typing issues. Then, autocomplete works as does cmd+click to go to definition.
TazeTSchnitzel 3y ago
There is optional static typing. If you write type declarations, the editor will not only give better code completion, but it will use type inference to find errors statically where possible, and the runtime will check for the remaining type errors. In this way it's more sophisticated than almost all other dynamically typed languages!

shmerl 3y ago

What about other bindings, like with Rust?

meepmorp 3y ago
Apparently (per the article) the C++ bindings use the same API as c# and GDScript. Presumably rust would have the same limitations, unless you wrote a whole new API just for it.
- shmerl 3y ago
  Sounds like something they can improve then.

Dudester230602 3y ago

The history is cyclical here it seems: https://blog.unity.com/community/unityscripts-long-ride-off-into-the-sunset https://blog.unity.com/community/unityscripts-long-ride-off-...

dandellion 3y ago

I went into Godot thinking I'd hate GDScript and switch to C# pretty fast because I already knew it. Now I love GDScript, if I ever need performance I'll probably just go straight for C++.

talloaktrees 3y ago
I think this is correct... you can even go with Rust instead of C++
syntheweave 3y ago
This is the Godot way of doing it. It encourages just getting your hands dirty if you need the engine to do something very specific. The architecture is made with the understanding that you eventually want to transition from script implementations to native ones, but that you'll ship with the game being somewhere in between. And the architecture has been set up with generous amounts of glue(which is the overhead encountered in OP) to make the transition uneventful. And while it's desirable to optimize the glue and make scripting fast, that's also a much larger engineering project; Unity did it by spending big.
- Rapzid 3y ago
  You don't need to spend big though to address the issues author highlighted. Pretty straightforward API changes. After a design is decided on just some tedious typing work. Heck, it could be dog piled easy enough.
plopz 3y ago
The author of the article seems to say that even the c++ api version is a heap allocated dictionary, so you would still take the perf hit
lynzrand 3y ago
C# strikes the balance between speed and dynamic features IMHO. Especially for games that need mod support (which is not that uncommon at all), using C# allows for the modders to easily interface with existing code, while still getting near-native performance thanks to the type system and JIT. C++ code in such case would be too rigid to be modified and hard to interface wth.

badsectoracula 3y ago

> community might dislike a performance-friendly change which will break the parity in favour of C#. The community will dislike a change that will drop GDScript, check the Godot subreddit submission (linked by the article), a ton of comments were pro-GDScript and how easy and fast (development-wise) it is to use. If that change can happen without affecting GDScript i doubt anyone would have any negative thoughts. There have been a couple of suggestions in the subreddit post on how that could happen and the Godot developers seem to be thinking about it.

__loam 3y ago
It is pretty shitty how people seem to be coming into Godot and immediately shitting on GDScript without trying to understand why it was built that way, and I say that as someone who shit on GDSCRIPT initially.
- Rapzid 3y ago
  "People" will always do shitty stuff. Also, "people" will get overly defensive about challenges to their status quo and world view.. That said, how prevalent is the former vs the later really?
- sankhao 3y ago
  How long are they supposed to spend to start appreciating it enough to tolerate 20x performance penalty to core engine functions ?
  - tourmalinetaco 3y ago
    It’s not about spending time, it’s about being ignorant of GDScript’s use cases. It’s like if people went into Python communities and shat all over it because C is faster. It’s true, but it misses the point that iterating in Python is leagues faster and is fast enough for a large section of projects.
    - jayd16 3y ago

TazeTSchnitzel 3y ago

GDScript is in a much better place than most scripting languages because the compiler actually has quite a lot of static type information. If they invest in unboxing optimisations and a JIT, it can definitely become competitive with C#.

jayd16 3y ago
I can't help but think this is delusional. Microsoft has put massive effort and funding into C# and I just don't see how Godot, being much more niche, can reach that level of investment.
- TazeTSchnitzel 3y ago
  If they targeted the .NET VM they'd be able to make use of a lot of that investment. But they don't really need to. There's a lot of low-hanging-fruit for performance, and narrowing the gap is more important than outright parity.

Rapzid 3y ago

Here is a discussion from the proposal repo I found with the topic of improving C# support: https://github.com/godotengine/godot-proposals/discussions/4007 https://github.com/godotengine/godot-proposals/discussions/4... . One of the first comments was quick to point out that in a poll from back then 81% of users used GDScript primarily. They followed up with saying: > As far as I know, the only reason why Godot got C# support is because of Microsoft's grant (and of course neikeq enthusiasm ). It's my impression poking around that a lot of the community, at least at the time, had a hard time imagining that for Godot to gain serious mainstream adoption as THE OSS game engine, the project would need to focus on the what the development makeup would be at that future time and how they can attract those crowds. So, the user makeup of now may not look like the makeup of then. Further down though somebody points out: > Most people using Godot will make toy projects. That is the same for all other engines and developer tools as a whole. C# is crucial in serious projects, at least in 3D which is where I spend most of my time. Having first-class support for it (both in terms of tutorials in the documentation as well as in the engine) will go a long way towards making better-performing games for developers making serious projects. This post has been timely as I've been checking out Godot going through a massive 12 hour tutorial but using C# instead of GDScript; because of course. The entire time my mind kept wandering back to this quote I've seen posted various places: > C# is faster, but requires some expensive marshalling when talking to Godot. I kept thinking "but why?! C# has excellent interop support and should be able to map directly over Godot's types. That seems like it's going to be a serious limitation long term..". EDIT: That said, I'm very impressed with Godot in general and a lot of the C# integration. They are making pretty good use of source generators making a lot of string magic replaceable with type-checked property accesses. Signal creation and exporting properties to Editor members works this way; cool! I think they will end up working through the worst of these interop perf issues.

trinovantes 3y ago
That poll seems highly biased How many people have tried godot/gdscript, hated it, and never came back? They're not the people who are answering the survey
- Rapzid 3y ago