Just to be pedantic: the command is jai.exe, and the source file extension is .jai, so everyone calls the language Jai. Except Jonathan Blow, who only ever refers to it as "the language" in his videos. I vaguely recall him saying in an interview that he doesn't want to commit to a name just yet.
Jai has not been released to the public. If people are looking for a language that has been very heavily influenced by it and is in a near category, then that would arguably be Odin (https://youtu.be/M763xHjsPk4). Odin is open to the public, where nobody knows for sure when Jai will.
Rust will be nowhere in the next 10years for gamedev, not even sure it will be used at any point. The only one I know using it to some extend is Embark but they have a very good engineering culture ( ex DICE / SEED ).
For people not working there, it's kind of a blackbox in term of tooling / pipeline etc ... when you work in webservices you have a ton of opensource knowledge / tools available, videogame are kind of different they re-invent a lot of the stuff in-house.
I think this is sadly true. If you follow Game Devs with Large, Fragile Egos Twitter (I'm not naming names!), you'll hear a lot of "I hate (but secretly also love) C++ (because I know it intimately)" and "Rust isn't the answer" because they can't iterate fast enough.
My guess is that's probably a function of them thinking they can learn Rust in a weekend, because they are 10x-ers, instead of any inherent problem with the language. There is also a machismo aspect to C/C++, especially in game dev ("I eff with raw pointers all the time!").
But, if you read the article, Tim Sweeney seems to be saying "I want a fast functional language" which Rust is. One thing I am less clear on is whether Rust is better re: modularity and extensibility.
> He also wants a garbage collector (pg. 57) and Pascal / ML family syntax (pg. 58). He clearly wants https://nim-lang.org/.
Since this was written in 2005, Rust/the Rust model didn't exist, so maybe Rust is memory managed/ML enough? But I am interested in looking at Nim. Had no idea it was ML influenced.
And I think I read in another comment Sweeney hired an engineer to write a new language called Verse.
FYI Nim also follows the Rust model with sink/lent annotations[0] + optimizes the (not yet default) automatic reference counting with static analysis so that RC overhead is minimized. Nim is like something between Pascal / Rust / Python, not sure why it is not more widely used.
> Sweeney hired an engineer to write a new language called Verse.
I think a lot of people want Nim, but either don't know about it, or some language feature turned them off. There are a few polarizing language design choices, but every language has something. Perhaps it just needs a killer app using it in some visible fashion (e.g., Lua in Neovim and Hammerspoon).
I was turned off by the Windows Defender issue. I can't release consumer software written in Nim if every executable compiled with their toolchain is flagged as malware and the downloads silently halted.
For context apparently Nim had a few articles written on how to write “red team” software with it and it also got popular with malware writers. Ultimately there’s an issue with AVs being lazy and flagging all Nim binaries as malware. Some of them even ignore binaries properly signed with good keys. Just another reason AVs are terrible.
Glad to see progress on this, because I really liked Nim when I learnt it and this is my only blocker to consider it for a few personal projects.
I understand the necessity to detect known malware, but AVs are definitely terrible if they're unable to fingerprint the actual malicious code rather than the general traits of the toolchain used.
Also, signed binaries have proven close to useless since newly released binaries/installers raise a warning on Windows until several people run them anyway.
A lot of game development happens under the pressure of constant crunch and low budgets. I'm not just talking about EA and their constant penny pinching but small studio releases are a huge gamble with a steep upfront cost (Sean Murray, the face of Hello Games that released No Man's Sky, famously took out a large personal mortgage against his house to keep the studio afloat) and no guarantees of success after release - games can fail for the most absurd reasons.
I think a lot of game programmers will keep an iron grip on using C/C++ for a while simply because they don't have the luxury of exploring other options. That said, I think Rust is exceedingly well designed to supplant C/C++ - game development really wants to minimize runtime failure cases and push more errors onto the compiler and static analysis due to the size and complexity of the project and Rust manages to deliver that without compromising on the performance needs - Go was a similar hopeful for a while but the lack of exception throws even under controlled situations is very difficult to deal with (I know you can panic and catch panics but it is a very rudimentary system).
> I think Rust is exceedingly well designed to supplant C/C++ - game development really wants to minimize runtime failure cases and push more errors onto the compiler and static analysis due to the size and complexity of the project and Rust manages to deliver that without compromising on the performance needs
why would a preference for the use of raw pointers indicate "machismo"?
do you think there's any possible other reason why game developers would choose to not use rust aside from some hypothetical jerkbag strawman that exists in your mind? is it possible that there's any practical reasons you haven't considered?
> why would a preference for the use of raw pointers indicate "machismo"?
Ugh. That's not what I meant/said. What I meant was that there can exist a certain belief that there is only one way of doing things, when in fact there may be several. And there can be a belief that, because one has experience dealing with the most unsafe and bug ridden things, that experience is somehow necessary everywhere and all the time.
Perhaps you might try to address the question at hand, is there a certain amount of machismo re: C/C++ in game dev? Heck, everywhere?
> do you think there's any possible other reason why game developers would choose to not use rust aside from some hypothetical jerkbag strawman that exists in your mind?
Oh, totally. I'm reading the comments and looking for exactly these sorts of serious, interesting criticisms.
However, from what I've seen, some game dev criticisms have been pretty shallow from certain segments of that community. In another comment, I explain there are some game devs that have gone really deep on Rust and have really interesting things to say about it. My fear is simply that the more shallow sentiments of these high profile enfants terrible will take hold, because they often do.
I thought about this for a bit, because at first I thought you were making up a rather insulting caricature that could only detract from your case, or at least from anyone wanting to engage with you. I've been in C++ game dev for something like 25 years, and I'm sure I have never encountered a programmer who acted like using pointers was any more impressive than using the alphabet. That goes for any daily-use language feature not including all the optional C++ esoterica. We don't even talk about using pointers, we just use them. We no kidding talk more about how to use curly braces than how to use pointers. But then it occurred to me that perhaps that's only true amongst ourselves, where we don't have as much to feel defensive about. It's just silently understood that pointers are basic. But maybe if a C++ programmer were talking to a Rust programmer or any other language with a higher level memory paradigm, and if it was a conversation about whose language was best for what, then maybe they would feel defensive and need to act a bit superior.
Or, perhaps when you say they act big about using pointers, do you mean that they act big about using pointers safely? Because that is different. That's a conversation I began declining to have because I no longer believe it's possible for a person who is trying to use C++ for a task, and has already decided it is the best available tool for that task, to have that conversation with pretty much anybody without it devolving into a pissing match.
> But maybe if a C++ programmer were talking to a Rust programmer or any other language with a higher level memory paradigm, and if it was a conversation about whose language was best for what, then maybe they would feel defensive and need to act a bit superior.
There is a reason "I will never be able to get the control I need (but I don't know)" or "I'll have to use unsafe everywhere (but I haven't tried)" are anti-Rust tropes. It's possible for certain game dev patterns to be awkward in Rust (really interested in hearing more about these!), but these other criticisms smell less like highly relevant informed criticism, and more like one hasn't tried Rust, as much as surface-level, mole hill criticism of hypothetical or pathological instances of bad syntax do.
It isn't that one uses raw pointers. It's much more an attitude I've witnessed in younger programmers that if they're not doing it in C/C++, they're not doing the thing. It's about vibes as much as anything else, and I think, when their heros use their own vibe-level criticisms, they only reinforce that perspective.
> Or, perhaps when you say they act big about using pointers, do you mean that they act big about using pointers safely?
No, I wasn't thinking of that, but that's another part of it. And now that you mention it, "My code doesn't have any of these issues" can be yet another defensive tact.
it's just that the specific phrasing of "anti-_______ tropes" is usually reserved for something much more severe than criticizing a programming language…
if you're actually interested in learning different perspectives from people who have done significant work in the field and you're willing to stomach someone who I have to presume is one of these "large fragile egos" or whatever other vague terms you want to use about vague people vaguely (this passive-aggression is rather unbecoming), I personally found this comment, and the rest of the thread, to be very enlightening with regards to how I think about memory management in video game development and why rust's lifetimes maybe aren't the best solution for the problem domain https://news.ycombinator.com/item?id=26443768#26451692 (specifically the numbered list of memory usage patterns and the ensuing discussion about them)
FTR, I'm not talking about jblow. I acknowledge his criticisms are superficially similar to what I wrote. At the very least jblow is seriously engaging with the arguments re: Rust, like in this thread. As to whether he's actually seriously tried to learn Rust, I'm unsure. I hope he does.
And I'm not naming names not to be passive aggressive, but for self preservation. I don't know if you noticed, but games can have a really toxic fandom.
Are you saying you've never encountered an engineer with a large, fragile ego? Because lucky you.
I guess I'd also say there is another, more mature side that takes Rust much more seriously, even on Twitter, such as John Carmack. I didn't know this needed to be said but not all game devs have fragile egos, but, wow, some certainly do.
I love Rust, but it's "righteous" nature might go against the grain in many game shops where quick and dirty is not only accepted practice but where anything more rigid than C is deemed necessarily inferior. Something like Zig might have a better chance in that space.
Are there game studios out there still using C? From what I've heard the majority is using C++, so switching Rust just makes your life easier without changing too much (C++ devs already uses templates, smart pointers, RAII, etc. which Rust has too, but with a better design (a stronger type system, and also hindsight from 30 years of C++)).
From what I've seen on HN, Zig seams to appeal people who like the “simplicity” of C and find Rust too complex, but I don't think anyone coming from C++ could find Rust “too complex” (a bit different, with a learning curve indeed, but not “too complex”).
I don't know much at all about game development circles, but have a fair appreciation of others areas using c or c++ for combinations of high performance, low level, bare metal, etc. I've found some shops that very specifically use c, but other that use "c++" but that means "pretty c-like, with a few c++ features but don't you dare do x,y,z". Some of these variants are pretty simple, but it's enforced by code/design review (and sometimes tooling) not the language.
Zig also tries to block quick-and-dirty stuff, unused variables are errors for example. There are formatting related things too.
This is obviously not as "righteous" as Rust as you put it, but when you look at the source of some shipped games, you'll see that some programming best practices are ignored.
None of this will block Zig from being used in games, of course, but I wish they had a "let me work in peace until I get this working and then we can worry about that small stuff" mode in the compiler.
I think the reasons languages like Zig choose not to make this configurable is because other than the odd exception occasionally very few shops bother to turn on the stricter mode or are actively hostile to the stricter mode.
And when you rely on other libraries that sort of less strict mode tends to start leaking out everywhere since that one critical library you really don't want to rewrite won't compile when you use strict and you don't want to carry a bunch of patches for it either.
The net result is if you don't start out enforcing cleanliness your community of users will unintentionally devolve into unclean over time.
> The net result is if you don't start out enforcing cleanliness your community of users will unintentionally devolve into unclean over time.
Well since the package manager will be integrated to the compiler, I think they could enforce the cleanliness for people who want to publish their libraries.
> when you look at the source of some shipped games, you'll see that some programming best practices are ignored.
yeah. players demand performance because it relates directly to a better playing experience. they demand it with their purchases and their critiques. game developers understand this inherently or they will not be a game developer for long.
honestly, i think a lot of “best practices” are nothing more than an influential person demanding compliance to their preferences, because a LOT of those “best practices” actively reduce developer productivity and runtime performance both; there’s no tradeoff, its just pure loss.
non-game developers could learn a lot from seasoned and experienced game developers, i think, but we imagine ourselves wholly superior when we absolutely aren’t.
There are at least some studios using Rust. Chucklefish did for a while though they ended up stopping. Ready at Dawn was using Rust at one point but not sure if they still are. Embark still is so far as I can tell.
It certainly isn't a language for every gamedev shop but some seem to be taking it seriously.
You can always use "unsafe" code in Rust. At that point you're basically writing a block of code in C++ with the guarantee that it'll interface correctly with all your other "safe" code.
Finally. Someone gets it. It has nothing to do with the language itself. But the culture and philosophy of the tools / language / framework or library.
I'm writing a kernel in Rust, having a great time. I'm not sure what all the arguments here about it not being suitable for game dev are but I would imagine it works perfectly for game dev.
Suppose you wrote a kernel in rust. Now there has been a CPU regression and you have to implement a retpoline. Obviously you don't want to implement it in places where you don't have to. Would this be easy? Or hard?
Because macros can obscure having an accurate mental model of what is happening at the metal level, which is what matters when you're doing a retpoline. This is why ziglang, for example, has "no hidden control flow". Not only the mental model, but also you might find that where you need to add the code forces you to break open a macro, which could be a considerable refactoring task.
I find it interesting that one of the go to "let's learn Rust" books (Hand on Rust) is cantered around building a rogue like game. I feel like this will have a subtle but noticable (long tail) impact because many people who start learning Rust will do so on gamedev examples. The next logical step for a couple of them will be "all right now I'll build my own cool game". Maybe it'll be a tiny fraction but I feel there will be more good people moving into the Rust-Gamedev area than if that book was about building a web server.
Also worth noting that you can write Godot native plugins (I don't think that's the correct terminology - forgive me, I'm not a Godot developer) with Rust, and wire them up with GDScript. This seems super promising to me as far as Rust in game dev.
Not so sure about this, it may take quite a time. It's not because of language's strength or weakness but simply because the upfront cost of building a modern game engine from scratch is getting more expensive and expensive. It's going to take a decade to build a competitive ecosystem against Unity or Unreal, assuming the best scenario.
I am sure it will happen, but (in my opinion) there is no way that it will gain significant popularity. It's just too high friction and in game development being low friction is imho one of the most important attributes of a programming language.
> All dereference and array accesses must be statically verifyable, rather than causing sequenced exceptions
This is such a pipe dream. In so many cases you will not be able to verify array index statically except by having the programmer write assert statements which the compiler could do automatically when it can't prove correctness (like the java JIT which can lift out bounds checking from loops).
Its funny how nothing of that actually got implemented.
Instead we have visual scripting to allow people that cannot program at all to contribute.
There are no near future improvements that fit game development people. All people who could have been creating and using new languages are not even going to go to job interviews. Because ads, fin-tech and web are paying a lot more.
But how did they improved life of those of us who are programmers and work on games?
The article was about programmers being able to express their intent in code better. Life went completely different way. And most of comments even in 2022 here are still following that old dead end path and arguing benefits of different programming languages that maybe will change game industry.
have you had a back-and-forth with someone who sat with you so you could type while they designed a system, because they can’t code and you’re not a game designer? Blueprint eliminates the developer time needed for that design work, and lets the designer design at their own pace. when they are happy, you (the developer) can turn that into code quite quickly, without the days required pairing with the gameplay designer to get the behavior where they want it.
More generally, there are benefits to every programming language ever made, if you count learning what not to do.
In my experience with such tools the part 'you can turn that' means that you do not let them go far away from the cage and quickly destroy whatever they did.
Which is not what I see happening.
I see that now you have 2 layered system forever. You need to fully understand both layers to make changes. You need to keep everything like it was designed so design person will be able to continue their work. You now need to design code blocks to the puzzle to make it look like its a software.
Currently I am coping with what I see and the only feeling I have and I know its wrong, is that whatever prototype team gets from this visual stage has to be stripped for ideas and redesigned from clean slate before going into next steps. But I have been in business long time and I know I will not see any clean slates anytime soon. We are going to ship whatever 'works'.
That slide deck is pretty interesting just to see the 10k foot vision of a game. I'm working at that level in infrastructure software and the vision of what comes together for the game development and design is fun to see.
In 2022, in a HCOL, $150K base for an exceptionally senior/lead developer with 10 to 15+ years of experience, writing hard-core C++ and multiple shipped AAA titles, in the games industry, working on console or PC or mobile, with a BSc, that isn't connected to blockchain/web3/nfts/crypto, is actually on the high side. If the developer is pure Unity (even if they are writing C++/HLSL every day), you can cut another $20K off of the price. Senior developers sit around $100K to $120K. Mid-levels below that. I am specifically talking HCOL US wages. I got a "generous" offer last year where the company struggled to get to $160K base for the Los Angeles area. There's a reason that Roblox, Amazon, Microsoft, Google can slurp up pretty much any software developer in the games industry.
Artists and designers will rarely break $100k. There will also be project management (director & producer), and QA. Though depending on how the studio is set up, QA might be a shared resource and only get line items towards the end of development.
Tool & software budgets in the games industry are miniscule. Training and continuing education are non-existent. Bonuses hardly exist. You might get a $40 "special sale" office chair that at least four other people have had before you. Unless you buy your own or get really lucky, that keyboard and mouse you're given has been there since the company was founded and are now considered religious artifacts.
A fully loaded team of 10 developers is going to be one lead, two or three senior SMEs, 50% mid-levels (if you're lucky), and the rest are juniors or developers who are (non-visual) scripters building visual (UI, effects, game play) in Lua or some other scripting language.
We can argue the numbers back and forth in endless pedantry, but my salary numbers are going to be pretty close to reality, with $5k to $10k here and there based on current industry trends. I keep my finger on the pulse of the industry pretty closely. In 22+ years, high-end salary of $100K in 2001 has slowly crept up to $130K-ish in 2022. Over my 40 year career I've spent a good two decades doing AAA development, have been senior/lead/tech director and CTO, and run my own studio, built multiple teams and managed large projects and have hired a lot of game developers over the years.
I remember from my (very!) brief stint in the games industry that there are certain specialists who make considerably more than that, such as game engine, cutting-edge rendering and 3d audio specialists. But, it sounds like it still pays to be the one selling shovels. The company I worked for paid mid 5 figures a month to Unity for one dedicated engineer to help us with our issues.
Of course there are outliers, without a doubt, but for the most part, wages in the games industry lag far behind "market rate" of the overall software development industry.
I wonder what the author would think of C# now. Seems he's very much a fan of C++ over C#/Java, which may have changed in the intervening 15+ years.
Personally, I think continuing to use C++ for game dev (it is still the lingua franca) is more about momentum than it being the best choice (in most instances).
His predictions on what computing power will look like "in the future" (e.g. now) are interesting as well. Some have played out, others haven't.
I'd be interested to see some non-text super-IDE integrated programming languages. Maybe even hosted in the webbroswer. I think that's interesting territory that can unlock a lot of value. Simple instant variable renaming, far better commenting and interactive debugging that can all be stripped from a compiled final version etc.
Have you looked at visual scripting which is popular in games? It may or may not be what you want but it is non-textual way of creating logic. UE has Blueprints, Unity has Bolt (as well as 3rd party ones available on their asset store, but Bolt is the one Unity purchased). Godot had one though it is being taken out of the core engine in 4.0
It isn't 'just fashion'. I agree with SPJ that what we are all here for, is the content of the education, not how it's presented. The problem is that a good font makes it easier for people to relate to the content.
Having a comedy font for a dead-serious funeral company technically communicates the required information, yet it's going to limit your audience to those that can tolerate the conflicting tones and the people who will choose to relate to what you're trying to say.
It's really so difficult to press CTRL-A and select a different font? Would it cost him so much to relate a little closer to the tried and true methods?
There is no readability argument here with just short phrases and bullet points, so your stance is purely middlebrow gatekeeping.
SPJ and Tim Sweeney don't care about people who are only willing to listen when the other one does it "the right way". They put something out and if you don't like it, you can leave it unread.
I like good fonts, I have bought several "serious fonts" for private use that cost serious money. I would never use Comic Sans in larger texts. I wouldn't probably use it myself anywhere.
I agree no readability argument. The relatability and tone argument is what I wrote.
SPJ and TS don't have to relate to me, or anyone if they so wish. Just making the point SPJ's argument is quite poor, whatever "brow-level" it exists at.
I agree, it's like clothes, sometimes it is appropriate to dress up if you want people to view what you are saying through a certain lens, wether that is wearing gold cufflinks to your job as a banker or wearing a hoodie to your job at Facebook it all signals something. Computer games are a visual medium, where aesthetics is very important, I'm not sure I would want to signal that I don't care about aesthetics to my audience, presumably quite a few of whom will be designer/programmer/artists type people (whatever you call front end in game dev).
Tim Sweeney is a game development legend. He could put handwriting on these slides and people would read it.
Did HN's reverence for John Carmack drop because he dabbled in rockets, instead of doing "proper programming"? Stars can afford to be eccentric.
I wouldn't recommend slides like these to a normal game developer giving a speech. But it's preposterous to claim that it might hurt Tim Sweeney in any way.
Overall just looked like a more comfy C++ designed specifically for game development.
Correction: the language is called Jai https://inductive.no/jai/ Joi is Ana de Armas AI version.