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.
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.
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.
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.