Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Why Rust Is the Future of Game Development

thefuntastic.com

Post reply on HN
Print view View original

211–220 of 247 posts

Re: Why Rust Is the Future of Game Development

#211

Post by Impossible »

nabakin wrote: post #76
Impossible wrote: post #30

Earlier quoted context omitted.

There are some AAA game engine and graphics developers actively using Rust in their main codebase like RAD and Embark, and many are Rust curious and using Rust for side projects or tools. It's true that it will be a while before wide Rust adoption happens in the game industry (if ever) and C++ will stay around for a while. As for tech in games moving slowly... there is some truth to that but some things also move muc…

Chucklefish, the developer of Starbound, uses Rust too. The lead dev on the project gave a great presentation [1] at RustConf. [1] https://youtu.be/aKLntZcp27M

I'm aware of Chucklefish's usage of Rust, but they aren't a good AAA example even if they've shipped some of the most successful indie titles of all time. Also, as mentioned in a sibling comment they have abandoned Rust because the lead programmer that was driving it moved on.

Re: Why Rust Is the Future of Game Development

#212

Post by ridiculous_fish »

RomeoDelta wrote: post #204
ridiculous_fish wrote: post #187

Earlier quoted context omitted.

unsafe is sometimes necessary because Rust's safe APIs are needlessly inefficient. For example, consider a function for 16 byte equality: fn equals(v1: [u8; 16], v2: [u8; 16]) -> bool { v1 == v2 } rustc emits a branch to test if v1 and v2 point to the same thing, which is unnecessary (it can never be true!) and can ruin loop vectorization, etc. The useless branch is not serving any safety purpose but requires unsafe…

I know this is only responding to your one example, and perhaps your statement is still true generally, but I think that in this particular case it is not. In this godbolt [0] I tried using the safe version of equals with two values (from stdin so it can't just optimize the computation away, though I don't think it would) and it seems that when the compiler inlines the equals function, the inefficiencies are removed…

Right, the branch may or may not be optimized out; probably it depends on llvm's alias analysis. That's not good, it means you might break it accidentally.

IME Rust is more dependent than C++ on these fragile optimizations. I think it is because idiomatic Rust is more abstract, and also because C++ has more advanced specialization features which allows implementing optimizations directly. For example in C++ you can say "if the type is uint8_t then do this instead..." but this is harder in Rust.

You asked for other examples: consider a simple operation over an array, like bitwise not. A C-style for-loop does the obvious thing but idiomatic Rust emits a gazillion one-byte 'not' instructions. This doesn't involve 'unsafe' but it does illustrate that you really do have to babysit Rust to get efficient codegen. https://rust.godbolt.org/z/PjW5vo

