public static Vector operator -(Vector a, Vector b)
    {
        Vector v = new Vector();
        v.X = a.X - b.X;
        v.Y = a.Y - b.Y;

        return v;
    }

    Vector result = myVector1 - myVector2;

At one point Mozilla had a prototype implementation of strongly-typed value types in JavaScript, but it fell by the wayside once WebAssembly became a thing.

var result = myvector1.sub(myvector2)

The real kicker is value type semantics. You have two options with reference types : you can either do math in-place or allocate on each operation. First option is a huge foot gun because the ownership is unclear it's super easy to share references to something and update something unintentionally. And it can be hard to track down. Second option is super taxing on GC. And the overhead of going through reference for simple 3 float tuple (and object type info, etc.) is large - but for large arrays you can sort of work around it by primitive arrays. But that's like hand rolling assembly and you're supposedly using a high level language.

C# with structs and operator overloading is an ideal high level language for gamedev - most of the time it's really ergonomic and high level, but it has the tools to get down to memory layout control without it looking like disassembled code.

I imagine it was too much work to support two languages? As a dev reading docs, I used to have to deconflict the parts of the docs talking about JS from C# (not difficult as an experienced dev -- I wonder how the first timers fared). I'd also have to translate advice from JS Unity programmers into C# when researching how to do certain game things. I'm sure JS Unity devs had to do the same with C# advice.

I'm happy they aligned on one language. If JS had an optional type system baked into the language, I think it would be a better choice. However; it doesn't.

Nothing is stopping you from compiling JavaScript though, browsers do it. The lack of static types makes this harder, of course.

That said, there are forks of Godot that support JS/TS but I don't know how up to date or ready they are.

There are game engines written in rust Bevy for example

Perhaps consider that for many programmers, TypeScript is JavaScript, and TypeScript is that better language. I've put a decent amount of thought into using TypeScript for games because it allows for a flexible, expressive data model in a way that few other languages do. The performance might be a problem for some flavors of games, but I'm interested in discrete simulations almost exclusively, where it doesn't matter at all. But TypeScript allows effectively encoding intent into data structures and into code in a really ergonomic and pleasant way, while also running on virtually every gaming platform on the planet.

(Rust, etc. are fine. If that's your bag, that's great. I'll write Rust if I need to, but I don't enjoy it, and don't seek out opportunities to write it.)

https://en.wikipedia.org/wiki/Discrete-event_simulation

In truth, I think V8 is almost certainly more than fast enough for real-time games (real-time in the gaming sense, not in the OS sense); Mono is fast enough for Unity, even, and Mono is creaky and slow, with a really poor garbage collector, on its best day. But for the stuff I'm interested in, I just don't care at all.

- easy interop with native programs/libraries

- modern language features (pattern matching, async, and many more)

- Strongly typed

Microsoft XNA used to be a popular indie game framework that used C#. Stardew Valley, Celeste and Terraria run on XNA.

Mono used C#. Xamarin used Mono to create a cross-platform application framework that worked on mobile. Unity leveraged Xamarin to create a cross-platform game engine that worked on mobile, ending up using C#.

Thus, two generations of indie gamedevs ended up learning C# to create games. Then Unity grew a whole lot, so more and more people ended up associating C# with game engines, so as soon as Godot was released people started asking for C# support.

But C# being the language of choice doesn't really depend on specific C# features. It could've just as easily been Lua or JavaScript instead. For example, RPG Maker moved from Ruby to JavaScript when they upgraded to a new engine, again, because their new rendering engine was nw.js, and getting it to run almost anywhere was easy.

C# being possible to mostly AOT compile (some exceptions) is also an advantage over JS for scripting since JS is not particularly efficient to run in an interpreter and many deployment targets don't allow you to JIT code at runtime. Languages like Lua have much better characteristics for those targets since they have high performance interpreters and cleaner language semantics.

As engines became larger products, companies often have the resources to make something bigger for game teams. Unreal’s Blueprints, or Godot’s GDScript integrate much more tightly with the engine’s runtime.

If you're an indie dev you usually don't want to strain the hardware with extremely complex models and textures and rendering pipelines, because you don't have the money to produce or source these models and textures.