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

Migrating away from Rust

deadmoney.gg

Post reply on HN
Print view View original

411–420 of 799 posts

Re: Migrating away from Rust

#411

Post by pcwalton »

jayd16 wrote: post #407
pcwalton wrote: post #311

Earlier quoted context omitted.

But Unity game objects are the same way: you allocate them when they spawn into the scene, and you deallocate them when they despawn. Accessing them after you destroyed them throws an exception. This is exactly the same as entity IDs! The GC doesn't buy you much, other than memory safety, which you can get in other ways (e.g. generational indices, like Bevy does).

You can't do possibly-erroneous pointer math on a C# object reference. You don't need to deal with the game life cycle AND the memory life cycle with a GC. In Unity they free the native memory when a game object calls Destroy() but the C# data is handled by the GC. Same with any plain C# objects. To say it's the same as using array indices is just not true.

> You can't do possibly-erroneous pointer math on a C# object reference.

Bevy entity IDs are opaque and you have to try really hard to do arithmetic on them. You can technically do math on instance IDs in Unity too; you might say "well, nobody does that", which is my point exactly.

> You don't need to deal with the game life cycle AND the memory life cycle with a GC.

I don't know what this means. The memory for a `GameObject` is freed once you call `Destroy`, which is also how you despawn an object. That's managing the memory lifecycle.

> In Unity they free the native memory when a game object calls Destroy() but the C# data is handled by the GC. Same with any plain C# objects.

Is there a use for storing data on a dead `GameObject`? I've never had any reason to do so. In any case, if you really wanted to do that in Bevy you could always use an `EntityHashMap`.

Re: Migrating away from Rust

#412

Post by jandrewrogers »

ryao wrote: post #380
mawww wrote: post #369

Earlier quoted context omitted.

C and C++ do have very different memory models, C essentially follows the "types are a way to decode memory" model while C++ has an actual object model where accessing memory using the wrong type is UB and objects have actual lifetimes. Not that this would necessarily lead to performance differences. When people claim C++ to be faster than C, that is usually understood as C++ provides tools that makes writing fast co…

Try putting objects into two linked lists in C using sys/queue.h and in C++ using the STL. Try sorting the linked lists. You will find C outperforms C++. That is because C’s data structures are intrusive, such that you do not have external nodes pointing to the objects to cause an extra random memory access. The C++ STL requires an externally allocated node that points to the object in at least one of the data struct…

It seems like your argument is predicated on using the C++ STL. Most people don’t for anything that matters and it is trivial to write alternative implementations that have none of the weaknesses you are arguing. You have created a bit of a strawman.

One of the strengths of C++ is that it is well-suited to compile-time codegen of hyper-optimized data structures. In fact, that is one of the features that makes it much better than C for performance engineering work.

Re: Migrating away from Rust

#413

Post by pornel »

fooker wrote: post #48
dist-epoch wrote: post #32

Earlier quoted context omitted.

Quake 1-3 were written for computers where memory was not much slower than the CPU as is the situation today. But yeah, probably you don't need an ECS for 90% of the games.

Memory is sometimes faster today!

In absolute terms yes, but relative to the CPU speed memory is ridiculously slow.

Quake struggled with the number of objects even in its days. What you've got in the game was already close to the maximum it could handle. Explosions spawning giblets could make it slow down to a crawl, and hit limits of the clientserver protocol.

The hardware got faster, but users' expectations have increased too. Quake 1 updated the world state at 10 ticks per second.

Re: Migrating away from Rust

#414

Post by hedora »

Animats wrote: post #231

Another failed game project in Rust. This is sad. I've been writing a metaverse client in Rust for almost five years now, which is too long.[1] Someone else set out to do something similar in C#/Unity and had something going in less than two years. This is discouraging. Ecosystem problems: The Rust 3D game dev user base is tiny. Nobody ever wrote an AAA title in Rust. Nobody has really pushed the performance issues.…

Pin and unpin handle circular references, sort of.

Re: Migrating away from Rust

#415

Post by saghm »

jayd16 wrote: post #407
pcwalton wrote: post #311

Earlier quoted context omitted.

But Unity game objects are the same way: you allocate them when they spawn into the scene, and you deallocate them when they despawn. Accessing them after you destroyed them throws an exception. This is exactly the same as entity IDs! The GC doesn't buy you much, other than memory safety, which you can get in other ways (e.g. generational indices, like Bevy does).

You can't do possibly-erroneous pointer math on a C# object reference. You don't need to deal with the game life cycle AND the memory life cycle with a GC. In Unity they free the native memory when a game object calls Destroy() but the C# data is handled by the GC. Same with any plain C# objects. To say it's the same as using array indices is just not true.

