// the find
godot-rust/gdext
Rust bindings for Godot 4
Rust bindings for Godot 4 via the GDExtension API, letting you write game logic in Rust while mixing it freely with GDScript. The proc-macro layer (#[derive(GodotClass)], #[godot_api]) hides most of the FFI ceremony, so you end up writing something that feels like idiomatic Rust rather than C binding glue. Aimed at developers who want Godot's editor and asset pipeline but need Rust's type system or performance for the logic layer.
The macro ergonomics are genuinely good — #[init(node = "Ui/HealthBar")] auto-wiring and OnReady<T> are the kind of QoL that stops you fighting the framework constantly. The CI suite is unusually thorough: clippy, unit tests, engine integration tests, memory sanitizers, and hot-reload tests all run together, which is meaningful for a project sitting on top of a C++ engine's unstable extension API. The type-safe signal API (self.health_bar.signals().value_changed().connect(...)) is a concrete improvement over stringly-typed GDScript connects. The custom GodotCell borrow-state implementation shows the team thought seriously about the Rust-ownership-meets-Godot-object-lifetime problem instead of just wrapping everything in RefCell.
Breaking changes still happen regularly and crates.io releases lag behind master — for a library you're integrating into a real game, you're effectively pinning to a git rev and hoping the migration guide covers your usage. Wasm, Android, and iOS are labeled experimental with acknowledged gaps in docs and tooling, which means cross-platform mobile/web targets are not production-ready. The FFI layer means compile times are punishing: godot-codegen generates bindings from Godot's JSON API at build time, and that hits cold builds hard. There's no async story built into the engine loop — godot-core/src/task exists but it's early, so anything that needs async (HTTP, disk I/O in game logic) requires working around the single-threaded Godot main thread manually.