I won’t use the word “serious” but my limited personal experience is that C# feels like the right balance between flexibility and performance.

Rust is a joy to write in but I personally find that it asks a lot from you when you just want to ship a game that doesn’t need to be safety rated.

C++ is a great choice but it’s C++ and I’m just not good enough to enjoy a language with fewer guardrails. It also has similar verbosity issues to Rust and (likely because I’m a noob) eats up a lot of my time chasing dumb bugs rather than making a game.

I do most of my game dev in TypeScript because it’s a wonderful language and web is a great platform to easily ship toy games (my specialty). But it just isn’t fast enough for anything major.

I find it hard to imagine whatever glue language you choose for an engine like Godot would really matter that much. All you’re implementing is the business logic. Even the slowest language can run through basic business logic in the blink of an eye relative to the heavy duty that the Godot systems are doing.

Eve Online runs on *python*, for instance. So does Blender. For a glue language, I am highly doubtful that the .net is that much faster than v8 or any other runtime to make a difference.

Agreed - our company's app isn't a game but is built on top of UE4, and nearly all of our code is in Python and it's never the bottleneck, not by a mile.

So you think all the talk about performance tuning in games is just made up, or what?

What ends up happening is you write scripts for lower compile times and ease of use. Then if something is too slow you rewrite it in native. The speed of the scripting tier lets you write less in native. Its not irrelevant at all.

Most of it is, because most of it is cargo-culting by amateurs who just believe what they read on SO and forums and who have never actually written anything non-trivial, much less shipped a game.

Are you saying they misunderstand what they're cargo-culting or are you saying amateur game scripts run fast enough? To cargo-cult it needs to be relevant somewhere, so either way it shows the blanket statement is false, no?

I'm saying most amateur games do run fast enough, and that for those which don't, the bottleneck is more likely to be related to poor caching, unnecessary allocations or unoptimized assets, etc, rather than just the language used. You really have to go out of your way nowadays to actually slow a game down with just bad code.

And many of the idioms people abide by may no longer be relevant, or may only be relevant in niche but not general cases.

Exactly. The Godot components are very performant, and the glue code doesn't get in the way. And Godot 4 is getting compute shaders, IIRC.

I've built a few custom engines over the past decode, also shipped a few games. I've lately been working with Bevy in Rust, and I really absolutely love it. It's the perfect framework (for me). Bevy gets out of the way enough where I don't feel like I have to fight with it, which is what always annoyed me with actual game engines. Plus, I love working with Rust.

> isn’t fast enough for anything major.

I think it could be fast enough if portability to different platforms wasn't such a high priority for game studios these days. Nobody wants to write typescript and then pay $50M for someone to port it for Switch or whatever.

Well you could always go with C++ but C# has a solid balance of high level features, good libraries, good tooling, a feature full (if not slick) threading mode, performance features when you need them and good interoperability with native code.

Its not always fun or sexy to rewrite a reference type to a value type to get around your GC but you _can_ do that in C#. Its a have your cake and eat it sort of language.

Can you elaborate on that? Do you mean rewriting existing classes as structs so they go on the stack?

Yes, just an example of one of the many performance minded complications that C# brings to the table. You can even use raw pointers if you want to.

https://docs.microsoft.com/en-us/dotnet/csharp/language-refe...

gdscript is dynamically typed. If you have the large arrays of structs common in gamedev, then all data members are boxed, significantly increasing memory usage compared to something like C#.

C# objects are boxed too.

Boxing is taking a Value Type (struct, int, enum, etc) and converting it to an Object. So Objects aren’t boxed.

Apparently we have different definitions of boxing. To me, and I've always used it (and seen it used) like this, a boxed value is a value that's stored on the heap and passed as a pointer. Maybe C# has a different definition?

No, from the C# docs[1] - Boxing is the process of converting a value type to the type object or to any interface type implemented by this value type

[1] https://docs.microsoft.com/en-us/dotnet/csharp/programming-g...

Right, so then in C# a boxed value is an object as far as I can tell.

That’s correct, but not what you said. You said objects are boxed. Values are boxed to create a reference by wrapping it in an object, objects are already reference types so there’s no boxing.

I'm not extremely familiar with C# objects, but I think I get the confusion now. My point was that objects are boxed values, and that most things in C# are (to my knowledge) objects. I guess I used slightly the wrong words.

Probably not serious, just that it's the language used in unity