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

Leaving Rust gamedev after 3 years

loglog.games

Post reply on HN
Print view View original

881–890 of 996 posts

Re: Leaving Rust gamedev after 3 years

#881

Post by afiori »

pcwalton wrote: post #877
afiori wrote: post #838

Earlier quoted context omitted.

The article is not saying that Bevy does not parallelize but that the impredictability of parallelism (both in ordering and in timing) forces the developer to add enough dependency constraints that there is not much left to parallelize.

The fact that 100% of the CPU is being used, and multiple systems are executing in parallel, shows otherwise.

Both I and the author agree with that, but it was not the point:

> the impredictability of parallelism (both in ordering and in timing) forces the developer to add [...] dependency constraints

The fact that it is possible to make a benchmark without hitting this problem does nothing to prove that bigger games can avoid it too.

Hitting 100% CPU means nothing unless those cores are doing things you actually want them to do.

Re: Leaving Rust gamedev after 3 years

#882

Post by suby »

estebank wrote: post #857
suby wrote: post #740

Earlier quoted context omitted.

If you're removing lifetimes from the script, I'm not sure how you're then transpiling to Rust, unless you wrap everything with reference counting, at which point you're better off using a language with GC.

I would assume that it would opportunistically try to run the borrow checker, and if it fails on the access of a specific field, turn that access into an Arc/Rc everywhere, leaving any other access as references. This leaves you with invisible performance cliffs, where accessing a field in a new place suddenly increases the cost of accessing it everywhere else, but it does give you the "just do what I want, damn it!"…

Thanks for the reply, it's an interesting idea.

Re: Leaving Rust gamedev after 3 years

#883

Post by pigpang »

zozbot234 wrote: post #848
flohofwoe wrote: post #843

Earlier quoted context omitted.

