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

511–520 of 799 posts

Re: Migrating away from Rust

#511

Post by lostb1t »

janalsncm wrote: post #280
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.…

> These crates also get "refactored" every few months, with breaking API changes I am dealing with similar issues in npm now, as someone who is touching Node dev again. The number of deprecations drives me nuts. Seems like I’m on a treadmill of updating APIs just to have the same functionality as before.

the Js ecosystem is by far the worst offender in this area

Re: Migrating away from Rust

#512

Post by amelius »

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

> Someone else set out to do something similar in C#/Unity and had something going in less than two years.

But in that case doesn't the garbage collector ruin the experience for the user? Because that's the argument I always hear in favor of Rust.

Re: Migrating away from Rust

#513

Post by akoboldfrying »

josephg wrote: post #430
_bin_ wrote: post #297

Earlier quoted context omitted.

I saw a good talk, though I don't remember the name, that went over the array-index approach. It correctly pointed out that by then, you're basically recreating your own pointers without any of the guarantees rust, or even C++ smart pointers, provide.

> It correctly pointed out that by then, you're basically recreating your own pointers without any of the guarantees rust, or even C++ smart pointers, provide. I've gone back and forth on this, myself. I wrote a custom b-tree implementation in rust for a project I've been working on. I use my own implementation because I need it to be an order-statistic tree, and I need internal run length encoding. The original vers…

> Recently I rewrote the b-tree to simply use a vec of internal nodes

Doesn't this also require you to correctly and efficiently implement (equivalents of C's) malloc() and free()? IIUC your requirements are more constrained, in that malloc() will only ever be called with a single block size, meaning you could just maintain a stack of free indices -- though if tree nodes are comparable in size to integers this increases memory usage by a significant fraction.

(I just checked and Rust has unions, but they require unsafe. So, on pain of unsafe, you could implement a "traditional" freelist-based allocator that stores the index of the next free block in-place inside the node.)

Re: Migrating away from Rust

#514

Post by lostb1t »

mtndew4brkfst wrote: post #385
palata wrote: post #257

Earlier quoted context omitted.

If you use Rust with `.clone()` and Arc/Mutex, why not just using one of the myriad of other modern and memory safe languages like Go, Scala/Kotlin/Java, C#, Swift? The whole point of Rust is to bring memory safety with zero cost abstraction . It's essentially bringing memory safety to the use-cases that require C/C++. If you don't require that, then a whole world of modern languages becomes available :-).

For me personally, doing the clone-everything style of Rust for a first pass means I still have a graceful incremental path to go pursue the harder optimizations that are possible with more thoughtful memory management. The distinction is that I can do this optimization pass continuing to work in Rust rather than considering, and probably discarding, a potential rewrite to a net-new language if I had started in somet…

Agree in this, i enjoy Rust and use the same approach.

People are saying rust is harsh, i would day its not that much harder then other languages just more verbose and demanding.

Re: Migrating away from Rust

#515

Post by pjmlp »

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.

While we don't need, we can, that is the beauty of languages like C#, that offer the productivity of automatic memory management, and the tools to go low level if desired/needed.

Re: Migrating away from Rust

#517

Post by whstl »

mjr00 wrote: post #219
doctorpangloss wrote: post #136

Earlier quoted context omitted.

And yet, if making your own game engine makes it intellectually stimulating enough to actually make and ship a game, usually for near free, going 10x slower is still better than going at a speed of zero.

> And yet, if making your own game engine makes it intellectually stimulating enough to actually make and ship a game, usually for near free, going 10x slower is still better than going at a speed of zero. Generally, I've seen the exact opposite. People who code their own engines tend to get sucked into the engine and forget that they're supposed to be shipping a game. (I say this as someone who has coded their own e…

I disagree with this assessment.

After 30 years participating in Gamedev communities I feel like the "don't build an engine" was always an empty strawman aimed at nobody in reality.

The Venn diagram between the people interested in technical aspects of an engine and in also shipping a game is probably composed of a few hundred individuals, most of them working for studios.

The "kid that wants to make an engine to make an MMO" is gonna do neither. It's just a meme.

I shouldn't really care about it myself, but I do because Unity sucked the air out of every gamedev discussion and now there are almost no spaces to discuss anything advanced (even if it's applicable to Unity/Unreal/Godot).

Re: Migrating away from Rust

#518

Post by lenkite »

josephg wrote: post #430
_bin_ wrote: post #297

Earlier quoted context omitted.

I saw a good talk, though I don't remember the name, that went over the array-index approach. It correctly pointed out that by then, you're basically recreating your own pointers without any of the guarantees rust, or even C++ smart pointers, provide.

> It correctly pointed out that by then, you're basically recreating your own pointers without any of the guarantees rust, or even C++ smart pointers, provide. I've gone back and forth on this, myself. I wrote a custom b-tree implementation in rust for a project I've been working on. I use my own implementation because I need it to be an order-statistic tree, and I need internal run length encoding. The original vers…

One can also use this array-index approach in C++, utilize the `at` methods and have "memory safety guarantees", no ?

Re: Migrating away from Rust

#519

Post by palata »

BigJono wrote: post #495
nayuki wrote: post #457

Earlier quoted context omitted.

> GC pauses aren't really acceptable Java has made great progress with low-pause (~1 ms) garbage collectors like ZGC and Shenandoah since ~5 years ago.

People have 240hz monitors these days, you have a bit over 4ms to render a frame. If that 1ms can be eliminated or amortised over a few frames it's still a big deal, and that's assuming 1ms is the worst case scenario and not the best.

What about the C# garbage collector? Is it much better? Because Unity is in C#, right?

Re: Migrating away from Rust

#520

Post by palata »

internetter wrote: post #290
lolinder wrote: post #267

Earlier quoted context omitted.

I have a personal-use app that has a hot loop that (after extensive optimization) runs for about a minute on a low-powered VPS to compute a result. I started in Java and then optimized the heck out of it with the JVM's (and IntelliJ's) excellent profiling tools. It took one day to eliminate all excess allocations. When I was confident I couldn't optimize the algorithm any further on the JVM I realized that what I'd b…

I'd rather write rust than java, personally

Note that I mentioned JVM languages. There is Scala, Kotlin and others. Kotlin is the default for Android, and it is really nice.
Post reply on HN