Leaving Rust gamedev after 3 years

> I'd expected some AAA title to be written in Rust by now.

I'm disinclined to believe that any AAA game will be written in Rust (one is free to insert "because Rust's gamedev ecosystem is immature" or "because AAA game development is increasingly conservative and risk-averse" at their discretion), yet I'm curious what led you to believe this. C++ became available in 1985, and didn't become popular for gamedev until the turn of the millenium, in the wake of Quake 3 (buoyed by the new features of C++98).

The "async" system is optimized for someone who needs to run a very large web server,

Even there it's very problematic at scale unless you know what you're doing. async/await isn't zero cost, regardless of what people will tell you.

I'd expected some AAA title to be written in Rust by now.

Why? Those kinds of game engines are enormous amounts of code, and there's little incentive to rewrite.

I do strongly disagree that we aren't ever going to see large-scale game development in Rust; it just takes time. Whether games adopt an engine is largely about that engine's maturity rather than anything about the language. Bevy is quite young; 0.13 doesn't even have support for animation blending yet (I landed that for 0.14).

* There are very few people doing serious 3D game work in Rust. There's Veloren, and my stuff, and maybe a few others. No big, popular titles. I'd expected some AAA title to be written in Rust by now. That hasn't happened, and it's probably not going to happen, for the reasons the author gives.

At one point the studio behind the Finals was writing game server code in Rust with an Unreal engine client. Not sure if that's true still

The "async" system is optimized for someone who needs to run a very large web server, with a huge number of clients sending in requests.

Can you please elaborate on this? I see a lot of similar concerns in other contexts too. Linux kernel's scheduler for example. Is it a throughput/latency tradeoff?

"I tend to agree about the "async contamination" problem. The "async" system is optimized for someone who needs to run a very large web server, with a huge number of clients sending in requests. I've been pushing back against it creeping into areas that don't really need it."

100% this. As I say elsewhere in these threads: Rust is the language that Tokio ate. It isn't even just async viral-chain-effect, it's that on the whole crates for one async runtime are not even compatible with those of another, and so it's all really just about tokio.

Which sucks, if you're doing, y'know, systems programming or embedded (or games). Because tokio has no business in those domains.

I'd expected some AAA title to be written in Rust by now. That hasn't happened, and it's probably not going to happen, for the reasons the author gives.

The main reason is that you can't ship that Rust code on PS5 in a sensible manner. People have tried, got useless toys to compile, but in the end even Embark gave up. I remember seeing something from them that they had moved Rust to server-only.

I'm happy to see someone still doing some work in second life.

I tend to agree about the "async contamination" problem.

Argh I have the same issue. Sure if you write JS or Python you probably need async. My current Java back end that has like 5 concurrent users does not need async everything making 10x the complexity.

My priorities are reasonable performances and the fastest iteration time possible.

I bought Mount & Blade II Bannerlord in 2020-03-30. I love it to death, but come on...

  // 2024-02-01
  $ curl https://www.taleworlds.com/en/News/552 | grep "Fixed a crash that" | wc -l
  29

  // 2023-12-21
  $ curl https://www.taleworlds.com/en/News/549 | grep "Fixed a crash that" | wc -l
  6

  // 2023-12-14
  $ curl https://www.taleworlds.com/en/News/547 | grep "Fixed a crash that" | wc -l
  101

Edit: Lol guys calm down with the down-vote party. I was counting crashes, not bugs:

  $ curl https://www.taleworlds.com/en/News/547 | grep "Fixed a bug that" | wc -l
  308

As a non-game dev who uses Rust and Elixir, Rust wouldn't be my first pick for a large gamedev studio for multiple reasons. As for alternatives worth evaluating: Crystal, Cython (compiled Python), or Nim could result in increased gamedev productivity over C++ or C#. Maybe even Go because the iteration and compile times are very fast, and the learning curve is very low.

a flexible enough programming structure, moving things around and changing your mind about the most desirable approach several times a day is common during heavy development phases.

That's the kind of code for which Rust-like languages shine. Rich type systems make it easy to change your mind about things and make large changes to your code with confidence.

(Whether Rust tooling is actually at a level to take advantage of that is another question)

It is a different story for game engines, renderers, physics, audio, asset loaders etc. those are much closer to system programming but this is also not where we usually spend the most time, as a professional you're supposed to either use off-the-shelf engines or already made frameworks and libraries.

But this is where industry interest (the little there is) lies for Rust, is it not? This is what the AAA studios that are researching and prototyping are working on.

C++ is not a popular language to implement the actual game in for all the reasons you list. It is too slow to compile and too rigid. The people who actually build the games, make them tick, are all working in visual scripting languages.

Also, ECS is, IMHO, a useful pattern for some systems, but it is a pain in the butt to use with gameplay or UI code.

I'd love to see a language built around ECS. I wonder how nice it can be in a language syntax where ECS is the easiest thing you can do.

I had similar thoughts, about Rust being a good match for game engines but not games. Maybe it suggests Rust game engines might want to include an interpreter for some higher level language to actually do the gamedev in.

Rust is pretty good for writing PL interpreters (and similar tooling) too, actually.

I know you're not asking for recommendations, but Lisp, particularly SBCL, really seems to check all your boxes. I say this as someone who generally reaches for Scheme when it comes to Lisps too.

There are a few game engines[0] for CL, but most of them seem to be catered specifically to 2D games.

[0] https://github.com/CodyReichert/awesome-cl?tab=readme-ov-fil...

Also, ECS is, IMHO, a useful pattern for some systems, but it is a pain in the butt to use with gameplay or UI code.

