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

911–920 of 996 posts

Re: Leaving Rust gamedev after 3 years

#911

Post by pc2g4d »

eterevsky wrote: post #710
pc2g4d wrote: post #588

When I set out to learn Rust about a decade ago, I chose to write a game - a clone of "Empire" that I call Umpire. It's a different task to re-implement an already-designed language rather than designing and implementing at the same time. Nevertheless I have run into a number of the difficulties mentioned in the article, and arrived at my own solutions - foremost passing around global UUIDs rather than actual `&` ref…

> Rust's strength in ML Most of ML frameworks that I know are implemented in Python and C++. I tried looking at ML in Rust a few years ago and didn't find anything useful. Has it changed?

You can use libtorch directly via `tch-rs`, and at present I'm porting over to Burn (see https://burn.dev) which appears incredibly promising. My impression is it's in a good place, if of course not close to the ecosystem of Python/C++. At very least I've gotten my nn models training and running without too much difficulty. (I'm moving to Burn for the thread safety - their `Tensor` impl is `Sync` - libtorch doesn't have such a guarantee.)

Burn has Candle as one of its backends, which I understand is also quite popular.

Re: Leaving Rust gamedev after 3 years

#912

Post by fl0ki »

flohofwoe wrote: post #823
Arech wrote: post #809

Earlier quoted context omitted.

[flagged]

Oh I followed the C++ standardization process quite closely for about 15 years up until around C++14 and still follow it from the sidelines (having mostly switched back to C since then), and I'm fully aware of the fact that C++ has designed itself into a complexity corner where it is very hard to add new language features (after all, C++ has added more new problems that had then to be fixed in later standards than it…

It's even worse than that, because even if a new proposal had no concerns from a language & library point of view, it can still be crippled by vendor concerns because of short-sighted, entirely unforced errors the vendors made, often decades prior.

It's part of why I don't believe the C++-compatible C++-successor languages will deliver on their promises nearly as well as they think. They only solve half of the problem, which is that their translation units don't have to accommodate legacy C++ syntax.

They still have to reproduce existing C++ semantics and ABIs, their types still have to satisfy C++ SFINAE and Concepts, etc. so they're bringing all of the semantic baggage no matter what new syntax they dress it in.

And anywhere they end up introducing new abstractions to try to enforce safety, those will be incompatible with C++ enough to require hand-crafted wrappers, just like we already do with Rust, only Rust is much further along its own maturity and adoption curve than those languages are.

Re: Leaving Rust gamedev after 3 years

#913

Post by torginus »

jandrewrogers wrote: post #133
bdw5204 wrote: post #24

My impression of Rust is that it's a very opinionated language that wants everybody to program in a specific way that emphasizes memory safety above everything. That's a good idea, I think, for the systems programming use cases that it was intended for. I don't see that as a particularly useful thing to value for game development. The part in the article about the Rust borrow checker constantly forcing refactors soun…

> 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 indefinit…

This kind of extends to embedded/low level systems programming as well - the assumption that memory can only change as an effect of program execution just does not hold true there. What's the value of tracking mutability and data ownership when a DMA engine can just decide to overwrite the memory you supposedly have exclusive access to?

Re: Leaving Rust gamedev after 3 years

#915

Post by manx »

nu11ptr wrote: post #19

As much as I love Rust I sometimes wonder if I'd be more productive in a simpler language. If I wrote it every day I'm not sure that would be true, but as a hobbyist coming back to Rust sometimes takes me a bit to get back in the zone. Also, still not a fan of async, as it is woefully incomplete and fairly complicated in some use cases. That said, I just can't go back to Go with nil pointers and lack of decent enums/…

Have a look at Scala.

Re: Leaving Rust gamedev after 3 years

#917

Post by cogman10 »

VancouverMan wrote: post #831
cogman10 wrote: post #510

Earlier quoted context omitted.

Ok, do you have a concrete example of this?

I haven't rigorously tracked all of the instances I've seen of this happening over the years, but I've tried to quickly find some more prominent examples for you. This bug report, for example, has various "This comment has been minimized.", "rust-lang deleted a comment from ...", "rust-lang locked and limited conversation to collaborators" interference: https://github.com/rust-lang/team/pull/671 A Reddit thread discu…

Thank you very much for digging these up. I don't have anything more to add these are good examples of bad behavior.

Re: Leaving Rust gamedev after 3 years

#918

Post by Klonoar »

Capricorn2481 wrote: post #855
Klonoar wrote: post #576

Earlier quoted context omitted.

I mean, your comment is actually contributing to the problem. You can 100% criticize the community - and thus push them to clean up that shit - without straying into characterizing it like that. It's fanning the flames and just doesn't really help.

> You can 100% criticize the community - and thus push them to clean up that shit - without straying into characterizing it like that Like what? To criticize a community, you have to characterize it. And of course they didn't say everyone was like this. > Of course, there are many people in the Rust community who are not religious and try to improve the language

Ending with "The church of Rust" alone is farther than is necessary and not a helpful characterization. Programming/tech religious wars are a two way street, we don't need to push them along. ;P

Re: Leaving Rust gamedev after 3 years

#919

Post by zozbot234 »

Toutouxc wrote: post #905
hot_gril wrote: post #579

Earlier quoted context omitted.

Rust has traits on structs instead of using inheritance. Aka composition.

AFAIK composition, in the traditional sense, means that you put your objects/concepts together from different smaller objects or concepts. Composition would be to have a struct Car that uses another struct called Engine to handle its driving needs. A car “has a” engine. A trait that implements the “this thing has an engine” behavior isn’t composition, it’s actually much closer to [multiple] inheritance (a car “is a”…

Traits do implement interface inheritance, but that doesn't have the same general drawbacks as implementation inheritance (such as the well-known "fragile base class" problem).

Re: Leaving Rust gamedev after 3 years

#920

Post by fooker »

Georgelemental wrote: post #868
fooker wrote: post #173

Earlier quoted context omitted.

Perhaps the more appropriate advice is : Use the right tool for the job. Use C++ for writing a high performance library or a database engine. Use Go or Java for writing a server. Use C for writing a kernel module. Use shell scripts for automation. Use python for trying out ML ideas or heavier duty scripts. Use Rust for ... I'm not quite sure what it's the right tool for yet. I suspect it's trying to become the right…

> a high performance library or a database engine > a server Rust is a great tool for these. The focus on performance and reliability (versus fast iteration) is a perfect fit for these domains specifically.

Server, I think you could be right.

Database engine, no way. Look at the internals of modern ones. Very very intricate pointer based data structures that you'll pull your hair out replicating with Rust.

Again, it's not like it's impossible. You can certainly accomplish it by treating it like a puzzle but using the right tool will have better results.

Post reply on HN