At least in terms of doing math on indices, I have to imagine you could just wrap the type to make indices opaque. The other concerns seem valid though.

Re: Migrating away from Rust

#416

Post by pornel »

maccard wrote: post #272
yyyk wrote: post #56

GC isn't a big problem for many types of apps/games, and most games don't care about memory safety. Rust's advantages aren't so important in this domain, while its complexity remains. No surprise he prefers C# for this.

Disagree on both points. Anyone who has shipped a game in unity has dealt with object pooling, flipping to structs instead of classes, string interpolation, and replacing idiomatic APIs with out parameters of reused collections. Similarly, anyone who has shipped a game in unreal will know that memory issues are absolutely rampant during development. But, the cure rust presents to solve these for games is worse than t…

I'm shocked that Beat Saber is written in C# & Unity. That's probably the most timing sensitive game in the world, and they've somehow pulled it off.

Re: Migrating away from Rust

#417

Post by ArthurStacks »

jokethrowaway wrote: post #357
_bin_ wrote: post #326

Earlier quoted context omitted.

But in rust you have to fight the borrow checker a lot, and sometimes concede, with complex referential stuff. I say this as someone who writes a good bit of rust and enjoys doing so.

Given my experience with Bevy this doesn't happen very often, if ever. The only challenge is not having an ecosystem with ready made everything like you do in "batteries included" frameworks. You are basically building a game engine and a game at the same time. We need a commercial engine in Rust or a decade of OSS work. But what features will be considered standard in Unreal Engine 2035?

Nobody is going to be writing code in 2035

Re: Migrating away from Rust

#418

Post by hedora »

ryao wrote: post #356
jandrewrogers wrote: post #295

Earlier quoted context omitted.

> C instead of C++ because "it's faster" (spoiler: it probably doesn't matter for your project) If your C is faster than your C++ then something has gone horribly wrong. C++ has been faster than C for a long time. C++ is about as fast as it gets for a systems language.

I doubt that because C++ encourages heavy use of dynamic memory allocations and data structures with external nodes. C encourages intrusive data structures, which eliminates many of the dynamic memory allocations done in C++. You can do intrusive data structures in C++ too, but it clashes with object oriented idea of encapsulation, since an intrusive data structure touches fields of the objects inside it. I have neve…

OO (implementation inheritance) is frowned upon in modern C++. Also, all production code bases I’ve seen pass -fno-exceptions to the compiler.

Re: Migrating away from Rust

#419

Post by andrewflnr »

bmitc wrote: post #213
klabb3 wrote: post #204

The fact that people love the language is an unexpected downside. In my experience the rust ecosystem has an insanely high churn rate. Crates are often abandoned seemingly for no reason, often before even hitting 1.0. My theory is this is because people want to use rust primarily, the domain problem is just a challenge, like a level in a game. Once all the fun parts are solved, they leave it for dead. Conversely and…

I find it interesting how the software industry has done everything it can to ignore F#. This is me just lamenting how I always come back to it as the best general purpose language.

Probably the intersection of people who (a) want an advanced ML-style language and (b) are interested in a CLR-based language is very small. But also, doesn't it do some weird thing where it matters in what order the files are included in the compilation? I remember being interested in F# but being turned off by that, and maybe some other weird details.

Re: Migrating away from Rust

#420

Post by pclmulqdq »

Ygg2 wrote: post #101
bigstrat2003 wrote: post #84

Earlier quoted context omitted.

> And split the community and double your maintenance burden. If you choose to support 1.0 sure. But you don't have to. Overall I find that the Rust community is way too leery of going to 1.0. It doesn't have to be as big a burden as they make it out to be, that is something that comes down to how you handle it.

> If you choose to support 1.0 sure. If you choose not to, then people wait for x.0 where x approaches infinity. I.e. they lose confidence in your crates/modules/libraries. I mean, a big part of why I don't 1.x my OSS projects (not just Rust) is that I don't consider them finished yet.

Godot launched 0.1 in February 2014 and got to 1.0 in December 2014.

The distance in time between the launches of Unreal Engine 4 and Unreal Engine 5 was 8 years (April 2014 to April 2022). Unreal Engine 5 development started in May 2020 and had an early access release in May 2021.

Bevy launched 0.1 in 2020 and is at 0.16 now in 2025. 5 years later and no 1.0 in sight.

If you want people to use your OSS projects (maybe you don't), you have to accept that perfect is the enemy of good.

At this point, regulators and legislators are trying to force people to use the Rust ecosystem - if you want a non-GC language that is "memory safe," it's pretty much the de facto choice. It is long past time for the ecosystem to grow up.

Post reply on HN