godot-lang-support: a map of the languages that can drive Godot

What the repository actually contains

The repository holds a README and a licence and nothing else, and its stated aim is to provide a faithful overview of the available language bindings and other related projects that target the Godot Engine or one of its many forks. The document itself is licensed under CC-BY-4.0, and the instructions say to look for the individual LICENSE file on the public repository that is linked for each project, which is a useful distinction that is easy to miss. The list is not the code, and the terms of the code are the terms of the project it points at, not the terms of the catalogue. The project also asks for help to keep the document up to date, so the accuracy of the list depends on people reporting changes, and the topics it carries suggest the scope, covering Godot 3 and Godot 4, modules, GDExtension and pluginscript.

Four axes, and why the sorting is not cosmetic

Entries are ordered on four axes, and the first rule is that entries are expected to appear exactly in the order given, with a request to submit a pull request if one is not. The axes are by maintainer, official or community-maintained; by method, a module, a GDExtension, a language that surfs in another language, a sandbox that isolates the code, or auxiliary language tooling; by editor support, meaning whether it can be edited inside the Godot engine and its forks or has support for the Godot API being edited in an external editor; and by target platform, the web or the JIT restricted platforms of consoles and iOS. Every entry in the list carries these markers, so a reader can filter by them mentally. The order is by emoji, which is a documentation choice rather than a technical one, but the rule that entries are sorted makes the list diffable, so a new binding is visible as a one line change.

The console note, which changes what a marker means

One note under the target platform category is worth reading before you interpret the console marker on any entry. Console support is not available by default, because an SDK and an implementation are also needed, and the project asks readers to respect that JIT restricted platforms also do not allow downloading code from remote sources. That second point is a real constraint on the GDExtension model rather than a formality, since a GDExtension is loaded as a library at run time, and the whole point of a console target is that you cannot ship a general purpose dynamic loader onto it. A binding marked for consoles therefore represents a specific, deliberate port rather than a binding that happens to work everywhere.

The production ready tier, and what the official entries are

The top tier is described as languages that are documented and stable, listed in alphabetical order, and it is where the official entries sit. C++ as a Godot module is the official route where you include your game logic as modules, and GDScript is the official primary language of the ecosystem, actively maintained, documented and stable, with the most tutorials online and deep Godot editor support. C# is made possible by an official Godot module, and if you have the .NET version of Godot or Blazium it comes built in. Among the community entries in that tier, C++ through Jenova provides hot-reloadable C++ scripting with support for Visual Studio, VS Code and the Godot editor, nested GDExtension development and a built-in virtual machine for running an entire operating system that can be embedded into the game and interacted with, and it is described as one of the most advanced and best maintained community extensions, with performance on the same level as native C++ and a 0.005ms impact for calling functions from Godot.

The other production ready community bindings

The rest of the top tier is a spread of extension and module approaches. Rust uses GDExtension with a project homepage of its own, and is described as very well supported, with good documentation and an active community. Swift is a very well supported implementation by Miguel Deicaza, with a companion SwiftGodotKit. Nim is a feature-complete, hot-reloadable implementation. Kotlin, Java and Scala come from a project that aims to support Scala in the near future, with GraalVM Native Image also supported. JavaScript and TypeScript have an extension with multiple different backends to choose from, and Lua has a new binding that allows Lua to be used both directly and by calling into it from other languages. Go has GDExtension bindings that are possible to use for shaders. Haxe compiles to GDScript using the reflaxe framework, and Orchestrator is a visual scripting language with advanced macro support, implemented in C++ and compiling to native code, and also usable for dialog scripting. There is also a C++, Rust and Zig project that sandboxes the code, making it suitable for modding support.

The curiosities, and the middle tier

A section of curiosities covers stable programming languages with a twist, and it holds two entries. Enu is a logo-like framework in a block-based 3D world based on Nim, and Ink is a scripting language for writing interactive narrative, in the mode of a language that surfs in another. The next tier is described as halfway there, in active development and comparable to being in the beta stage, and the project admits the markers there might be incomplete. It includes Scratch-like visual coding in blocks, an eventsheet-based visual scripting, the TinyCC C compiler integrated as a GDExtension, a Godot ClassDB binding code generator for C++ extensions and modules, a maintained D binding to GDExtension ported from the previous GDNative extension, a Dart binding whose README contains a detailed roadmap, and an intuitive visual event-based language. The honest reading of these two tiers is that the catalogue tells you what exists, and the tier tells you how much risk you are taking on.

How to use this list, and what it does not tell you

The most practical way to read the catalogue is to pick your language and then read the entry's markers against your own constraints, since the method and platform markers do most of the filtering. If you need to edit the Godot API in an external editor, the editor support marker tells you whether the integration supports that at all, and if you are shipping to a console you need both the platform marker and a separate SDK and implementation. The document does not version itself, since it is a README and a licence, and it publishes no releases, so there is nothing to pin and the way to see what changed is the commit history, with the last push to the repository on 2026-10-22. And because every entry points at a separate project with its own licence and its own maintenance status, the catalogue is a starting point for research rather than a substitute for it.

Editorial conclusion

godot-lang-support fits a Godot developer who has decided to write their game in something other than GDScript and needs to know which integration exists, who maintains it and whether it works on the platform they are targeting, since the catalogue answers all three at a glance. It does not fit a developer who wants a library to depend on, because the repository holds a README and a licence and no code, and it does not fit a decision made from a single entry, because the catalogue itself is a community list where each project carries its own licence and the document explicitly points you to that licence. Before you pick an integration, read the individual project repository for its own licence, check the editor support marker against your own editor, and read the console note, because console support is not available by default and needs an SDK and an implementation on top.

Frequently asked questions

Official sources

1. Godot-Languages-Support/godot-lang-support on GitHub
2. Issues
3. License: CC-BY-4.0
4. README