TBF, unsafe Rust still enforces much more correctness than C or C++ (Rust's "unsafety" is more similar to Zig than C or C++).

TBF this is not really true. Unsafe Rust is a lot harder than comparable C/C++, because it must manually uphold all safety invariants of Safe Rust whenever it interacts with idiomatic Rust code. (These safety invariants are also why Safe Rust can often be compiled into better-optimized code than the idiomatic C/C++ equivalent.)

Unsafe Rust is not harder or safer than C/C++. If you can uphold all safety invariants for C/C++ code (OMG!), then it will be easier to do same thing for unsafe Rust, because Rust has better ergonomic.

Re: Leaving Rust gamedev after 3 years

#884

Post by flohofwoe »

zozbot234 wrote: post #848
flohofwoe wrote: post #843

Earlier quoted context omitted.

TBF, unsafe Rust still enforces much more correctness than C or C++ (Rust's "unsafety" is more similar to Zig than C or C++).

TBF this is not really true. Unsafe Rust is a lot harder than comparable C/C++, because it must manually uphold all safety invariants of Safe Rust whenever it interacts with idiomatic Rust code. (These safety invariants are also why Safe Rust can often be compiled into better-optimized code than the idiomatic C/C++ equivalent.)

With more enforced correctness of Rust (also unsafe Rust) I mean small details like Rust not allowing implicit conversion between integer types. That alone eliminates a pretty big source of hidden bugs both in C and C++ (especially when assigning a wider to a narrower type, or mixing signed and unsigned integers).

All in all I'm not a big fan of Rust, but details like this make a lot of sense (even if they may appear a bit draconic at first) - although IMHO Zig has a slightly better solution by allowing implicit conversions that do not lose information. E.g. assigning a narrower to a wider unsigned integer type works, but not the other way around.

Re: Leaving Rust gamedev after 3 years

#885

Post by baby »

metaltyphoon wrote: post #876
baby wrote: post #803

Earlier quoted context omitted.

mod.rs is better, change my mind

Sure, open 5 tabs named mod.rs, so which mod are you in?

Open 5 libs.rs, which crate are you in? Always look at full path instead of filename. A mod.rs means a much more cleaner organization, as you know that all of a folder module's content is within that module, and you don't have to look elsewhere.

Re: Leaving Rust gamedev after 3 years

#886

Post by baby »

metaltyphoon wrote: post #879
sullyj3 wrote: post #602

Earlier quoted context omitted.

Which is which and why?

mod.rs came first and that made creating modules verbose as hell. Not only that but imagine having many mod.rs files open, you wouldn’t know what module you are in by just looking at the filename.

imagine having many lib.rs open?

Re: Leaving Rust gamedev after 3 years

#887

Post by erikbye »

dgellow wrote: post #765
erikbye wrote: post #208

Earlier quoted context omitted.

Well aware, and it affects none of my points.

You asked: > What systems are we talking about that benefits from Rust? Advanced weapon systems that should absolutely not fail? Controllers for air planes? Traffic controllers? Radar? Power grid? You seem to be listing niche, specialised systems where a failure would be critical. But a simpler answer that is missing: mainstream operating systems — as I said, both Windows and Linux have been investing in Rust. Mainly…

And only time will tell us how that plays out.

Re: Leaving Rust gamedev after 3 years

#888

Post by belinder »

110bpm wrote: post #863
belinder wrote: post #541

Earlier quoted context omitted.

Do you know of or have any shareable (sample) projects implemented in your way of doing F#? It sounds very intriguing to me

While the libraries and techniques I mentioned above seem to be well-known, I couldn't find a good public sample project. I can recommend https://fsharpforfunandprofit.com/ as a starting point. If there's interest, I can split some of my code into stand-alone chunks and post my experience of what worked well and what didn't. I wanted to share some thoughts on here on what brought me to F#. Maybe this can serve as a s…

Thanks so much for your detailed reply. This looks very cool indeed. I've had a couple tiny projects in F# in the past that never went anywhere, but you're describing essentially all the parts in a programming language that I want, early returns, binds/maps, language support for these features, defining your own keywords (not really but kinda with your expressions)

Excited to try this out

Re: Leaving Rust gamedev after 3 years

#889

Post by GTP »

germandiago wrote: post #866
zozbot234 wrote: post #848

Earlier quoted context omitted.

TBF this is not really true. Unsafe Rust is a lot harder than comparable C/C++, because it must manually uphold all safety invariants of Safe Rust whenever it interacts with idiomatic Rust code. (These safety invariants are also why Safe Rust can often be compiled into better-optimized code than the idiomatic C/C++ equivalent.)

I wonder if Rust is killing flies with canons (as we say in spanish). There are perfectly safe alternatives or very safe ones. Even in a project coded in Modern C++ with async code included, activating all warnings (it is a cards game) I found two segfaults in like almost 5 years... It can happen, but it is very rare at least with my coding patterns. The code is in the tens of thousands of lines of code I would say,…

I'm not answering your question here, just saying my opinion on C++ vs Rust. I think that the big high-level difference (before diving into details like ownership and the borrow checker) is that C++'s safety is opt-in, while Rust's safety is opt-out. So in C++ you have to be careful each time you allocate or access memory to do it in a safe way. If you're working in a team, you all have to agree on the safe patterns to use and check that your team members are sticking with it during code rewiews. Rust takes this burden from you, at the expense of having to learn how to cooperate with the borrow checker.

So, going back to your question, I think that the answer is that it depends on many factors, including also some non-strictly-technical ones like the team's size.

Re: Leaving Rust gamedev after 3 years

#890

Post by zozbot234 »

germandiago wrote: post #866
zozbot234 wrote: post #848

Earlier quoted context omitted.

TBF this is not really true. Unsafe Rust is a lot harder than comparable C/C++, because it must manually uphold all safety invariants of Safe Rust whenever it interacts with idiomatic Rust code. (These safety invariants are also why Safe Rust can often be compiled into better-optimized code than the idiomatic C/C++ equivalent.)

I wonder if Rust is killing flies with canons (as we say in spanish). There are perfectly safe alternatives or very safe ones. Even in a project coded in Modern C++ with async code included, activating all warnings (it is a cards game) I found two segfaults in like almost 5 years... It can happen, but it is very rare at least with my coding patterns. The code is in the tens of thousands of lines of code I would say,…

> What I am saying is that an evolution of the C++ model is much more ergonomic and less viral than this ton of annotations with a steep learning curve where you spend a good deal of your time fighting the borrow checker. So my question is:

That "evolution of the C++ model" (the C++ Core Guidelines) has an even steeper learning curve than Rust itself, and even more invasive annotations if you want to apply it across the board. There is no silver bullet, and Rust definitely has the more principled approach to these issues.

Post reply on HN