(In fairness C++ has its own stupid pitfalls too: https://travisdowns.github.io/blog/2019/11/19/toupper.html)

Re: Why Rust Is the Future of Game Development

#213

Post by Iwan-Zotow »

jayd16 wrote: post #15

I think Rust would eat into C++ more than C#. Microsoft is pushing C# and the tooling fairly hard right now. Performance is pretty good and even though Rust seems like a rising star, it won't reach C# levels of tooling for quite some time. I don't think the population of studios that chose C#'s performance and convenience over C++ but would now choose Rust is all that large. But hey, lets start talking about bindings…

Not in a game business, but I could tell you - until Rust is supported (down to debugging) in Visual Studio, there would be no C#/Rust apps, and plenty C#/C++ apps.

Re: Why Rust Is the Future of Game Development

#214

Post by je42 »

naikrovek wrote: post #141
jrsj wrote: post #93

Earlier quoted context omitted.

Isn't this basically saying that you can't have the compiler guaranteeing you aren't including bugs in those optimizations / global variable usage because it's more efficient to just write and then ultimately ship some bugs? To me it seems like this would require a significant adjustment in how certain problems are approached, but the outcome would likely be more effective development as you could eliminate a lot of…

Game development problems are very often global state manipulation problems. In a given game, many things may have genuine need to be able to read and write to multiple global variables once per frame (that's usually somewhere between 30 and 240 times per second), and that is after all unnecessary global state has been removed. Enterprise developers often look very poorly upon the solutions that game developers come…

if your game is riddled with bugs... you make no money or at least less.

further, the whole point of rust is that is fast and safe.

safe doesn't imply slow.

a lot of game development is entity component systems, and there are several of those for rust - it will be a matter of time until these are good and fast enough to be used in larger and larger games.

Re: Why Rust Is the Future of Game Development

#215

Post by lostmsu »

suprfnk wrote: post #151
jayd16 wrote: post #15

I think Rust would eat into C++ more than C#. Microsoft is pushing C# and the tooling fairly hard right now. Performance is pretty good and even though Rust seems like a rising star, it won't reach C# levels of tooling for quite some time. I don't think the population of studios that chose C#'s performance and convenience over C++ but would now choose Rust is all that large. But hey, lets start talking about bindings…

> even though Rust seems like a rising star, it won't reach C# levels of tooling for quite some time. Just curious; what's the tooling gap between Rust and C#, according to you? I work in C# profesionally, and dabble in Rust, and haven't really found Rust tooling lacking yet -- but maybe that's because I'm only working on small hobby projects.

Aren't you using refactoring tools like ReSharper?

Also, what about debugging? C# does edit & continue and allows arbitrary statement execution during debugging. Does Rust debugger even allow moving the instruction pointer at will?

Re: Why Rust Is the Future of Game Development

#216

Post by blackrock »

I can’t imagine programmers wanting to use Rust for games development, especially when there are plenty of alternative languages.

And remember that Rust must go through an LLVM layer.

Instead, what about Nim? Any hopes for this language to become a mainstream games programming language instead? Since it does transpile down to C code.

Re: Why Rust Is the Future of Game Development

#217

Post by pjmlp »

scythe wrote: post #201
pjmlp wrote: post #178

Earlier quoted context omitted.

> potentially faster compile times than C++ when Rust is more mature First cargo needs to also handle binary dependencies, and C++20 has modules now.

The technical progress will be unpredictable as usual, but at the level of the problem definition, I think it's safe to say compiling Rust is easier than compiling C++.

Depends, if the option is between doing it in 5 minutes (thanks binary libraries and pkg-config) or wait 16 minutes (cargo compiling the world).

Re: Why Rust Is the Future of Game Development

#218

Post by RomeoDelta »

ridiculous_fish wrote: post #212
RomeoDelta wrote: post #204

Earlier quoted context omitted.

I know this is only responding to your one example, and perhaps your statement is still true generally, but I think that in this particular case it is not. In this godbolt [0] I tried using the safe version of equals with two values (from stdin so it can't just optimize the computation away, though I don't think it would) and it seems that when the compiler inlines the equals function, the inefficiencies are removed…

Right, the branch may or may not be optimized out; probably it depends on llvm's alias analysis. That's not good, it means you might break it accidentally. IME Rust is more dependent than C++ on these fragile optimizations. I think it is because idiomatic Rust is more abstract, and also because C++ has more advanced specialization features which allows implementing optimizations directly. For example in C++ you can s…

> the branch may or may not be optimized out

That's true, and while I agree that it is a concern, is there ever a way to gain both ergonomics and optimization? In other words, aren't we always leaving it up to the compiler one way or another? You mention C++'s specialization, and I suppose that is a solution, but then you are (potentially, I can't say for certain) sacrificing compile times. Although I will admit that this is probably a fair trade for certainty of optimization, and it would be nice if Rust at least offered some amount of specializing.

> you really do have to babysit Rust to get efficient codegen. https://rust.godbolt.org/z/PjW5vo

Oh wow, that is interesting. Yeah, that probably speaks to Rust still being a relatively new language, although I would have expected LLVM to do something about that... In any case, that's certainly no zero-cost abstraction.

Thanks for the neat info!

Re: Why Rust Is the Future of Game Development

#219

Post by RedComet »

je42 wrote: post #214
naikrovek wrote: post #141

Earlier quoted context omitted.

Game development problems are very often global state manipulation problems. In a given game, many things may have genuine need to be able to read and write to multiple global variables once per frame (that's usually somewhere between 30 and 240 times per second), and that is after all unnecessary global state has been removed. Enterprise developers often look very poorly upon the solutions that game developers come…

if your game is riddled with bugs... you make no money or at least less. further, the whole point of rust is that is fast and safe. safe doesn't imply slow. a lot of game development is entity component systems, and there are several of those for rust - it will be a matter of time until these are good and fast enough to be used in larger and larger games.

Fallout 4 and the latest Modern Warfare beg to differ (with the first point).

Re: Why Rust Is the Future of Game Development

#220

Post by moth-fuzz »

Animats wrote: post #121
gtaylor wrote: post #67

Earlier quoted context omitted.

What makes games more likely to lean on global state than other kinds of applications?

Classic webcrap is near-stateless, with state in the database only. That way, any server in the farm can handle the next client request. Games have a consistent world to maintain in memory. Sometimes a really big consistent world.

I feel like this is an underrated sentiment. A lot of Rust’s design decisions (lack of inheritance, borrow checking, immutability by default) are complete non-issues when you’re reading a JSON string into some business struct or an enum and then serializing it back out to a DB again. Everything can be flat data types and functions can be pure and stateless.

But not if you actually have to keep things around in-memory. Then all the sudden your functions can’t be pure, you have to add additional parameters to each method to account for additional state, and you can’t design flat structs anymore since you have many different object types and they have to go somewhere and you can’t just declare N variables line by line. So you have to grapple with the limited definition of trait objects, or non-extensible enums, or throw everything out and use Any. It gets complicated.

Post reply on HN