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

201–210 of 247 posts

Re: Why Rust Is the Future of Game Development

#201

Post by scythe »

pjmlp wrote: post #178
scythe wrote: post #131

Earlier quoted context omitted.

>Unfortunately, Rust has limitation on what it can prove to be safe using the ownership and lifetimes approach. One of the simplest things which can't safely be done in Rust is a doubly-linked list. It can be done "safely" in Rust, as in without actual bugs; it can't be done in "safe Rust", that is, Rust without `unsafe{}` blocks. But it's reasonable to assume that any Rust game would make liberal use of `unsafe{}` b…

> 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++.

Re: Why Rust Is the Future of Game Development

#202

Post by Arainach »

samatman wrote: post #113
Arainach wrote: post #95

Earlier quoted context omitted.

At this point, does anyone seriously expect JAI to ever be released? It's been 6 years.

I think it's more likely than not, yes. Jonathan Blow has a reputation for taking a rather long time to release something eagerly awaited, and the result being impressive and critically acclaimed. I hope Jai will be the same way. We'll see what happens.

Sure, but that works for a game where you can release it once and then everyone consumes it.

Languages are ecosystems. They have tools, and libraries, and shims to integrate with other tools. They need evangelism. They grow with community involvement. As far as I know, no one has ever released a new language that was perfect in its initial release - there has always been feedback and syntax quirks that get addressed in future versions.

If a "0.1" compiler with warts was out there for people to play with and improve on, I'd have faith. But if you can't get a demo that you're willing to share within 5+ years, then I have very little faith you'll ever release anything, and absolutely zero faith that you'll be able to compromise your mental idea of perfection enough to build a thriving community around a product.

Re: Why Rust Is the Future of Game Development

#203

Post by stcredzero »

gameswithgo wrote: post #139
stcredzero wrote: post #99

Earlier quoted context omitted.

Lack of safety is a feature in game development, because the optimizations required are typically unorthodox and a super strict language slows development down. One of my first experiences interacting with a golang programmer, was in the context of my game server project. As an optimization, I had a race condition in the code that disconnected clients. After all, if the connection is about to die, I don't care if it…

given that a behavior in a race condition can be undefined, he or she may have been right. You might get the merely delayed behavior your want now, but something else on a future version of the compiler. Perhaps you are aware of all these subtleties and knew it was ok in this case.

given that a behavior in a race condition can be undefined, he or she may have been right

If the other party really had an interest in understanding, and not just condemning, he would've looked for more facts. He wouldn't have been talking over me and cutting me off.

Re: Why Rust Is the Future of Game Development

#204

Post by RomeoDelta »

ridiculous_fish wrote: post #187
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…

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 (which can be seen in the example::main section of the output; lines 212-216 look nearly identical, if not identical, to equals_unsafe in your example).

Please let me know if I'm missing something or if there are any other safe APIs to be wary of.

[0] https://rust.godbolt.org/z/W8dqaK

Re: Why Rust Is the Future of Game Development

#205

Post by ncmncm »

shmerl wrote: post #200
ncmncm wrote: post #195

Earlier quoted context omitted.

They have work to do, and tooling to do it with. Show them Rust, and they will say "what can it do that my tooling doesn't?", and then you must be silent.

It means they aren't curious about progress. Not someone you want to hire, unless those who run projects don't care about anything either. And sure, you can explain to them what better tools can offer. That was the point of the linked post. And if they don't want to hear the answer, then again someone probably hired wrong people there.

Game development shops are notoriously cheap. They have to hire people willing to work for peanuts. Like the circus, they take who they can get, from among people who need to be a part of the magic.

Meanwhile, game developers, as a rule, are interested in (surprise!) game development, not languages. What Rust brings to the table, few game developers are looking for. But Rust builds are notoriously glacial, where game developers are wedded to the edit-build-test cycle.

So, gaming will be one of the last places for Rust to thrive. That doesn't mean no games will be in Rust. Rust coders will compete for jobs using it, rather than game shops competing for Rust coders.

Re: Why Rust Is the Future of Game Development

#206

Post by lostcolony »

dxuh wrote: post #174
lostcolony wrote: post #14

Earlier quoted context omitted.

