Rewriting a Commercial Engine in Jai
polygonjs.com
polygonjs.com
It has some design choices that I appreciated at first, but are really strongly suited to a particular way of writing games, and I wouldn't call it general purpose (those same design choices are very limiting in other domains).
I do appreciate compiler speed, but ultimately I bounced off of it because the slight improvement in syntax doesn't justify losing massive tooling, libraries, docs, support, etc.
The language is also quite quirky in its conventions, which I think is due to Jon Blow's style, but which can feel quite odd to anyone who has a wider breadth of programming (than just custom game engines).
Also of course, any contributions or suggestions are met with the typical JB politeness and charm :)
All the flaws people mention here, are simply because you just don't get what a genius he is, those are actually features!
God help you if you are doing multi-threaded with closures and callbacks, web programming, something high level like ML, etc. I feel like the thesis statement of Jai starts with "Ok, so lets assume most programmers are trying to program custom game engines...". True for a very limited set of people, but makes it very painful to use generally.
Its the same feeling you get trying to use Unreal for anything except 3D first person shooters. Its possible, it just doesn't feel very good, and you start to see all the quirky assumptions of the framework.
At no point did Jon Blow make the claim that Jai would be a good language to do web development with. It is a low level system language, if you are making something that requires low level systems language features then you will probably like Jai.
If you are making custom game engines, Jai has some conveniences (especially if you don't use any libraries or care about docs, ecosystem, community, etc). And if you really like "roll your own" with a dash of "everyone thinks I'm nuts but I'm just that much smarter", its perfect. Its one step above "I wrote my own scripting language".
Hence why I say, if you are doing complex / multi-threaded code, good luck to you.
This is why the GC and memory safe languages have mostly taken over. They have even more ergonomic syntax, and none of the footguns. You can still do all the normal pointer casting / abuse type stuff in most of these languages too.
it is true you dont want to trip you up by the language you use, but look what people actually use the languages, not by theory.
almost nobody writes the high performant code directly, usually they just call some libraries that do the job instead. if you are the library writers, then sure, that's a different matter (but people have been doing it forever using c/c++), but for people who use the libraries to write the code, they don't care about any of that.
many people rather pick python, lua, ruby to write applications, even games, despite the low performance of the scripting language, but they don't care. and if it is only the scripting aspect of the whole framework (implemented in C++) then the speed lost is even less.
heck, even for rust, the core libraries always need unsafe blocks, despite they do not recommend user code to use them. it is the same story everywhere. the hard part will be write by more experienced people (and with more effort), the typical users just write domain logic instead.
so, for most people, they indeed need simpler languages with lot of syntactic sugars for better developing experiences.
Extremely reductive and untrue. As someone who still writes/deals with C daily, there is room for a successor that still attempts to be a thin wrapper around an abstract CPU. The C type system and preprocessor has some glaring flaws that are not fixable in a backwards compatible way.
I just meant as my general purpose goto language, I couldn't add to the roster. C++ is already filling that niche for me (except with all the aforementioned benefits), python for scripts, C# for a solid GC lang, there's just no place for a scrappy quirky lang with lots of sharp edges and no value propostion.
I'm just not sure why you would choose _this_ language for those needs. There are like 10 new langs that are all trying to be "the next C" and they all kinda suck (Jai included). I dunno, for me none of them had the same kind of feeling that you get from the really top-tier languages, they all felt like "we took C and solved these annoyances" not "we had a fundamentally new vision".
To be fair to Jai, Odin and Zig, there are definitely software libraries/applications that the world would benefit from having, where this level of performance is basically required. The standard tends to be C++ these days (Rust is rapidly gaining ground, but it's still inconvenient in cases where you frequently need to abstract under the allocator), and I think everyone is looking for a way to not have to write c++ for this stuff.
This left me feeling like "I wish I had decorators and annotations" from other languages, not a way to write arbitrary compile-time code. The use case for that is so rare, and kludgy, that I don't think its worth it.
Now it did shine with basic hygenic macros, which felt useful and solid. Its basically how C macros should have been done originally (a function that emits code at compile time). However conventions like $Code where a bit jank imo, again felt like using someone's home-spun scripting language, rather than a well thought out solid design, versus something like Rust's Syn.
I know Jon Blow hates "design by committee", as he is so much smarter than others, but honestly a lot of this felt like listening to any sane reviewers would catch this stuff. I mean really basic stuff like #cast which reads like a compile-time macro/pragma, but its actually a runtime cast? Or mixing casing conventions, underscores or not, etc. Names of modules are all over the place, it just feels like one dude trying to make a half-baked lang over a long period while being distracted doing 20 other things.
In Haxe i can pretty much do anything, run code, generate code, i even built an openapi doc on compile time just from types.
The interesting part to me was always that he didn't justify Jai very much. He didn't assert that anybody else would want to use it, or that it would be universally better than C++. His claim was that he didn't need to: building a language is now so quick that he can make a language just for him, just because he feels like it. Everybody can have their own language frontend.
His reasoning was that C was a pretty minimalist language introducing structured control flow and little else, yet it's flexibility and neutrality has allowed people to explore lots of approaches.
C++ on the other hand is highly opinionated, and a lot of its opinions are considered wrong or at least controversial (template metaprogramming, RAII, exceptions, diamond inheritance, just to name a few).
A lot of the C++ community doesn't use these features (for example Chrome, LLVM have exceptions turned off).
Jai on the other hand goes heavily into typed AST macros (along with a reasonably powerful type inference enigne), a very powerful extension of the language, that this language has gotten right - the feeling you get when looking at the docs is 'well, duh it obviously has to be done like this' - considering how long it took devs to arrive at this system suggests this is far less an obvious task than it looks like.
Other than this, what the language offers over C isn't much - it shares Odin's 'context' idea that you can inject an allocator or logger function and have your methods use that - which is kind of the point imo.
Blow, as outspoken and controversial a figure he is; seems to have designed a pretty unopiniated language - something designed for master programmers (like ones he has worked with in the games industry, who worked mostly in C) to express themselves, rather than a set of 'correct' opinions the language imposes on you.
Imo it's a shame it took so long to release, as I'm p. sure Jai would've been much more influential 2-3 decades ago or more, and would've had a good chance to dethrone C++.
> A lot of the C++ community doesn't use these features
That they even have the possibility shows how un-opinionated C++ is.
The fact that it did the things I wanted it to (barely), while allowing me to ignore 90% of the design intent behind it shows it was designed in an opinionated way, just not in the way I cared.
Same goes for C++.
It is pretty understandable he needs to hold back before he releases his new game, or even more.
Putting stakes into a language that will essentially be DOA, like the author does seems like a crazy decision.
it is not like he can get the funding via opensourcing the language to cover the development. what he and his company needs is the game to finish and release and get enough profit to cover all the expense. making a new engine is already risky enough.
you just can't ask a man to ruin his whole career/life because it benefits you.
I'm just cautioning other people to put any stakes into a language that's from its organizational bones doomed to fail for any outside party.
This happened years ago with the V programming language making a bunch of claims about the existing feature set that were not accurate and future roadmap that did not at all reflect how things went down, and it was all very bizarre and seemingly avoidable if the developer were truly committed to communicating better.
Another development process this reminds me of is the development by modders to port Oblivion to the Skyrim engine. After maybe a decade, the developers made a huge deal at the end of 2024 that they were going to finally release by the end of 2025 and made a lot of noise about it, but by the fall when no more details had been announced, someone asked in Discord about it and the lead developer directly said that it was not going to happen, with an announcement that it was "delayed" to 2026 not getting made until after people posted screenshots of this. We're now in October of 2026 and it's not clear it will be out this year, but trying to give feedback on the communication gets construed shouted down with exhortations to "let them cook". As far as I can tell, a large number of people seem to think that a suggestion that it's fine for the developers to just not keep announcing when things will be done so that they can take as much time as they want without confusing people is synonymous with telling them they need to release immediately.
If you are fine with getting there 80% his claim is correct. That he's using the language for his games proves it to me. Of course, if you require it to be both open and popular to be a success you kind of reach a stalemate. In a world where everyone can quickly whip up a language I would expect most to be closed to the public anyway.
I would like you to elaborate on how still being in closed beta is an argument against the thesis. To me it just looks like avoiding feature-requests, nitpicks and community interactions for a product he doesn't even want to sell.
> If you are fine with getting there 80% his claim is correct. That he's using the language for his games proves it to me. Of course, if you require it to be both open and popular to be a success you kind of reach a stalemate. In a world where everyone can quickly whip up a language I would expect most to be closed to the public anyway.
I think we're firmly in agreement here, except that IMO the default for software that's not for public consumption is to throw it over the wall, put the source up on GitHub or something, and not bother with documentation, explanation, or interaction. A carefully curated closed beta is kind of the opposite of that. If anything he's spending more time promoting it than I would expect.
If he'd announced the language twelve years ago and then not touched it again until a few months ago I'd believe you. But there's plenty of documented evidence that he's been spending a bunch of time on it, and (allegedly) even using it in his commercial projects.
Not to say that he's been working on it full-time for 12 years, of course, but even allowing for part-time work that's far beyond the initial ‘easier than The Witness’ premise.
Still no. Wildly incorrect. There are many, many languages that were developed and deployed in production in significantly less time, including C, C#, JS, Python, Perl, PHP, Ruby, Lua, basically any real-world language other than Rust was being used seriously in 1~2 years of development. C was written in 1972 and by 1973 an operating system was rewritten in it already.
Maybe you mean it takes a decade to develop a language where literally everything is provided for the user already and all they have to do is copypaste and smush together 1000 dependencies? If your metric is a child-friendly language like Javascript-with-npm, sure, it will take a decade to complete a full ecosystem. But getting a language to a point where it's seriously usable for people who are actually willing to write their own code, is really, truly not that hard.
Some other more recent data points:
Go was designed at Google (one of the biggest software development entities of our times, with input from existing PL luminaries) in 2007, released in 2009, and officially considered 1.0 in 2012, five years later;
Clojure was started in 2005 (there were two other attempts to build similar languages dating back to 2003, but let's charitably omit them) and hit 1.0 in 2009;
Zig has been going for about 11 years and hasn't hit 1.0 yet.
Rust's nine-year record (2006–2015) is on the longer side, but not a huge outlier.
Of course, this is just the time to 1.0; I think in practice languages tending to iterate a lot before becoming mainstream (which is a weak proxy for general usability, but at least should work in one direction). Rust today has come a long way from 1.0, for example, as has Go. Definitely the ecosystems at 1.0 releases tend to remain noticeably underpowered, and even if you want to ignore libraries for a language it's harder to justify excluding other tools that make it easier to work with the language on your own or with other people to build real-world software, like editor support, debuggers, documentation, or package managers.
Having really sophisticated memory management, type checking, semantics, safety guarantees, etc. is not at all trivial. The only part that has gotten easier is syntax => AST => machine code, but that is probably 10% of a PL if you want it to do something people will actually use.
Of course Jai "is fast" (meaning it has none of those things), so obviously LLVM is 90% of the work (just translating AST into LLVM calls). Yes, you can do this with AI in an afternoon, no its not useful to anyone. The real work of making a usable, interesting, useful language is not diminished, and it has little to do with the syntax => AST => LLVM part of the compiler.
Said another way, no one is choosing C, C++, Python, or Java because they are "easy ways to get generate machine code". They choose them because they have: superior semantics (design, memory management, portability etc), 3rd party libraries, frameworks, debuggers, ecosystem, documentation, support, standard library, etc.
I think this is really understating the challenge of generating machine code that is competitive in terms of size, performance, etc. with state-of-the-art compilers. I'll be the first to agree that it's far from the only (or even the biggest) difficulty in PL, but it remains a huge chunk of engineering work. The interesting part of this experiment is how much of that work, as a percentage of the work of building a programming language, is now given to you for free, for a language that is indeed mostly ‘just a syntax wrapper over C-like functionality’.
(Of course, a big part of ‘people will actually use’ is nothing to do with the language at all, but the next twenty years of building an ecosystem and community buy-in.)
This has been my hobby for nearly two decades and it is not so easy because there are hundreds of edge cases that must be considered even if the LLM writes all the code.
Had few other questions:
- Is the dev environment still web first or is that a secondary target?
- One of the best things about three.hs is the extremely fast feedback look with HMR where if setup properly you can code see changes reflected in your running app without a refresh or losing state within a second. Is something like that feasible here?
- How complete is the PBR support? - Lightprobes or lightprobe grid supported? I know that’s just mostly material/shader related code so shouldn’t be impossible to add based on a project’s requirements.
- I didn’t see support for skeleton meshes in the examples either, is that possible?
- Also, how feasible is WebXR support?
Thanks a lot for your questions.
Yes, the SDK being limited to jai beta is absolutely not something I'm happy about. I was hoping it would be public by the time polygon v2 was ready, but of course that was a gamble. Now the rumor is that it will be in 2027, so this is hopefully just a matter of waiting a bit more time. So I completely appreciate presenting Polygon like this isn't ideal.
But depending on what projects you have in mind, the node-based editor is already quite flexible. Feel free to let me know what you're thinking of building and I can tell you what you could try.
To your questions:
- Is the dev environment still web first or is that a secondary target?: I personally mostly dev in native, do most of the work and tests there, and then do final checks in wasm/js. Most of the projects I deliver using it still are web-based, so this target remains as solid as I can make it.
- [...]see changes reflected in your running app without a refresh or losing state within a second: I used to rely on that, but as projects scale grew, I always found that state would become stale in ways I did not understand, so I stopped chasing that. And when working in native against the SDK, re-compiling a project takes about 1-2seconds, so I have not needed to make this work as smoothly as in js. But I could look into it. And when you scaffold a SDK project, the wasm is reloaded without a page reload, but I think your app state my still need vuejs or react to handle that. In short: not fully sure, but it's most likely possible.
- How complete is the PBR support?: You can use env maps. The materials of imported GLTF are decent (see example: https://polygonjs.com/gui/gltf_import). Several things are still missing like clearcoat, and maybe others I am not fully aware of. There are advanced features like order-independent-transparency, volume rendering, raymarching.
- Lightprobes or lightprobe grid supported?: no light probes at the moment. I want to look into it. And I'm evaluating/experimenting with various GI solutions, which may vary depending if you're rendering polygons, SDF or voxels.
- I didn’t see support for skeleton meshes: There is none yet, but that's definitely on my roadmap.
- Also, how feasible is WebXR support?: not implemented yet, but also high on my roadmap.
Just to preface, I’m the developer of an nsfw bdsm game that’s getting some traction. That might not be something you’d be interested in supporting. But it is built using three.js webgl, its is VR-first but optimized enough for even iphones (memory wise to avoid crashing) with very high quality 3d models and physics. It’s also got a story/narrative/dialogue system with multiple worlds/stages. And everything is done in such a way to not spike memory usage even as different stages and parts of the story with hundreds of audio files, animations load over the web with pre-emptive caching.
It’s very hard to ensure memory usage stays low and make the right trade offs for browsers like Safari that don’t give you too much insight into it. Not to mention the limits of webgl for reducing gpu and cpu time which I’m currently also constrained by in terms of scale.
I’ve been considering migrating to babylon lite as webgpu webxr is nearly ready and already out for devices like vision pro, and it’s the only framework that in my testing actually reliably compares to threejs webgl renderer (threejs webgpu and og babylon are way behind).
But all in all having complete control over the memory seems amazing.
And regarding HMR, yeah it does require careful setup with r3f/react and obv has edge cases. But as my game’s story has increased to be hours long, it is quite handy to able to not wait for majority of changes as reloads which themselves can take a few seconds etc.
If you’re interested in chatting more, I can share the project with you if give me an email or another private avenue.
And the type of project you're describing isn't my personal interest, so no need to share it with me. But I'm curious about tools you've used to control memory with just javascript. I know there are extensions or browser flags you can toggle on, but those still seemed cumbersome. That was one of the main reason that motivated the rewrite, and I find it a relief that I can now detect memory leaks in the test suite, or have an easy way to have arenas (and arenas of arenas) so many objects can be freed/recycled very quickly.
So if you have a good way to control/manage memory in js, I'd be curious to hear.
And you mention "webgpu webxr" as if those worked together, but isn't webxr completely decorrelated from the render api? Or do you mean threejs implementation where those might be intertwined? I assumed webxr would work equally well under webgl or webgpu, since my understanding is that it mostly provides camera projection matrices and ray hit functions. But it could be that my knowledge is out of date, since I haven't touched webxr in the last 2 years.
> But as my game’s story has increased to be hours long
For those situations, on most projects I work on, I create a specific control node, which allows changing the state to predefined scenarii, or saving your current state. This requires the SDK for now unfortunately. But this can then be used with or without the editor, and allows you to quickly change from one state to a completely different one with 1 click or hotkey. I found that's the kind of technique that replaced hot reload for me. This made sure that only the state is updated, which limits the chance of bugs due to side-effects. Now that I write this, I realise this needs a proper documentation, I'll work on that.
Yeah so I have no sophisticated tools, just guessed calculations done mostly at run time (add up how much do gpu compressed textures should take for a model, mesh+blendshape memory estimates, other data structures). And obv for audio and animations just ensuring what’s not needed is never in memory and just knowing how much the biggest ones cost. To come up with an estimate of an upper bound and obv with lots of testing. ios safari doesn’t even publicly expose how much memory usage is allowed to a tab (and it changes) so really the final test is that stuff stops crashing. But my testing put the crash window between 500mb-1gb on an iphone pro. over 1gb usually guarantees a crash. Not really enough to make a proper game by today’s standards but hey they shipped gta san andreas at 32mb ram on ps2 so I’m sure I can push things further.
To answer your webxr webgpu question, no, it still doesn’t mostly work. If you’re interested in reading up on it:
https://github.com/immersive-web/WebXR-WebGPU-Binding/blob/m...
Post by a Chrome dev: https://toji.dev/2025/03/03/experimenting-with-webgpu-in-web...
Webxr webgpu attempts iirc some advanced reprojection for increasing FPS that takes into account the depth buffer. And vision pro at least today has some nausea inducing bugs around that for at least the official immersive web examples hosted on github.io. so its better if a depth texture isn’t supplied today. the fallback reprojection works better more smoothly.
For the story stuff, I have similar things setup in my project to essentially reload the game at a certain point in the story but still I personally find HMR to be much faster wherever possible.
I forgot it was such a small budget, it's indeed important to keep in mind how much could be done with little memory. Although I'd argue it was possible with a language that allowed you to control memory very precisely. With javascript garbage collector, I couldn't stand seeing memory ramp up every frame due to threejs internals or my own js code, and every few frame a major GC may or may not lead to a frame drop.
> advanced reprojection for increasing FPS that takes into account the depth buffer
Ah got it. I completely forgot that webxr of course needs to create textures to see through, so it indeed needs to know which graphic api is used. Thank you for the links, I'll have to study them.
this is also good: https://github.com/Jai-Community/Jai-Community-Library/wiki
Which means this website doesn't even know how HTTP 4xx codes work (406 is about content negotiation) and is also being rather pathetically pedantic about user agents.
So, to you polygonjs.com, I say, 469 Go Fuck Yourself.
Less hate would be good too.
Let me give you the full text of the message I got:
> 406 Not Acceptable
> Your browser is not supported. Please update your browser to continue.
My browser is fine, it's built off Chromium like many are, but apparently the UA makes your website say no. Your website should stop doing that, it's pointless.
> Less hate would be good too
My apologies, but I'm rather sick and tired of websites that impose arbitrary restrictions because I'm not using official Google Chrome.
There's absolutely no reason to do UA filtering in 2026.
And using a 406 response incorrectly and ostentatiously so, triggers my nerd rage. Read the RFC about what 406 means. It does not mean what you're using it for.
And I definitely do not need to update my browser.
I'm not sure why you thought it necessary to filter on UAs, but come on, it's the 2020s, it's not like the bad old days of "only renders in IE5 or Netscape 2.0".
If I have to fake my UA to read your webpage, that's just useless friction that negatively impacts your reach. I don't understand why you'd do this.
Apologies accepted. And thank you for mentioning the issue, it should now be fixed, so the website should load for you now.