Not a game developer, but each time I tried to make one not using ECS(or something at least similar in spirit) I quickly found myself not being able to proceed due to the sheer mess in the codebase.

How does one normally avoid that?

And my other biggest problem is that they keep painting other non-Rust things as being fundamentally flawed for not being Rust. "It's not memory safe" is the biggest one thrown around, but when was the last time memory safety was actually a big problem in games? Unity uses C# which is garbage collected, Godot uses its own scripting language which makes it nigh impossible to leak memory, Unreal AFAIK has its own tools that makes memory management trivial. Rust game development feels like a solution looking for a problem to fix.

Memory safety may or may not be important in games, but the ability of engines like Bevy to analyze system dependencies and automatically scale to multiple CPUs is a big deal. Job queuing systems have been popular in gamedev for a very long time, and Rust's insistence on explicit declaration of mutability is a big part of the reason that "just works" in Bevy.

I'm a Rust fan (mostly for embedded firmware with minimal deps), but even after 10 years of playing with the language it's not clear to me that advanced GUI or gamedev fits well with the borrow checker. It requires a significant paradigm shift in architecture, and I'm not convinced it's worth making that shift, especially if your application can tolerate a garbage collector (which many games and most UI apps can).

Now I'm wondering how far people could go a hypothetical Rustscript* that transpiles to Rust (or hooks into rustc?), introduces extra features such as reflection, removes lifetimes, and changes the defaults around things like monomorphization.

* name intentionally made to make people angry

Rust game development feels like a solution looking for a problem to fix.

The same can be said for ordinary CRUD backends. Java, C#, Go and Typescript (Node, Deno or Bun) are all memory safe with good type systems and more than good enough performance. Evangelism around Rust is unfortunately still a thing. A good example is the latest hype in the community because some Google Manager said at a Rust conference that writing Rust is as fast as writing Go. Anyone having done more than a toy program in Rust and Go knows how wrong this statement is. The reasons are given in the article.

Just a small addition: Godot also has great C# support. It is a real charm to work with.

but when was the last time memory safety was actually a big problem in games? Unity uses C# which is garbage collected, Godot uses its own scripting language which makes it nigh impossible to leak memory, Unreal AFAIK has its own tools that makes memory management trivial.

So.... Sounds like memory safety is indeed a problem? Otherwise why do so many solutions exist for it?

Yeah, Rust definitely is not the only solution, or perhaps not even a good solution to this problem in the context of game development. But let's not pretend the problem itself doesn't exist?

As I said in my own comment down thread, despite being a huge rust advocate, I sincerely agree with you here.

Rust is not a good language for actually writing games, and the fact that it is being sold as such is really detrimental to it in my opinion, because it is holding the ecosystem back. Rust is being pushed as a language for game logic, so people try out and realize it isn't very good at that, and so they just give up on Rust in the game development industry at all and leave, understandably! If Rust were more strategically positioned, it could get a lot farther. Where it should be focusing in the games industry is on game engines, where flexibility and quick iteration and easy prototyping and being able to just reach out and directly touch and control things isn't as important, but where concerns like the clarity and maintainability of the code base, stability of the software, resource ownership and management, and eeking out every ounce of performance all become important, and so the type system and static analysis guarantees of Rust are actually useful.

This is where, I'm disappointed to say, I think things like Bevy and Amethyst have severely hurt the Rust game development ecosystem. They aren't really game engines in the traditional sense, they are more like game frameworks like Love2D except written in Rust: they force you to statically link your game code to the engine code, and write your game logic in the same language your engine is written in. This means that game developers who just want to quickly prototype game mechanics and want to be able to iterate on them in order to refine them are forced to use a language that is far too focused on correctness, safety, static verifiability, and concerns like that to actually be usable as a programming language, and worse, it forces them to compile their game logic and the entire engine together and link them together in order to build their actual game and test it, massively increasing the weight of the process and basically ruling out hot reloading or making your game independent of any specific version of the engine, or its license. It puts them between a rock and a hard place, between using some other ecosystem, or using a language that simply unsuitable for a game development.

I think the far better solution (one which I plan to very slowly feel out with my embryo engine project, which is born out of my frustration of looking at the existing rust game engines and feeling like they are all kind of lying about what they are) would be to stop with the vaporware and the hype with Bevy and Amethyst and such, and actually build a proper game engine, like they are promising to be but are not, that is its own separate pre-compiled executable that game developers don't even need to mess with at all, that picks up game assets and game code written in a more flexible, dynamic, language that's better for prototyping, and runs them, something like what Unity or Godot or even Gamebryo do. Only then will the rust game development ecosystem take off, because it will no longer be forcing a language that just isn't good for that on to people.

We're doing more and more of our back-end work with Rust. The main reason is the performance it provides. It's not just great for our end-users it's also so much cheaper in the modern world where we pay per mileage in the cloud. Part of what we really like about Rust, however, is actually exactly the variable ownership because it makes it very straight forward to enforce and control data-integrity and avoid race conditions. Even for programmers who would struggle to do so in C or C++.

I'm not sure whether or not that's even useful in game development. I've never done any form of game development beyond some Chess game I programmed in my first year of CS 30 years ago. But I'm actually really curious as to why you've struggled with variable ownership, because I'd frankly like to improve our on-boarding processes even more for new hires.

my other biggest problem is that they keep painting other non-Rust things as being fundamentally flawed for not being Rust

Rust has a cult and it's best not to pay too much attention to it. Don't get me wrong, we're seeing great benefit in not just using Rust over C/C++ but also replacing more and more of our C# and Python services with it, but it's a very immature language and like any other programming language it's still just a tool. If it works for you, use it, if not... Well, use something that does.

