Rust Is for the Engine, Not the Game
barretts.club
barretts.club
Unless you are dogfooding whatever you create, it will be crap and you are better off not creating in the first place, don't waste everyone's time with stuff you yourself couldn't be bothered to actually use.
I think it definitely would be a good idea if the creators of a space suit wear it and try to do some light DIY with it.
I'm not sure. I can imagine that some programmer would prefer LaTeX, even if they work in the Google Docs team (or the Microsoft Office team). That wouldn't raise much of an eye brow from me: Google Docs isn't exactly aimed at programmers.
I actually think something like the sentiment expressed in https://news.ycombinator.com/item?id=40594627 is approximately true, but it would need quite a few qualifiers.
That entirely depends on what sort of thing you're programming. My current job is programming for industrial equipment. I certainly don't, and won't ever, personally have a use for the software I write, but that software is 100% addressing a real problem.
```rust /// Errors that can occur when loading a dynamic plugin #[derive(Debug, Error)] #[deprecated( since = "0.14.0", note = "The current dynamic plugin system is unsound and will be removed in 0.15." )] ```
Source: https://github.com/bevyengine/bevy/blob/main/crates/bevy_dyn...
I use Rend3/WGPU/Vulkan, which use Rust more or less correctly. My own code is 100% safe Rust. I'm not clear on why so many people have problems with working in safe Rust.
Sure there's some custom reflection and type erasure, but that's mostly to support the highly ergonomic APIs and for optimising ECS layout and access.
There are conversations (maybe even an RFC) around better supporting reflection in the language itself, which would improve the situation a lot. (Edit: some of it linked at the end of the post)
Bevy is quite literally pushing Rust festures and the type system to their limits on multiple fronts, sometimes "exceeding" those limits with custom code. All with the intent of not sacrificing performance or happy path ergonomics. Of course there's going to be some unsafe.
I really should try to pull together my proposal for back references. A big problem in Rust is that if A owns B, B can't have a static reference to A. If you want to do that, you have to make all links to A be Rc references, and have B contain a Rc::Weak reference to A. Then there's a run-time check if you try to make the weak reference into a strong reference temporarily. Usually, the program is set to panic if that fails.
The question is whether a static analysis can determine that such a weak to strong raise will never fail. If that could be proven at compile time, the reference counting would be unnecessary. And Rust could have sound back-references.
If all the places where a weak link is raised to a strong link are bounded by scopes, this is probably do-able. But hard.
OCaml could have done fine in that comparison, based on the critique provided. Also, I haven't tried Zig, but based on what I've read, I do believe it would have been worth an evaluation as well.
"D: Using an Emerging Language in Quantum Break"
https://www.gdcvault.com/play/1023819/D-Using-an-Emerging-La...
You're implying present tense, but from what I remember, the studio gave up on D instantly after Ethan Watson (the guy who gave that talk) left. There have been no mention of D in gamedev in years.
"used by" => in the past
"some of their titles." => 1 or more
And yes, C# was won out over D, in what concens AAA studios.
But that wasn't the point, rather languages missing from OP's list.
Use a high level language for your logic, and a low level one to optimise your hot loop. Have we not learned this lesson already? It is almost always easier to design something at a high level and migrate parts of it downwards as necessary.
I would never use Rust for game design or reactive UI and I don't understand why people are trying to shoehorn Rust into these use cases. They both benefit immensely from global shared state and object-oriented patterns and Rust's correctness makes workarounds harder if not impossible.
That depends on the language. If your language is flexible/multi-paradigmatic, it was designed for you to make it work in all sorts of ways, so there is at least a potential of the code not eing smelly.
> Rust is designed by C++ programmers to service their needs
Rust was originally written in OCaml for someone who wanted to work on a browser engine. So, I'm not quite sure about your characterization. Remember also that different (C++) programmers have vastly different needs.
Rust adds friction to quick prototyping, but OTOH it is particularly good at providing robust, safe library APIs (with machine-checked memory management, lifetimes, sharing across threads, and strong patterns for error handling). It's one of the reasons why Rust applications can easily use so many dependencies.
Rust intentionally makes it difficult to cut corners, and by default enforces all of its best practices around immutability, thread-safety, etc. This is annoying for quickly trying things out for gameplay purposes (central point of the "Leaving Rust gamedev" post), because exploration of gameplay ideas doesn't need bug-free code, it needs to iterate quickly.
But this focus on correctness is the right trade-off when building foundational components and libraries. Applications need to have a stable and reliable platform to build on, and to actually ship they can't have a "prototype-quality" engine.
It's silly that people uncritically accept the narrative that all hopes of getting reflection implemented were lost when JeanHeyd quit the project.
As far as I'm aware, the only thing JeanHeyd posted was an initial design exploration. Not a formal RFC, not code, just some design theory-crafting. That's good, that's something people need to do to advance the language, but it's a little off-putting how some people are treating that writeup like some Graal lost and not like one design exploration among many of its kind.
Especially since that design work would likely have stayed purely theoretical for a while, given that the compiler's team reaction to a similar proposal, variadic generics, was "We won't have the bandwidth to even evaluate the proposal for at least a year".
What I really want is something like a lightweight embeddable C# without the GC:
- A strongly-typed scripting language that's easy to bind with a C++-based game engine core (or Rust/Zig/whatever)
- Guarantees sufficient-enough performance while achieving fast compilation for development builds (very important for gamedev iteration). A possible solution for this would be a bytecode VM, but with the option for AOT compilation when exporting your game.
- Comes without a GC. Options could be to just use plain old reference counting, but also something like what Inko does with runtime-checked dangling references or alternatively what Vale does with with generational references.
- [EDIT] Support for value types (like structs in C#)! Really indispensible when you write any "mathy" gamedev code or trying to bind to C++ data structures efficiently.
It should strive to be familiar for users of the host language, not invent weird new syntax. This is ultimately a personal preference, but what I want is a script-oriented rust: Dispense with some ugly stuff that makes it hard to compile or analyze (borrow checker, macros (maybe), giant core+std libs), but keep enough of the things that make it good (inferred static types, expression oriented, pattern matching).
Regarding the "no GC" point: My idea is to just not store any persistent state inside the script engine. Allocate temporary objects in arenas which only live for the duration of a top-level call. If you want persistent state, expose it through bindings. This has the added benefit of making hot reloading trivially easy -- when there's no state, there's nothing for your hot reloading system to break. There are some pretty obvious pitfalls of this. It could totally blow up in my face, so the door is open to adding optional global state and/or garbage collection down the line.
I have a very(!) minimal prototype, and I've written enough of a compiler before that I'm confident I can eventually produce something that works. Whether it lives up to my aspirations is a different story.
If you want something that actually exists now, maybe look into AngelScript. I haven't personally used it, but it's statically typed and supposedly has good C++ integration.
I also started a side project making a strongly-typed scripting language compiler / VM a few months ago, but it’s currently on hold since I’m trying to not do too much yak shaving. But maybe someday…
I've only ever come to two conclusions. The first is that the cost of garbage collection is much higher than I estimate, but I have seen no empirical proof of that, and many game engines seem to use garbage collected scripting languages without issue. The second conclusion is that Java's lack of value-types means every program needs to allocate small objects like mad and that degrades performance, which has made most people view GC as slower than it would be if you took a C++ program and swapped the calls to new out with calls to some garbage collected allocator. Do you have any insight on this? What profiling have you done to conclude GC performs worse?
I agree that you likely could design and implement an effective garbage collection-based memory allocator for game (engine) use cases. I am certain many successful titles have shipped with something you could call garbage collection.
In my experience, the expected friction / hatred stems from the idea of a (language-level) GC that you as the developer have little to no control over. i.e. it's not about a direct performance cost/penalty so much as 1: a limiting factor or overhead (e.g. if you don't know which frame the penalty occurs you need to reserve time for it in every frame) and 2: the cost of dealing with yet another layer of main loop system synchronisation issues.
The point about value types is relevant, but probably not strictly a GC issue, as you say. Fast value types are absolutely crucial to high performance game (engine) code. Value types to a game developer are stack-allocated. Going to the heap is completely out of the question. Here, "fast" means performance comparable to the basic numeric types.
Keep in mind that outside of Minecraft, Java is not popular for writing games where the high-ish level language of choice is usually C# instead, both with Unity and many other open or closed source engines, that either host it as a gamescript language or, lately, implemented entirely in it.
And this is what confuses me. The opinions of game developers on this seems utterly baseless, and contradicted by the actual practice of the people who write game engines. I've only ever seen one (quite frankly genius) paper[1] on this that explores the question in a satisfying manner, and it suggests that garbage collection has something like a 17% overhead compared with a malloc call, at the cost of 3 times the memory usage. Not great, but it seems like a video game can afford to triple its memory usage given how it works with resources, and also given that a lot of what's allocated will be large assets which won't need to be counted in the 3× overhead since the represent a small number of objects compared to their size.
[1] Matthew Hertz and Emery D. Berger. 2005. Quantifying the performance of garbage collection vs. explicit memory management. SIGPLAN Not. 40, 10 (October 2005), 313–326. https://doi.org/10.1145/1103845.1094836
I tend to treat negatively such academic works because they become outdated fast, and are hard to draw conclusions from.
Allocation in competent GC is explicitly cheaper (it's a 1-2 dereferences, and a pointer bump if allocation context/quantum/pool can satisfy the allocation without asking for more memory for the GC itself or without performing collection), you pay the cost later with mark and sweep, and pause time, but most of all, non-deterministic nature of "batch deallocation" of such kind.
They say "garbage collection is slow" and when I ask how they know, they have no response.
> they are likely to be worse than misleading
> they become outdated fast, and are hard to draw conclusions from.
Out of interest, how many papers have you read and how have you come to these conclusions? What empirical evidence to you have for these claims? I don't dispute that there is a general lack of research around this area, but that hardly justifies discarding the scientific method. Given that many of them implement techniques which can simply be re-run as new runtimes are released, why do we not do this? With proper CI, you could easily keep this information as up-to-date as necessary.
> Allocation in competent GC is explicitly cheaper
I am well aware. When I say "allocation", I refer to the entire lifetime of an object. As in both its allocation, residence in memory, and cleanup. Did you read the paper I cited? It provides a strong case that this "lifetime-cost" of an object can be quantified and measured.
I will read it in full, thanks.
An alternative approach for supporting GC in your game engine, would be to extend C++ on the engine-side to support GC with some black magic (aka Unreal's approach with UObject). But that requires adding an additional hacky transpiler / reflection system on top of C++... which I think has been mostly a net negative in terms of usability (if you've tried using Unreal you'll quickly get what I mean...)
Ever allocated an arena, bumped its pointer for many small allocations and then deallocated the entire thing, efficiently? That’s what Gen0 of .NET’s GC is, and it wouldn’t be an issue in a game.
(Also there's another sibling comment I've wrote that deals with the subtleties of trying to bind a scripting language with a C++ engine core...)
I think it's important to understand the context of where the discourse on "GC in games" comes from - I mentioned in a sibling comment that a lot of perception, at least from Unity side, comes from the fact that in Unity the GC performs (or had performed in the past) really poorly. And, as another comment mentioned, games written in another popular GC language, Java, have little to no avenue in avoiding allocations where even integer operations can lead to data being heap allocated, and requiring the compiler to do a lot of heavy lifting to avoid doing so with escape analysis and packing integers into (compressed) pointer shadows.
Actually, I don't think there is much widespread knowledge on how non-Unity C# performs on its own as a language for both the engine and the scripts, at least here on HN. There are Stride3D (rename from Xenko), Fna, MonoGame (which does not use Mono unlike the name suggests), and probably other I don't know about which use .NET 6/8. I'm not aware of GC related issues for any of these games beyond regular aspects of memory management in games that apply regardless of the platform.
Something to look for is Unity's migration away from their custom Mono fork to CoreCLR .NET as it should eliminate most if not all remaining GC related issues. I find this interesting as .NET's GC implementations (both WKS, SRV and SRV+DATAS) have not been made with games in mind, and a more game-optimized and frame-pacing-aware GC implementation could be definitely provided, at the cost of complexity of doing such project.
See discussions like https://discourse.julialang.org/t/rust-vs-c-and-vs-julia-and... https://discourse.julialang.org/t/should-we-make-a-push-into...
Historically, this situation reminds me of what happened with C++, where continuous fixes led to a convoluted structure that many developers abhor.
It's happening :)
The repo has been archived and now is unmaintained: