Mono is an open source implementation of Microsoft’s .NET Framework
Mono uses C# and other .Net languages as well
Unity still uses the mono run-time, so i don’t understand when you say Unity transitioned from Mono to C#, please explain.
On the Godot side of things i hope GDScript will be always the Godot scripting language of choice, I really like GDScript and the internal editor.
Unity once had a proprietary language called “UnityScript”. Unity also once supported a language called Boo (https://boo-language.github.io/). You can read a bit about Unity’s support (and deprecation) of both here: UnityScript’s long ride off into the sunset | Unity Blog
Anyway, just as a data point, my team migrate away from Unity, and we are quite excited to NOT use C#. As convenient as C# is in many ways, we often found ourselves fighting the garbage collector and dealing with annoying memory allocation quirks.
Our intention in Godot is to write code in C++ (using GDExtension or direct engine modification), and treat GDScript as the engine’s scripting language (which, you know…it is).
I dislike dynamic typing but gameplay development is quick iteration; making and dropping things as fast as possible, game-specific editor tools, fast compiling and hot-reloading. Strictness gets in the way.
Performance is directly related to memory management and processing. You will need languages with low-level and strict memory management for this. C++ was made so easy to use with Godot that it doesn’t make sense to use C# if your goal is really performance. I would use Rust as alternative to C++ for more syntax sugar and modern features.
I like C# features yet I go with GDScript for 90% of the game, gameplay, and editor tools and C++ for data-oriented systems such as procedural generation, simulation, and anything like the engine’s low-level work. Would mix in C# too since languages are just modules, but honestly the only use case is to use .NET libs.
you know if you dislike dynamic typing, you can just cast variables with type…I mean, not sure why this is an issue. It’s not like dynamic typing is mandatory.
I’m not sure what you mean dynamic typing is not mandatory. It’s not like GDScript was designed for types. Types are a second-class feature in any dynamic language.
Dynamic typing is mandatory when you want contract-like functions because we use strings and duck typing to simulate interfaces. It is also mandatory in many API methods that use strings as type hints, dictionaries as structs, and Variants. It is required if you don’t want conflicts in the global namespace because we can’t define type aliases so we preload scripts without giving them class names. Also to avoid parser errors such as references to editor class because their types are removed when you export a project but there is no feature to remove snippets of editor code as we would do with C++/C# preprocessors.
There are many other cases you can run at because GDScript and the API were designed around reflection, not types. However, as I pointed out, the dynamic nature is ideal for faster iteration and there is no need to change it. I just don’t like coding anything besides gameplay or small-scope tools with it.
Oh well, I agree with this about 99%…I don’t like using GDScript for things covered under the System.IO, Collections, and Collections.Generic names spaces. C# or C++ are far better choices if your collections of any significant size. But for methods and properties that access the GD space, I wouldn’t use anything except GDscript.
My personal chain of thought:
- Use
GDScript
. - Identified a bottleneck? Use the profiler to find the problem.
- Is it a language problem? Use
GDExtension
.
I can use GDExtension
with Rust
(my main language), as well as C++
and Go
.
And yeah, I’d rather use any of the above over C#
(even if C#
is better integrated).
Just because someone likes C# so much because of a .NET bloated Unity doesn’t mean we all have to be forced into it. I prefer the lean and mean Gdscript. It integrates beautifully, more readable, and is more efficient than C#, because the underlying code is C++ anyway. Don’t make the mistake of following MS and .net into bloatware.
I prefer C# because I prefer object-oriented paradigms over more linear approaches. I find it to be cleaner and more maintainable, and consequently more “fun” in the long run (bigger games with longer development cycles). GDScript, to me, feels more like the BASIC programs I grew up writing. They were quick, fun, and encouraged dubious programming practices. I’m not going to say people shouldn’t use it, just that it isn’t for me.
Having said that, I love the idea that Godot has multiple options. C#, C++ and similar languages are more likely to prevent beginners and hobbyists from learning the craft than to draw them into it. I was already a professional developer when I made my first game 20 years ago, but I probably wouldn’t have bothered if GameMaker hadn’t been so user-friendly at the time.
I also like the idea that I can write some quick and dirty code in GDScript just to make sure my nodes/animations/etc. are set up correctly before dealing with the maintenance of setting up a C# hierarchy.
So I hope the parallel language options remain a thing. I believe it is not only a strength, but it is something that sets Godot apart.
I prefer C# because I prefer object-oriented paradigms over more linear approaches.
GDScript is object oriented.
Yes, but not to the extent C# is.
C# has more quality of life features, but you were implying that you didn’t like GDScript because you thought it wasn’t OOP.
I wasn’t implying that it wasn’t OOP. I said that it doesn’t emphasize OOP paradigms the way C# does.
Honestly, gdscript seems easy to pickup for someone used to C# anyways. Just focus on making things well organized and readable. Keep things simple and don’t overcomplicate things.
Just a little note on this: GDExtension is notably slower than C#/.NET 8, especially godot-rust. The FFI layer is a real turtle there, taking almost 8x longer for any engine API call compared to C#. The current Godot 4 C# implementation is quite special and even faster than C++ GDExtensions for API calls. I learned that the hard way mid-production.
For general data processing, C++, Rust and C# are about the same speed, so this only matters if you are planning to write actual gameplay code or if you need to pass a lot of data around between the engine and your extension.
That’s so odd.
Good info tho, ty.
BasicIn fact, as a developer who uses C# and python for both work and leisure programming, I’m actually more comfortable with a mix of gdscript and C#; for game animation, audio, simple physics, and UI, it’s much more efficient to write in gds than in C# (you can focus entirely on the game implementation without having to define a bunch of interfaces and types, etc.), and if it comes to io or heavy loads or communication with the server or other nugets that have similar libraries, it’s natural and comfortable to turn around and call C# to handle it. And if it comes to io or heavy load or communicate with server or other nuget have similar library to deal with, turn around and call C# to deal with it is also very natural and comfortable; now may be missing is: gds-C# shared structure type; gds-C# cross-language bi-directional asynchronous cancelable wait call (now I based on my own implementation of the signal queue to achieve, but if it can be a native wait would be better); gds-C# cross-language message queues
Choosing C# as the primary language for Godot would be a mistake. C# is a great language—one of my favorites, actually. It’s easy to learn, has a ton of built-in libraries, and you can get started quickly. But Godot is written in C++, and for game development, C++ is the better choice, hands down, because of performance.
The main issue with using C# in a game engine like Godot is the performance hit you get from native interop. Managed languages like C# just don’t play well with native code. P/Invoke, for example, is notoriously slow. Sure, there are ways to reduce the impact, but in many cases, it’s still not good enough. Unity has tried to address this with IL2CPP, which converts managed code to C++, but even that isn’t perfect and isn’t available in Godot anyway.
When I play games, I can often tell if they were made in Unity because of the frame spikes and performance issues. Unity uses C# as its main scripting language, and that’s a big reason why. It’s too easy to introduce performance problems with C#, especially with things like garbage collection and native interop. GDScript or Lua, on the other hand, sidestep a lot of these issues and make it more obvious when you’re doing something wrong.
For Godot, the best approach is to lean into GDScript or another lightweight scripting language, and handle the heavy lifting in C++ through modules or GDNative extensions. C# can work in Godot, but it shouldn’t be the go-to option. If Godot were built from the ground up as a .NET engine, that would be different, but it’s not. Performance is key for most games, and C++ is the way to get there.
C++ isn’t as tough as people make it out to be, especially with modern tools like std::unique_ptr and std::shared_ptr making memory management easier. If you’re serious about game development, learning C++ is worth the effort—it’s not as scary as it seems, and it’s crucial for getting the most out of Godot.
Exactly my point. Agree 100%, as a side note, Godot doesn’t need to be another unity. I was quite surprised by it’s performance.
Well Said.