This might be controversial, but "Safety" and "Speed", in the same ecosystem, are not free. The cost is heavy syntax and heavy cognitive climbs. Why Rust was ever sold as a language for the masses is beyond me. A safe, fast, hard language is something you use for operating systems, aircraft, etc.

I adore Rust because it does all the things I remember being told to do in C, but without me remembering to do them: Error codes from all functions, Ownership models, etc. But those are not good reasons for me to use it for anything I wouldn't use C for.

Rust ain't Go but anything Go has can be used as an argument that Rust should try to do better in certain areas. ;)

Perhaps learn another language like Haskell, Swift, or Kotlin before Rust.

Get cargo-bloat, cargo-cache, and cargo-outdated.

Setup a memcache server and use sccache to accelerate Rust, C, and C++ compilations. It's not 100% but it's pretty awesome for things compiled at a stable build location.

Just like any platform, avoid dependencies wherever possible and use minimal crate features. Some Rust crates have an npm-like problem of dragging in zillions of dependencies.

Garbage collection causes performance issues.

I just can't go back to Go with nil pointers and lack of decent enums/ADTs/pattern matching either.

Go is simply a badly designed language where the idea of "simplicity" has been maligned and proven bad ideas likes nil/null, exceptions and such have been introduced in a seemingly modern language. One would think that decades of Java, Javascript, etc. code blowing up because of this issues would teach someone something but seems that is not always the case.

Isn't that just Swift/Kotlin?

I mean.. Java is there. Java 23 is really interesting.

Maybe people will make fun of me, but I've been very happy with Kotlin and Dart. Null-safe, good ergonomics, very fast.

