There is a contingent of people that truly believe this, and I feel like that is what is motivating a lot of these "better C" languages. For me, those languages always leave me realizing I need to implement my own v-tables in 2026.
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.
I think you are confused maybe, Jai is made by a game developer, to make video games. Whatever exists in the language is there primarily to help video game developers make video games.
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.
Agreed, its just his idiosyncratic styled language for doing so. Like I said in another comment, using it for any other purpose feels like using Unreal Engine for anything but 3d first person shooters. You're going to have a bad time if you're making a 2d mobile-first puzzler. And that's why I don't see it gaining much traction (probably in the neighborhood of gdscript, haxe, or verse).
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".
I don't want syntax conveniences, I want fewer footguns. C has so many ways to trip you up that aren't inherent to its domain. Are any of these new languages better in that regard?
Somewhat, in terms of macro munging vs actual templates and other conveniences yes, however its still very possible to have unsafe memory operations and to accidentally create unexpected behavior. They have their own footguns in some ways, for example Jai's use of arenas can be tricky in more complex programs (e.g. you stored a value with a reference or array, the arena expired). Great for games, bad for most normal code.
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.
So what? Even if most people don't need to write low-ish level code, the fact remains that there are also many people who do (notably for this discussion, game devs). Should a language not exist to make their lives better just because it's not relevant to people doing a web service?
Eh? It is not his duty to public his language. It is not like publish the language is the end of story, you need to deal with the flood of feedback, that not always from good wills. The drama could cause him to lost time, effort and motivation, and hinder his game dev process.
It is pretty understandable he needs to hold back before he releases his new game, or even more.
If he raises interest in the language by saying it will be open source (which he did), I think it's fair for people to dismiss the language until he does actually open source it.
Putting stakes into a language that will essentially be DOA, like the author does seems like a crazy decision.
Yeah, even when the choice itself might be exempt from critique, stating one thing and then doing another surely isn't. Misleading posturing which can't be proven to be dishonesty but is impossible to differentiate from it seems surprisingly common for reasons I can't wrap my head around.
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.
you are not wrong. but like I said it is entirely his choice, which is also reasonable considering the budget Order of the Sinking Star already burned (I heard it was at AA level already)
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.
While it is not open sourced yet (to be honest it is not as important as you think, many programming languages are mostly implemened by a dozen people, even a single creator is not rare) it is not like he forbids anyone to ask for being beta testers, just like the blog writer.
It is pretty obvious anthropic is lying yet again if you think about it rationally.
Unlike Claude models which always hide the thinking process, Chinese models always show it. So how the heck they can delegate the api call to anthropic and still get the full reasoning? Yes there are tricks to reveal the thinking output, but they are just tricks and do not works reliably. So what would happen when they failed to do it? Cancel the ongoing token generation and revert back to it own model? What about the glitches, the delays, the changes in behavior?
I would understand if the attempts are small in volume, because normally people hardly notice it, but anthropic claims that they happened for millions of calls. Such large numbers would surely get noticed by Chinese users and got reported in the tech forums like linux.do. yet we haven't seen any sight.
It is not simple like that, anthropic claimed that they (Chinese labs) routed the api calls to Claude models to keep the illusion that Chinese models are also capable.
So it is not that the labs call the requests parallely and only return the internal version, but also serve those requests live so they can trick the users that the Chinese models are also great.
Which is very silly considering Chinese models are published to huggingface for everyone to test.
I agree we shouldn't believe Anthropic but if you wanted to scam people into thinking they weren't using Claude wouldn't you simply generate synthetic COT?
It is technically impossible, considering they need to serve them live and the token generation speed is a hard limitation. Just think about it, since us models hide their CoT, there will be dozens seconds delay before the first output token retuning to the user. And to predict the fake CoT correctly you need to at least read enough output tokens to make it believable. Then you have to hide their own model CoT to generate said synthetic CoT, which mean further delays. Adding up it will be at least 30s or 1m before you first seeing the thinking process.
I don't think nobody would notice such delays, because Chinese models do not need to hide the CoT like US models so usually they start emit text pretty soon
Well, that can be a recognizable pattern, too. Just imagine when you vibe code using the Chinese models, it suddenly becomes very slow then the output is drastically improved. It would be hard to not notice it.
I surely don't want a fast compiled Ruby for the tasks I would use crystal for though.
Like every one else I also used ruby for almost everything back then, usually some hundred of lines or less for processing stuff. but for tasks that run for several hours using ruby was a frustrating experience. slowness and memory consumption aside, the duck typing system and lazy evaluation of method meaning you can run to typo after hours of running session. sure, you can fix it by write the code more carefully, running smoke tests beforehand and other stuff, but it still a chore, and when you write code all days it makes you sloppier.
having a strong typed compiled language helps it immensely, and with crystal you don't have to sacrifice the easiness of programming. and you can compile it to a portable binary and run it everywhere, no need to reinstall a huge toolchain again. (yeah rust or go can also do that, but not for ruby level expressioness language)
I'm sure crystal is not the ideal language for everything you want to use, and ruby is still helpful for what you use daily. but for some tasks, crystal surely has it own advantages. you can write very capable CLI programs without have to install a single library!
You're free to like Crystal of course, but for me even for long running tasks (almost my entire desktop, including my wm, terminal, editor are Ruby - I still use Ruby for almost everything; if anything, for more than ever), the Ruby ecosystem beats the steadily diminishing performance gap between MRI and an AOT compiled language to the extent that even going to TruffleRuby where I could keep almost all of my code, is rarely worth it for me.
But my main point was that people who do want a fast Ruby should be aware that Crystal isn't a Ruby in any meaningful sense - if you like Crystal for Crystal, by all means use it.
no, I meant when your script crashes because some careless typo in the middle of the file, then you will value a compiled language. and even when there is no typo, your program can still crash due to the huge memory consumption.
also, using crystal you have parallel and concurrency to speed up your task. sure it is not as good as other matured languages, but it still does the job.
when doing with large amount of data, and with IO involved, you will see that your JIT or AOT engine for ruby still can not cut it, because in ruby there is so many layers of safety check and failure guard it is really hard to make it faster (number calculation is not everything). with crystal you can manipulate the io stream directly, avoiding a lot of intermediate steps. you can check yourself, they make a full page for it: https://crystal-lang.org/reference/1.22/guides/performance.h...
personally I do not use a single language, I just pick the most suitable language for the job I'm doing, let it be ruby, python, crystal, rust, go or typescript. but surprisingly crystal is the one I use the most everyday.
> no, I meant when your script crashes because some careless typo in the middle of the file, then you will value a compiled language. and even when there is no typo, your program can still crash due to the huge memory consumption.
If your code is poorly enough tested for a typo to cause it to crash, a typo is the least of your concerns.
> also, using crystal you have parallel and concurrency to speed up your task. sure it is not as good as other matured languages, but it still does the job.
So you do in several Ruby implementations.
> when doing with large amount of data, and with IO involved, you will see that your JIT or AOT engine for ruby still can not cut it
I've used Ruby for large scale IO with Ruby for 20 years without problems, even on CPU's far slower, and with Ruby versions far slower than today. If you're doing IO with Ruby and the performance of your language implementation is what is limiting you, rather than spending most of the time in kernel space waiting for system calls to complete, you're doing something wrong.
> when your script crashes because some careless typo in the middle of the file, then you will value a compiled language
How about the crashes for all the other more common reasons? It seems like a concern unrelated to whether a language is strictly AOT-compiled or not, and whether such compilation runs through a static type checker or not, and in any case surely differs a lot among programmers' experience. (Crashes from typos basically rarely if ever happened to me in Python, same with memory constraint crashes. But I've never tried running Python on anything with less than 1 GB/core, if you don't count possibly some educational usage on ancient 90s hardware or a 2004 laptop; the lowest power device was probably a Cubietruck3 from 2013 that still had a generous dual-core ARM cortex-a7 and 2 gigs.)
But I agree with the sentiment, I hate it when programs crash and take out their work in progress or other state. I wish more languages adopted the Common Lisp condition system model, where errors don't crash or unwind anything by default and you can dynamically fix things and retry, or resume, or restart from a specific stack frame. There's even a book about implementing it: https://www.amazon.com/dp/B0DF5YVJKJ (And despite being dynamically typed, Common Lisp is compiled to native machine code, and some implementations like SBCL offer some bare-bones static checks to flag trivial typo or type mismatch issues during compilation, before running the code in question... You can also bolt on a full static type system language on top as a library if you want.)
I doubt that, I got downvoted several times pointing out inferencing is insanely profitable.
Even take account of R&D cost it is still profitable, because you do not actual retrain the base model every month, only distill and post train from the same foundation.
heck, I think even including the giant cost of the top tier researcher salaries, they are still profitable.
then, how are they still losing money? just read what they are actually spend the most budget: always the hardware. those companies will never profitable, because they will never stop spending money to expand their computational prowess.
It passed the test of using latest crystal-lang concurrent feature (with web search) when gemini 3.8 flash failed (again, with web search enabled). I think it is at least useful for coding, for sometime.
reply