Polygonjs-Entwickler schreibt kommerzielle Engine in Jai neu – aus Frust über JavaScript
Rewriting a Commercial Engine in Jai
Nach acht Jahren mit three.js, TypeScript und Vue.js hat der Polygonjs-Autor seine prozedurale Engine komplett in Jai neu geschrieben. Ausschlaggebend waren die fehlende Kontrolle über Speicher und der Garbage Collector, der Frames zerstörte. Jai erlaubt ihm, jede Allokation nachzuvollziehen und Speicher recycelbar zu verwalten. Version 2.0.54 bietet prozedurale Geometrien, eigene Materialien, Compute Shader und einen Render-Graph – als Standalone-App oder SDK.
Wenn eine Testsuite dir nicht sagen kann, wo du ein Speicherleck hast oder ob du überhaupt eines hast, dann fliegst du blind.
- program_whiz
Mein Kommentar zu Jai ist, dass es eine Sprache mit einigen Annehmlichkeiten ist, aber letztlich kein starker Grund, sie zu bevorzugen. Ähnlich wie zig, odin und andere ist es im Grunde nur C mit ein paar syntaktischen Bequemlichkeiten.
Es hat einige Designentscheidungen, die ich anfangs geschätzt habe, die aber wirklich stark auf eine bestimmte Art des Schreibens von Spielen zugeschnitten sind, und ich würde es nicht als Allzweck bezeichnen (dieselben Designentscheidungen sind in anderen Domänen sehr einschränkend).
Ich schätze die Compilergeschwindigkeit, aber letztlich bin ich davon abgekommen, weil die leichte Verbesserung der Syntax nicht den Verlust von massivem Tooling, Bibliotheken, Dokumentation, Support usw. rechtfertigt.
Die Sprache ist auch recht eigenwillig in ihren Konventionen, was meiner Meinung nach an Jon Blows Stil liegt, aber für jeden, der eine größere Bandbreite an Programmierung hat (als nur eigene Game Engines), recht seltsam wirken kann.
Und natürlich werden jegliche Beiträge oder Vorschläge mit der typischen JB-Höflichkeit und -Charme aufgenommen :)
All die Fehler, die hier erwähnt werden, sind einfach deshalb, weil du nicht verstehst, was für ein Genie er ist – das sind tatsächlich Features!