So what in the language prevented them from doing it that way? What in the community ensured they didn't do it that way? Firefox is open source, and yet it still happened. "Best practices" is such a red herring. Best practices = don't write bugs, too; yet there are bugs. You can't evaluate a language in theory and ignore what happens in practice any more than you can with any other thing in life. It's the UX, does it…

> "Best practices = don't write bugs" That's absolutely not what it means. Best practices usually means "don't use these features anymore" and "use these features whenever you can". And that is very reasonable and DOES get rid of a lot of the problems (not all) that are usually associated with C++, but still people don't do it. I blame it many C++-people actually preferring "C with classes" (various code bases openly…

You clearly missed the facetious tone of that part, along with the entire rest of the post.

So let me simplify - if to use a language correctly requires knowing the full history of the language, along with explicitly eschewing some of the key features of the language (except in certain cases when you need them! And they're not deprecated or issue warnings or similar by the compiler), and even extremely experienced developers using the language still make mistakes...the issue is with the language.

Re: Why Rust Is the Future of Game Development

#207

Post by MaulingMonkey »

shultays wrote: post #198
MaulingMonkey wrote: post #196

Earlier quoted context omitted.

> Lack of safety is a feature in game development, Bullshit. How many games have had releases delayed and major wrenches thrown into marketing plans because of progress ruining heisenbugs? How many failed certification passes from banal data races and other undefined behavior? We trap UI in actionscript or javascript, and gameplay programmers in other scripting languages - perhaps python or lua - for faster iteration…

You tell me. How many? I am a game developer that mostly works with c++ and my answer is none so far. The projects delay but nor because of the language. Undefined behavior is c++'s strength. If it was not, we wouldnt have it in the first place

Just counting my personal experience, I've seen multiple titles fail cert and delay release thanks to bug backlogs that were mostly filled with memory issues, even after months of working to reduce the backlog of crash bugs. Perhaps you can't blame that entirely on the C++ codebase, but you sure can't absolve it entirely either.

At every single studio I've worked at I've helped build out crash collecting, symbolizing, or deduplicating infrastructure just to get a lead on where shit is exploding, and seen major productivity outages when tooling crashed frequently enough to disrupt the workflows of my coworkers. Address sanitizer, valgrind, extra debug allocators - I've sunk a lot of time into just making these crashes shallower to debug and quicker to catch.

One of the smallest and quickest projects that comes to mind was an NDS -> iOS and Android port. Do you think most of the time was spent in porting APIs and control schemes? More than half the time on that project was spent just chasing down really stupid memory related crash bugs that were exacerbated in frequency and time by the port. I made damn sure to communicate my concerns about the schedule, and if my memory serves me correctly, we managed to soft launch "only" a week or two late.

C++'s strengths are it's lean portability, speed, and huge existing codebases and tallent pools. Undefined behavior is simply the cost we begrudgingly pay, not it's strength, and even that we often mitigate by trying to figure out ways to write as little C++ as possible - keeping it only for the parts of our codebase that are actually performance sensitive. Tooling is often C#, Python, anything but C++. UB is a pox and constant time sink.

Whenever people call out C++'s UB as it's strength, I'm left wondering how many of their bugs do they actually fix, and how many are begrudgingly fixed by their coworkers. Most of the people whom I've worked with with that attitude don't pull their own weight in the debugging department, so they don't see the full costs of it.

Re: Why Rust Is the Future of Game Development

#208

Post by aw1621107 »

ridiculous_fish wrote: post #187
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…

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'm curious; is the extra cmp something that's actually required by Rust's semantics, or is this more along the lines of an optimizer bug/missed optimization?

Re: Why Rust Is the Future of Game Development

#209

Post by pthariensflame »

aw1621107 wrote: post #208
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'm curious; is the extra cmp something that's actually required by Rust's semantics, or is this more along the lines of an optimizer bug/missed optimization?

The latter, definitely.

Re: Why Rust Is the Future of Game Development

#210

Post by ridiculous_fish »

aw1621107 wrote: post #208
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'm curious; is the extra cmp something that's actually required by Rust's semantics, or is this more along the lines of an optimizer bug/missed optimization?

This particular case is because array delegates to slice for Eq, and slice has the pointer comparison - though it looks like there's some churn here with 'guaranteed_eq' so it may be fixed soon [1].

1: https://doc.rust-lang.org/src/core/slice/mod.rs.html#6610

Post reply on HN