为何我用 Jai 重写 Polygon 引擎
Rewriting a Commercial Engine in Jai
我八年前用 JavaScript 和 three.js 打造了 Polygon，但它始终受困于浏览器内存限制和垃圾回收机制导致的卡顿。在尝试 Electron 集成 Steam API 失败后，我转向 Jonathan Blow 的 Jai 语言。两年重写之路充满挑战：从重构核心引擎到自研渲染器，最终实现了内存的完全掌控和性能飞跃。现在，Polygon v2 已发布，支持 WebGPU、自定义材质和计算着色器，为艺术家和开发者提供了更高效的工具。
如果测试套件无法告诉你哪里有内存泄漏，甚至无法确认是否存在泄漏，那你就是在盲目运行。
HN 评论区
28- program_whiz
我对 Jai 的看法是：它确实提供了一些便利，但最终并没有特别充分的理由去偏爱它。和 Zig、Odin 等语言类似，它本质上就是带有一些语法便利的 C 语言。
它有一些设计选择，我起初挺欣赏，但它们其实非常适合某种特定的游戏开发方式，所以我不会称其为通用语言（同样的设计选择在其他领域会非常受限）。
我确实欣赏其编译速度，但最终我还是放弃了它，因为语法的微小改进并不足以弥补在工具链、库、文档、支持等方面巨大的损失。
此外，该语言的惯例也相当古怪，我觉得这源于 Jon Blow 的个人风格，但对于编程经验更广泛（不仅仅局限于自定义游戏引擎）的人来说，这感觉相当奇怪。
当然，任何贡献或建议都会遭到典型的 JB 式礼貌和魅力回应 :)
这里所有人提到的缺陷，无非是因为你不懂他是个天才，那些其实是特性！