There's a C API for Godot and GDExtension. It should be easy and it has been done before (but not maintained). The problem is that it's just far slower than GDScript or C#.
> The problem is that it's just far slower than GDScript or C#.
I'd say that depending on what you're doing, you can get away with a lot even in slower language runtimes, otherwise we'd be writing all of our game code in C, C++ or Rust (or other languages like that) only.
I actually ported the Godot LOD plugin from GDScript to C# a while back to what the performance would be like between the two supported languages: https://blog.kronis.dev/articles/porting-the-godot-lod-plugi... and found that the performance was comparable (so language runtime performance itself doesn't matter that much)
As long as you don't do too much number crunching every frame, you should be fine, especially if the engine itself does most of the heavy lifting. Of course, when it comes to the performance impact of interop between different languages/components, that might be a different story.
But hey, it's not like challenges like that can't be overcome due to some inherent limitations, even the Unity game engine sees popularity of MoonScript (which runs Lua under the hood), as far as I can tell. And in regards to games in general, the whole S.T.A.L.K.E.R. game series used Lua for scripting, if my memory doesn't fail me.
The problem isn't just Ruby speed, it's that GDScript exists and Ruby doesn't really offer any benefit over it. If there were no scripting language, sure, hook up Ruby. But GDScript is good.
Agreed, GDScript is pretty nice for working with the engine.
> The problem isn't just Ruby speed, it's that GDScript exists and Ruby doesn't really offer any benefit over it. If there were no scripting language, sure, hook up Ruby.
However, I'm inclined to say that familiarity with a language might be reason enough to choose to use it, if there are no other significant dealbreakers! If you like C++, use C++. If you like Rust, use Rust. If you like Python, Lua, or Ruby use those... as long as someone has done the work to make that possible (or you want and can do that yourself).
GDScript is nice and easy to pick up, but someone who has used .NET for close to a decade might benefit from using some C#, or maybe they like the refactoring or other functionality that an IDE like JetBrains Rider might provide, especially with the occasional nice plugin for the engine itself popping up: https://plugins.jetbrains.com/plugin/13882-godot-support (to be honest, I really liked the Rider plugin for Unity as well, which made writing code a more pleasant experience).
Secondly, there's also the question of an ecosystem, which may or may not work depending on how well any runtime integrates with the engine and what the situation for packaging various libraries/dependencies is (since sometimes you need to deal with native code in Ruby and others). But when it works, you can get a library for basically anything you might want to do: a novel game with AI processing? There are libraries for that. Want to hook up your own netcode solution? There's probably a solution for that. Want to do compression, or work with a variety of file formats, or add dynamic scripting, or interact with a web service of some description? Those are solved problems in some languages, with the solution being just a library away.
Of course, most games probably don't need anything that fancy and the engine has bits of nifty functionality in it, like making web requests, for example, but overall being able to benefit from a rich ecosystem is also good, especially when you decide to do something a bit more novel.
At the end of the day, use whatever works for you: for someone that might be GDScript with its nice integration with the engine and easy syntax, for someone else that might be C# with its static type system and rich IDE support, whereas someone else might be a bit more brave and go off the beaten path further!
