GDScript, a examen: gran integración con Godot y un sistema de tipos a medias

Un desarrollador ha reescrito en GDScript un sistema que antes tenía implementado en TypeScript, para poder ejecutarlo sobre Godot, y ha publicado su veredicto tras el ejercicio. La conclusión: no es un lenguaje de juguete como sugerirían los recuerdos de UnityScript o ActionScript, está más cerca de Lua que de JavaScript en tamaño, pero su sistema de tipos se queda a medio camino.

Lo que hace bien

GDScript se diseñó para una única cosa: escribir lógica de juego. Casi ningún otro lenguaje del sector nació para eso; Lua venía de la automatización industrial, C# de ocupar el nicho de Java en software de empresa y JavaScript de la web. Ese origen se nota en detalles que ahorran trabajo: tipos Vector2 y Vector3 nativos, distinción real entre enteros y flotantes, un generador pseudoaleatorio utilizable sin montar nada alrededor y una sentencia match que encaja con la lógica de comportamiento ramificada que aparece en cualquier juego. La biblioteca estándar trae lerp(), smoothstep() o wrap(), y los arrays empaquetados son nativos, algo que en Lua no existe.

El acoplamiento con el motor es la otra mitad de la ventaja. Las anotaciones permiten escribir una clase de nodo que aparece en el editor con su propio panel de configuración, y preload() y load() dan una semántica consistente a la carga de recursos. Las señales son ciudadanos de primera clase, lo que resuelve el "avisame cuando aquello haga esto" que aparece una y otra vez en cualquier sistema de juego. A eso se suma poder usar el depurador de Godot.

Y no hay recolector de basura. El motor combina gestión manual de memoria con conteo de referencias: los nodos se liberan solos al salir del árbol de escena, y para el resto está el recuento, que no resuelve las referencias cíclicas pero ofrece weakref() para el caso típico. El resultado es un rendimiento sin las pausas que un GC puede provocar en mitad de una partida. C# aporta más características de lenguaje, pero se pierde la integración estrecha con el motor y se gana un recolector corriendo por detrás.

Donde se rompe

GDScript es dinámico con tipado incremental: se pueden escribir anotaciones y obtener cierta comprobación en compilación, pero la función está sin terminar. En el ejemplo que usa el autor, aplicar map() sobre un Array[int] con una función que devuelve String no produce un Array[String]: map() devuelve siempre un array sin tipar y la asignación falla. Toca pasar el resultado por el constructor de arrays tipados a mano, una línea verbosa que además no funciona con clases internas. La raíz es que las funciones no tienen tipo propio, así que no se puede expresar la firma de un callback ni la de map().

Para quien tenga que decidir lenguaje en Godot, la nota deja una regla práctica: si vas a usar el motor, GDScript es la opción natural por integración y depuración, pero el tipado opcional no es una red de seguridad completa. Quien venga de TypeScript debería contar con escribir código parcialmente tipado y con algún cast manual por el camino.