I've tried Rust, sometimes play with C, D, Deno/TS, Nim, Java (actually I still write lots of it) and even some more cutting-edge stuff, like Unison. While they're cool, what I want is a language with really good tooling that gets out of my way without letting me write patently dumb code (like Java lets me use any object without checking for null, when it can be null but the language just doesn't give a shit to help me).

I use Dart when I want to compile to binary executable or use Flutter, and Kotlin for stuff I think the JVM has more to offer, like a server. The two languages are just a pleasure to use, pretty similar but having completely different ecosystems (which is great, you can use the best one for the job!).

For me, the closest language currently is F#.

The open-source ecosystem is not as massive as Go's or the JVM's, but it's not niche either. F# runs on .NET and works with all .NET packages (C#, F#, ...). If the .NET ecosystem can work out for you, I recommend taking a closer look at F#.

F# allows for simple code, which is "functional" by default, but you're still free to write imperative, "side-effectful" code, too.

I find this pragmatic approach works extremely well in practice. Most of my code ends up in a functional style. However, once projects grow more complex, I might need to place a mutable counter or a logging call in an otherwise pure function. Sometimes, I run into cases where the most straightforward and easy to reason about solution is imperative.

If I were confined to what is often described as a "pure functional" approach, I'd have to refactor, so that these side-effects would be fully represented in the function signature.

F# ticks the enums/ADTs/pattern box but also has its own interesting features like computation expressions [0]. I would describe them as a language extension mechanism that provides a common grammar (let!, do!, ...) that extension writers can target.

Because of this, the language doesn't have await, async or any other operators for working with async (like C# or TS). There's an async {} (and task {}) computation expression which is implemented using open library methods. But nothing is preventing you from rolling your own, or extending the language with other computation expressions.

In practice, async code looks like this:

  let fetchAndDownload url =
    async {
        let! data = downloadData url // similar to C#: var data = await downloadData(url);

        let processedData = processData data

        return processedData
    }

Metaprogramming is somewhat limited in comparison to Scala or Haskell; but still possible using various mechanisms. I find that this isn't a big issue in my work.

IDE-wise, JetBrains Rider is a breeze to work with and it has native F# support. There is also Visual Studio and VS Code with Ionide, which are better in some areas.

You can run F# in Jypiter via .NET Interactive Notebooks (now called "Polyglot Notebooks" [2]). I haven't seen this mentioned often, but this is very practical. I have a combination of Notebooks for one-off data tasks which I run from VS Code. These notebooks can even reuse code from my regular F# projects' code base. Over the past years, this has almost eliminated my usage of Python notebooks except for ML work.

[0]: https://learn.microsoft.com/en-us/dotnet/fsharp/language-ref...

[1]: https://github.com/demystifyfp/FsToolkit.ErrorHandling?tab=r...

[2]: https://marketplace.visualstudio.com/items?itemName=ms-dotne...

Rust is in a separate class of go and swift and kotlin and etc. The class it competes on is pretty C, C++, and itself.

Yes it's easier to write trivial code in python than Rust. Yes it's harder to manage memory manually than it is to let a gc handle it. I don't see the point.

Rust is a systems programming language. It's hard to write a server in it than it is to hack something in node, but it will also be faster and more reliable. Conversely, it's easier than writing it in C++ or C, while still being more reliable. That's the whole value proposition.

I've been hoping to see more languages that compile to Go, it might be the most practical way to arrive at what you want. For example, see Borgo: https://news.ycombinator.com/item?id=36847594

As much as I dislike many of the legacy issues with JavaScript I find TypeScript to be the best language to iterate with. If Rust had GC without need for wrappers like RC though I think that would be my preferred iteration language. I mostly try to write my TS in a manner that would translate to Rust, but that's hard to do sometimes when it comes to memory management.

It doesn't occupy the same space, but the simplicity of Gleam has been very enjoyable to me. It's still quite a young language though, but worth keeping an eye on.

Yeah I long for a language that has rust enums and pattern matching but none of the async or borrow checker.

Maybe I should just unsafe rust and see how I go....

OCaml could be that language.

I’m not convinced that ecosystem is so important for game dev. Once you have a simple graphics library, bindings to BulletPhyiscs etc most of the code is custom simulation code with no integrations needed.

this reminds me of Lispen of ye olde.. wait untill it clicks, man!

Parts of the Rust community are toxic indeed, but I've been around long enough to recognize the same pattern in communities of other hot programming languages or frameworks in their up-and-coming phase.

There's something about the new hot language/framework/paradigm that always attracts the type of people who wrap their identity up in the hot new thing. They take any criticisms of their new favorite thing as criticisms against themselves, and respond defensively.

What I see now in certain Rust communities feels a lot like what I saw in Golang communities in the early days. I had similar experiences when React was the new kid on the block, too.

Some of these communities/forums are just inhabited by people who thrive on dunking on noobs all day long. The good news is that they tend to get bored and move on when the next new thing comes out.

I'm already seeing this in my local Rust community as the chronically online people are moving on to Zig now. They even use one of the Rust discords to advertise their Zig meetups and proselytize about Zig at every opportunity. Eventually they'll get bored and move on.

> That being said, there is an overwhelming force in the Rust community that when anyone mentions they're having problems with Rust the language on a fundamental level, the answer is "you just don't get it yet, I promise once you get good enough things will make sense".

I don't fully agree with this assessment. In my experience, Rust community members who arrive with well thought out complaints or suggestions are welcomed by the people who like working on programming language fundamentals. You can nerd snipe a lot of Rust enthusiasts by showing up with a difficult problem involving tricky parts of Rust, which will often result in some creative solutions and discussions.

On the other hand, Rust communities are inundated with people trying to write Rust as if it was their old favorite language. I've spent a lot of time trying to get people to unlearn habits from other languages and try to adopt the Rust way of doing things. Some people refuse to let go of paradigms once they've used them for years, so doing things the Rust way isn't going to work for them. I've worked with enough people who spent more time fighting against Rust than trying to adopt Rust ways of doing things that I've also reached the point where I don't engage once I see the conversation going that way. Can't please everyone.

> The problem you're having is only a problem because you haven't tried hard enough.

And it actually does work that way with Haskell, in my experience. There's a big hill to get over where you flail against the type system, IO monad and all, and then you realize that, while Haskell's type system isn't perfect, being able to say

    Num t => (t -> b) -> [t] -> [b]

But Haskell isn't for every problem in the way Rust is apparently made out to be. For example, I've seen some posts about developing games in Haskell, but it isn't common, and nobody would try to push a game developer into using Haskell.

Rust is a language with a very high mental cost to use effectively. It requires some fundamental paradigm shifts in the way you write software, hence it's a hard language to be productive in.

For some tasks, the tradeoff is worth it. Some individuals are naturally very inclined to use it.

But for most people, for most tasks, it's simply not the right tool. It's not a general purpose language by any stretch of the imagination.

This was my biggest problem with rust, the community is, at a surface level friendly, but the moment you try to say something against the grain you get met with some of the most insufferable people ever. I tried to mention a problem with a lint on the official forms and the replies were so condescending (from regulars at that too). And at no point did they try to understand the issue, they just assumed I was dumb/new/doing something wrong.

Sounds like a no-true-Scottsman fallacy

> The problem you're having is only a problem because you haven't tried hard enough.

You just need to read another 50,000 word fasterthanlime essay. Then you'll not have problems any more.

I'm reminded of a line from Hachiman in Oregairu: "Something is only a problem when someone makes it a problem."

IMO it’s not opinionated enough. Golang for example doesn’t let you customize go fmt, while Rust does. Rust also has many ways to do things in general (mod.rs vs name_of_folder.rs for example) and seems to not want to provide a useful baseline for most projects via its standard library (unlike Golang).

But to go back to our subject: Rust is a great language and that’s all you need. I wish I could use it with unity.

I just don't think the kinds of security bugs you get from C/C++ "unsafe" code are that big of a deal for games but they would be for a web site or an enterprise database.

Even for database engines specifically, modern C++ is essentially as safe as Rust and significantly more ergonomic. Rust's safety features can't reason about the case when all of your runtime objects live in explicitly paged memory with indefinite lifetimes and no fixed memory address, which is the norm in database kernels. You have to write the same code to make handling these objects safe and correct in Rust that you have to write in C++. You can't use normal pointers and allocators for this even if you wanted to.

Rust's safety is designed more for normal dynamic memory applications.

You more or less described Zig

My impression of Rust is that it's a very opinionated language

It's not though. There's only one thing Rust is opinionated about.

that wants everybody to program in a specific way that emphasizes memory safety above everything.

Well yes, that is literally the core proposition and purpose of the language. That's like saying java is opinionated because it wants to manage the memory.

I just don't think the kinds of security bugs you get from C/C++ "unsafe" code are that big of a deal for games

As soon as games are networked it starts being a problem, and these days non-networked games are pretty rare.

  > I'd think that an ideal game dev language would be programmer time efficient, reasonably performant and designed for skilled programmers who can handle a language filled with footguns. Basically a better version of C such as a selective subset of C++ or a Golang without garbage collection.

There is a sweet spot : non-GC, with pointers (but bounded), inference, basic OOP + tacking, and all the comforts of scripts. All in a good looking syntax without semi-colons.

So you can program fast and get a fast program.

Most modern languages are memory safe and they don't get called out for emphasizing that or being opinionated. I think with Rust that attention results from its choice of memory management model which gets in the way a lot in ways described in the article.

incendiary responses to rust criticism can be

I've not experienced this. Do you have examples of the rust community flaming someone for having negative opinions about the language?

I think I just read about 10 versions of this comment on this page, and definitely not a single response to the criticism that could be described as incendiary. I don't think I even saw a single comment just now that fundamentally pushed back on the premise of this article, let alone in an incendiary way. It's early yet, and maybe this thread will look very different in a few hours though?

This is a textbook example of poisoning the well. [0] We see it used in every discussion about pros and cons of a language on HN.

It's some variation of "People who like this language can't handle criticism/are part of a cult/etc." The idea being that this will preclude anyone from responding to a criticism, because that would confirm the comment.

[0] https://www.logicallyfallacious.com/logicalfallacies/Poisoni...

I know rust, I don't know game development (I've dabbled slightly). If I choose to build a game I either need to make it work in rust* or I need to learn a new language (Unity -> C#, Unreal -> blueprints, Godot -> gdscript).

So your advice to "just use Unity/Unreal/Godot" is the opposite of your advice "you should stick with what you know" in my case. I suspect the former is good advice, and the latter is therefore wrong.

* For the sake of argument, we can pretend I only know rust. In reality I know a fair number of other languages as well, but the list doesn't happen to include C# or "random game engine specific scripting language", which seems to be the options if we're going with an established engine for big 3d games.

Advice should be - you should do what you like and try to align it with your client (employer) - otherwise you'll burnout rather quickly.

When all you have is a hammer, everything looks like a nail. When all you have is programming expertise, all your game production obstacles look like programming problems.

I think everyone in games has met an “engine person” who spends a lot of time iterating on tech, but never quite getting to the creative expression that got them in the game. I think part of it comes a bit from mythologizing breakthrough games like DOOM, where cool technology made something completely fresh. We begin to think that emulating id Software is how you make compelling art, ignoring the latter half of Kushner’s novel.

you need to make a strong up-front decision

Can one always realistically do so? I suspect the underlying unspoken assumption is that one must be ideally informed about all the possible potential pitfalls and gotchas they may face when using any given technology. Aka having a very good (ideally, perfect) knowledge of the technology and its surrounding ecosystem.

It wasn't just once or twice when I've picked some very promising library or tool only to learn something isn't exactly as I hoped (or as it was advertised - docs can lie, too) after I've already spent some non-negligible time implementing something with it. Save for some teenage keyboard mashing some decades ago I'm not a game developer, but I suspect this is universal experience no matter the niche.

Developers often fall in the (2) camp but don't admit it.

There's also a mixed approach, where people admit "I want to build this thing and use this technology, and I suspect they're a potential good match so I'm gonna try both at the same time". Any even slightly creative person must have an urge to learn and explore new things, even if they aren't exactly necessary for a task at hand. Checking on the promise, if it holds true - sometimes it does and you get a new tech you love, quite frequently it doesn't and you have a bad day.

How about "I'm building this thing and I want it to enjoy the unique combination of performance and memory safety offered by this technology"?

It's certainly close to (1), but also a perfectly rational way to be a The Rust Way fundamentalist avoiding refcounting and unsafe who appears suspiciously (2).

The "rewrite in Rust" meme surely does not come from thin air and there is certainly some skill honing and challenge seeking involved. But perhaps a rewrite ever couple of decades isn't all that bad? And if it isn't, could there be a better time for it than "in Rust"?

This is what I like to call the artist vs engineer dilemma.

1. An engineer solves problems, learning and using tools. 2. And artist learns and uses tools, for the sake of it.

Neither is wrong, and some times they benefit each other. I believe much of academia and research is heavy on the artist side. You just have to be clear on which one you are at any given point.

I'm not gonna use assembly for my $JOB where we need some basic web backend. That's not gonna stop me from trying on my free time tho.

I'm in the 1 camp. After several decades of C++ I know it very well. Well enough to find some of the things that those Rust and Ada people are saying about their respective languages intriguing. I'm at the point where I need to spend some time with each to see how/if they work with my problems in the real world. Because eventually you have to admit that while you can drive a screw with a hammer there are other ways and maybe it is time to learn how to use a screwdriver.

I've been playing around with an idea about OOP for awhile, not sure if it'll ring true or not but I'll run it up the flagpole for feedback.

I think FP is a great way to program actions and agency but OOP is a great way to model the world. I like Rust's trait system because the polymorphism is based on what you want an object to do not what it is. But when you're creating models of the world it's usually really convenient and even accurate to use nested inheritance models. Maybe the original system for this is the flora/fauna taxonomy but it applies to a lot of things; like GUI elements or game models.

If this is correct, it might explain why the discourse is so polarized. Whether OOP is a blessing or a curse probably depends on whether you're using a programming language as a modelling language or as a logic/execution language.

Absolutely agree. I think people saw that a lot of games are written in C++ and got confused into thinking that the right thing to do is to build your entire game in a systems language. The fact that we have games written entirely in C++ is mostly just due to the enormous amount of inertia that game engines have, and the fact that many of them have origins that go back decades to a time when the programming language landscape and broader development ecosystem were completely different.

And now, the most popular generally available game engines right now are: Unity - C++ in the engine, C# for game code Godot - C++ in the engine code, GDScript or C# for game code Unreal - C++ in the engine code, somewhat mangled C++ for game code BUT with also one of the most capable and widely used visual programming setups I have ever seen

I wouldn't be surprised if the "next great game engine" had a Rust core and some other language- I mean why not C# at this point?- for game code.

This makes a lot of sense. Wonder if Bevy will add support for GDScript or C# or something. I think it's generally opposed in the interest of ensuring the Rust devex is as good as possible, but it's coming eventually, I think.

> but also with a sense of misplaced religious purity regarding the evils of state

To clarify, Rust isn't against state at all. Rust bends over backwards to make mutation possible, when it would have been far easier (and slower, and less usable) to have a fully-immutable language. What Rust is against is global mutable state, and an aversion to global mutable state isn't a religious position, it's a pragmatic position, because global mutable state makes concurrency (and reasoning about your code in general) completely intractable.

Isn’t the trait system exactly the way out of this tar pit?

YMMV, but I find C# and TypeScript to have a "Goldilocks" mix of OOP and FP that you can take advantage of the strengths of each where it makes sense.

Type checkers shouldn't get in the way of your code compiling.

I don't get it, what's the point of type checking if not to reject invalid programs? The point of a type system isn't simply to add annotations to a programmer (and some type systems can omit them entirely) but to define the subset of programs that are correct within the set of all the programs that can be expressed.

I understand (and have used in production) optionally/gradually typed languages, and without fail codebases will opt for using types up front and not ignoring type check failure because they are always incorrect.

A type error is the compiler/run time telling you "I don't understand what you told me" so why do you want to ignore that?

And if the point is that you want to be able to change the type signature of something without having to refactor giant chunks of code, then that suggests your code is structured poorly to begin with. It should be easy to pull in what you need and play with it without affecting everything else if you haven't done a bad job of architecting the codebase.

There are at least a few nascent statically typed languages (as in, full static typing rather than gradual) which nevertheless let code with type errors compile for the sake of testing.

The two that I know of are Darklang [0] and Roc [1] which aim to let you compile code with type errors for the same reason you suggest.

[0] "Dark is designed for continuous delivery. As such, we don’t like requiring you to make large scale changes across your program, like changing a type everywhere. Instead, we want you to quickly discover that bad ideas won’t work, without first requiring you to propagate the type changes throughout your program."

https://blog.darklang.com/real-problems-with-functional-lang...

[1] "If you like, you can run a program that has compile-time errors like this. (If the program reaches the error at runtime, it will crash.)"

https://www.roc-lang.org/friendly

It's also pointless to care about types in fine-scoped code. Like if your language forces me to assert that i is an integer like this, something is wrong...

  for (int i = 0; i < n; i++) 

I think most people here understand that a language that is great for kernel development isn't necessarily great for everything else.

... complains about people using tropes and tired cliches in posts while using the worst of them, themself

Rust is already in Windows: https://www.reddit.com/r/rust/comments/12yg3cp/microsoft_rew...

Linux added Rust support: https://docs.kernel.org/rust/

Well, as far as I can tell, in the big language shootout (which is still the only decent language benchmark I know, but if you have others, I'd be happy to read them), in all the individual benchmarks I've looked at Rust is either first or within 3% performance of being first. So, this suggests that Rust is actually pretty good for raw performance.

In addition, I know that I'm way more productive for prototyping and iteration in Rust than in C, C++ (and I used to write C++ code professionally for a while), JavaScript, Go, Python (and I've been writing professionally in these three languages for a while now) etc. I _might_ be more productive in Java or OCaml. Yes, this is entirely anecdotal and it depends heavily on the kind of problems you're dealing with. I tend to focus on problems that have complicated invariants, and for which reproducing/pinpointing the issue in a debugger is a big annoyance.

Google, fb, amazon, etc. use C/C++ to squeeze the most performance out of anything I/O heavy, and security is not an issue that deep in the stack, that's not the exploitation layer.

Interestingly, all these companies are migrating some of their systems to Rust. This suggests that they find the language convincing enough.

Ok, we're going from a bunch of complaints about Rust being bad for fast prototypes for indie development to the idea that Rust is bad at everything. This is silly.

"Syzbot and the Tale of a Thousand Kernel Bugs" [1] is my favorite talk on this subject. The Linux kernel is adding security bugs faster than they can be fixed. This is an unsustainable situation--it is not "good enough"--and nobody really has any ideas to significantly improve things beyond adoption of memory safety.

[1]: https://www.youtube.com/watch?v=qrBVXxZDVQY

No, I'm not concerned with Linux/BSD/macOS performance, it's pretty good (I took Windows out because it does have performance issues [0]!). What I am concerned about is security bugs, memory errors, buffer overflows etc, all of the things Rust attempts to solve [1].

I think for weapons & flight control, ATC systems, we already have Ada that's designed for "can't fail systems".

[0] https://www.blobstreaming.org/former-microsoft-developer-say...

[1] https://www.zdnet.com/article/microsoft-70-percent-of-all-se...

Anyone really unhappy with Linux/BSD/Windows/macOS performance?

I wasn't unhappy with Windows' performance in the 90s until I saw BeOS. This is the kind of thing we're in the dark about what could be because the faster, rewritten fron scratch, free from API baggage systems are nowhere to be found.

Personally I think operating systems (kernels) should be as performant as possible, and C/C++ has been good enough for decades.

If that how you want your OS, that's fair enough. But I think a lot of people are happy to trade (to some degree, at least) performance for security, and would prefer that their OSs are as secure as possible first, and as performant as they can be second.

Well the problem with Jonathan's argument here is that he's spent the past decade mostly ranting about Rust and working to make a perfect game programming language, instead of making games.

So it turn out that even if he's opinion on Rust is correct, he would still have been much more productive using it than trying to build his own language for a decade…

(But he already shipped his masterpiece and he's a millionaire so he gets to chose his full time hobby as he wishes)

There is a better, more recent clip of him where he explain 'would we haven chosen rust, the witness would never been finished'.

The blog post reminded me of a quote from Jonathan Blow as well. I forgot the exact wording, but basically he said that Rust makes you treat every state of the project to be production ready (e.g. free of memory safety bugs), but in game development, most of the time the project needs not to be production ready, and for a good reason (rapid prototyping). You just have to fix the really bad things (crushing bugs) before shipping.

Seems like Rust was the wrong tool for the job.

Sure, but the problem is when you have a community around that tool that insists otherwise.

Exactly!

Yeah, I rather like the pattern of embedding a more rapid iteration scripting language on top for game stuff like Lua or stripped down Python variants, using Rust as the core and hot loop code. That said, there is a lot of folks wanting to do it all in Rust, and the article touches pretty well on that not being the pleasant case for a lot of valid gamedev approaches.

I would think a modern systems language such as Rust wouldn't require a systems development methodology from the 1970's. There's no inherent reason you shouldn't be able to rapidly prototype a system and then refactor the prototype into your actual implementation.

I think about Starcraft from 1998, created when virtually all PCs only had one core, and its 200 unit per faction cap. Blizzard hasn't increased this cap because it doesn't necessarily make the game more fun.

Ah... Starcraft. It's 200 supply per player (hero units take 0 supply, zerglings are 0.5, and the supply cost goes up to 8 for battlecruisers for example). The limit is enforced when building a unit from a building. Map triggers can grant units and you can exceed the 200 supply limit.

The technical unit limit for the map was 1700, and was later in fact extended to 3400 by Blizzard. The EUD emulator (part of the official SC Remastered) allows for online custom games to be played without any third party tools on the player's part. Certain limits like sprites can be bypassed with this tool (for map makers) https://github.com/phu54321/euddraft/blob/master/plugins/unl...

EUD started out as a buffer overflow exploit which allowed custom maps to patch the game client's code. It was later fixed by blizzard but re-implemented as an emulator (with some restrictions).

These are definitely things that enhance gameplay for custom scenarios. https://youtu.be/HEv_U9WV4PA?t=1541 (yes, that is a battlecruiser shooting nukes)

I think about Starcraft from 1998, created when virtually all PCs only had one core, and its 200 unit per faction cap. Blizzard hasn't increased this cap because it doesn't necessarily make the game more fun.

That small scale was exactly why the game ends up being so much about micro, and while that may make it more competitive or interesting for spectators it makes it a lot less fun to play IMO. Total Annihilation and successors were a lot more fun, and a big part of that was not having arbitrary unit caps in a way that affected gameplay; expanding the limit from 500 to 1500 did genuinely make the game more fun.

CPUs are way way faster, but RAM latency has barely improved in the past couple decades. That's why cache-optimized systems like ECS can still be a dramatic improvement when you're simulating a lot of stuff. Like, thousands of active objects.

Likewise - I've been learning Rust for four years now (significant C/C++/Python/Lua experience), and have written some reasonably complex apps in it, but I really just didn't get the Bevy / ECS "hype"...

I've tried to write several different types of games using it (with Bevy) in the past three years, and it just feels like shoe-horning something in.

But the biggest complaint I have with Bevy is that with all the refactoring that's been needed with the Bevy version upgrades: getting the code to compile again after the version upgrades has normally been fairly easy - but it then often didn't work correctly, and I'd have to spend time debugging the ECS system to work out what was wrong.

i.e. the "if it compiles, it'll almost certainly work" bonus of generic Rust code totally seems to fall down within Bevy.

I obviously understand that it's an in-development framework, in its early days, so some of that's on me for choosing it, but still, it's been a very painful experience, and I feel I've wasted a fairly significant amount of time over the past few years attempting it.

Many people are choosing Rust because they want to use Rust. Rust has the reputation being "the best" programming language: Fast, safe, reliable, modern. I can rely on that very much. Who wouldn't like the feeling of using the best tech for their project.

What many overlook is that using Rust has very high costs, but the edge over alternative languages is often only marginally - depending on the use case of course.

Those costs of Rust get in the way of developing the actual product. You loose speed, efficiency, but potentially gain no benefit to the users of your product.

but few games will actually leverage this effectively for fun gameplay

In my opinion this is a result of big mobs having poor performance. When players get to choose they seem to like having more mobs thrown at them.

This can also be limiting for interactable objects.

There's decades of work to catch up on

First you gotta get OpenGL going, with its horrible stateful API, give up on it and go to DirectX9. Do a complete rewrite when DirectX10 comes out. Get your real-time lighting happening with shadow volumes, run into patent issues and get strong-armed into putting Creative sound into your game. Cycle between GLSL, HLSL, and Cg. End up switching to shadow mapping anyway. Drop Linux and Mac support. Start over with Vulkan/Metal.

I don't think Rust needs to relive most of that.

* I don't see Rust becoming a truly great language for games unless it's blessed by Epic or Unity.

Which will never happen

The hardest part of a project is finishing it. I think the main issue is the fun problems to solve happen very early in the project and once those are done it becomes incredibly tedius and boring and I usually lose focus until the project dies. Its difficult to maintain motivation.

IMO one language can sidetrack you more than another. It might not be the main problem but a language that gets in the way for your usecase causes you to focus on the wrong problem. Making a good game is really hard and really needs you to focus outside the tech.

Yep.

Bikeshedding, how many angels can dance on the head of a pin, and https://xkcd.com/927/ are some ways of loosely describing what you said.

https://en.m.wikipedia.org/wiki/How_many_angels_can_dance_on...

but I still find it strange that so many people are so strongly focused on what their favourite language can do (usually better than others), instead of the project they're working on.

Yes, if they are so convinced of that, why are they not back in the office or at home, working busy as a beaver on their project, using that great programming language, the benefits of which they extol?

Smells fishy to me.

Oops.

Do people see what I did there? ;)

Totally agree

My unpopular programming opinion: languages aren't that interesting to me

I'm much more interested in the problem being solved and algorithms in the abstract sense

Rust is not antithetical to iteration-based programming, it just makes you write a lot of heavy boilerplate to explicitly support that kind of style. The flip side of that is once the 'iteration'/'prototyping' phase is over, you can actually refactor the prototype into high-quality production code, instead of either throwing it away altogether and rewriting it from scratch (spoiler alert: this doesn't really happen most of the time, because it's viewed as pointless waste) or just putting it in production as-is (which is what people actually do, even though it's obviously a disaster in the longer run).

I copied this exact same snippet and was going to comment the exact same thing.

Why choose Rust if you don’t care about maintainability and long term stability? Those are core values of the language!

The language choice was wrong from the start. C++ is king for games so if you care more about delivering features and fast prototyping why not go with that?

Maybe Rust is not a good language for rapid iteration in the game industry. And that’s ok I think.

I've ended up with similar thoughts about automated testing in games too.

I really enjoy having automated tests and automated tests solve problems. Like, I absolutely love our molecule test suite for our infrastructure code and it gives us huge value. The smoke tests we have for the infrastructure running after deployments are amazing. It's liberating in an environment of rapid and chaotic changes everywhere, complex interdependencies, as well as pressure on top.

However, if I try to transfer that kinda approach to a game it just... fails?

But the realization is: In games, many behaviors and systems are actually far simpler and less intertwined in arcane ways, and code changes actually less frequently and dramatically than at work.

I could see structured testing in e.g. turn based strategy games and such, so you can test that the culture per turn is correctly calculated based off of many different situations and such.

But in many smaller projects I've had, you write some janky code, make sure the enemy behaves as expected... and never touch or change that piece of code ever again. And it just doesn't break, because no fundamental part below it ever changes, because then the entire house of card would fall apart.

It feels dang weird, but it works very well for smaller projects.

It's a weird concept to "care about programming". Same as "inadequate code". I find this statement really condescending and completely confirms some of the cliché quotes that the author write in this article

It's said that software is never finished, only abandoned, but games actually do get finished. And at that point any maintainability is absolutely irrelevant. It's just very different to web programming.

I mean, if you agree that the ideal for bevy would be lua integration, you are kinda agree with the author that Rust itself is suboptimal (at least in layer of game scropting), don't You?

When will an editor be added?

That’s what’s holding me back from jumping into Bevy.

I actually think Rust is really hard, but I also think it would be beneficial to my career.

Would it be possible to create a generic way to script Bevy? I'm sure there are a lot of people who are going to want to use C#, C++, or something else. I could imagine running a runtime in-process and Bevy communicating with it over a socket.

As for ECS, it's not really about upsides or downsides. It's about the fact that Rust effectively forces You to use ECS everywhere, because 'normal' game objects interacting won't fly under borrow checker.

And no matter how many upsides ECS can have, being forced to use it everywhere, rather when You want to, is the painfully part.

Did you read the part where they said that they're a two-person indie game studio with a development cycle of 3-12 months max?

I had this same pain point though when using Rust that was meant to run in the browser (compiles to WASM), i.e. guaranteed to be single-threaded. Still had to pay the very high price of accessing global state in Rust. Ended up moving that code to JS instead just to avoid that!

To be fair, many (non-game dev) Rust projects I have seen/used do provide great user experience precisely because they are laser-focused on performance and have blown existing alternatives out of the water. (Think ripgrep, fzf, etc.)

Prototyping is certainly necessary but it shouldn't be at the cost of runtime performance – at least not too much –, because it will typically be very difficult to improve performance after the fact, which web development frameworks, and in particular shitty "web" applications like MS Teams are a testament to.

As always, it's about balance.

User experience is ultimately all that matters.

It should be but current state of web will show you that it is often not.

Someone who has experienced real problems as a result of a specific mechanism is not required to solve every single problem with alternatives to that mechanism before saying "this mechanism has caused me real problems and it'd be nice if there were a better alternative that didn't cause those problems".

The moment you allow this, you have to find a way to pick between several implementation - and they don't always have sane names.

There are other possible solutions that don't involve that.

For instance, many applications would be quite happy with "There can be only one implementation", giving a compiler error if there's more than one.

A slightly more sophisticated rule would be "Identical implementations are allowed and treated as a single implementation". This would be really convenient in combination with some kind of "standalone deriving" mechanism, which would generate identical implementations wherever it was used.

I agree, and D with the GC lets me prototype quickly. Its type system gets progressively stricter with constraints, for code that survives. I wouldn't want all the type system to apply to prototype code or a nascent program.

When ever I watch someone coding C(++) all they do is compile and then add remove * and & or change between -> and . when the compiler complains.

Multiply that by all the C(++) coders on the planet and we have lost a billion man hours...

In the same idea in Eiffel in a.b, b can be either a member or a function to allow easy replacement.

On the opposite other languages want to have no hidden function call, no hidden pointer dereferencing..

You could hack the C compiler!

https://github.com/tsoding/tic-tac-toe-auto-deref

https://www.youtube.com/watch?v=yKI-VOBBFu8

The power of attributes and get/set in languages like C# is similar. It's easy to turn value types into functions. Or to move a value into a subclass and you don't need to do a.b.c (moved c into b) because you can add c => b.c to the a class.

That's a good example. I actually think dot syntax is really under-utilized sometimes. Although personally, I'd prefer that if v was a reference/pointer to a struct, that v.b simply performs a pointer offset, instead of auto-dereferencing like ->.