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

271–280 of 799 posts

Re: Migrating away from Rust

#271

Post by neonsunset »

palata wrote: post #255
wffurr wrote: post #237

Earlier quoted context omitted.

>> a bit as if people went for C++ instead of a JVM language "because the JVM is slow" (spoiler: it is not) The OP is doing game development. It’s possible to write a performant game in Java but you end up fighting the garbage collector the whole way and can’t use much library code because it’s just not written for predictable performance.

I didn't mean that the OP should use Java. BTW the OP does not use C++, but Rust. This said, they moved to Unity, which is C#, which is garbage collected, right?

C#/.NET has huge feature area for low-level/hands-on memory manipulation, which is highly relevant to gamedev.

Re: Migrating away from Rust

#272

Post by maccard »

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 the disease it seems. I don’t have a magic bullet either..

Re: Migrating away from Rust

#273

Post by maccard »

peterashford wrote: post #222
mamcx wrote: post #214

This can be summarized in a simple way: UI is totally, another world. There is not chance for any language, not matter how good is it, to match the most horrendous (web!) but full-featured ui toolkit. I bet, 1000%, that is easier to do a OS, a database engine, etc that try to match QT, Delphi, Unity, etc. --- I made a decision that has become the most productive and problem-less approach of make UIs in my 30 years do…

I disagree. The issue, which the article mentions, is iteration time. They were having issues iterating on gameplay, not UI. My own experiences with game dev and Rust (which are separate experiences, I should add) resonate with what the article is expressing. Iterating systems is common in gamedev and Rust is slow to iterate because its precision ossifies systems. This is GREAT for safety, it's crap for momentum and…

This is why game engines embedded scripting languages. Who gives a crap if the engine takes 12 hours to compile if 80% of the team are writing lua in a hot reload loop.

Re: Migrating away from Rust

#274

Post by yuriks »

forrestthewoods wrote: post #115
queuebert wrote: post #30

Earlier quoted context omitted.

> The ownership model of Rust can not represent the vast majority of allocations. What allocations can you not do in Rust?

Gameplay code is a big bag of mutable data that lives for relatively unknown amounts of time. This is the antithesis of Rust. The Unity GameObject/Component model is pretty good. It’s very simple. And clearly very successful. This architecture can not be represented in Rust. There are a dozen ECS crates but no one has replicated the worlds most popular gameplay system architecture. Because they can’t.

Which part of that architecture is impossible in Rust? Actually an honest question, I'm wondering if I'm missing something.

From what I remember from my Unity days (which granted, were a long time ago), GameObjects had their own lifecycle system separate from the C# runtime and had to be created and deleted using Destroy and Create calls in the Unity API. Similarly, components and references to them had to be created and retrieved using the GetComponent calls, which internally used handles, rather than being raw GC pointers. Runtime allocation of objects frequently caused GC issues, so you were practically required to pre-allocate them in an object pool anyway.

I don't see how any of those things would be impossible or even difficult to implement in Rust. In fact, this model is almost exactly what I used to see evangelized all the time for C++ engines (using safe handles and allocator pools) in GDC presentations back then.

In my view, as someone who has not really interacted or explored Rust gamedev much, the issue is more that Bevy has been attempting to present an overtly ambitious API, as opposed to focusing on a simpler, less idealistic one, and since it is the poster child for Rust game engines, people keep tripping over those problems.

Re: Migrating away from Rust

#275

Post by dudinax »

WD-42 wrote: post #250
VWWHFSfQ wrote: post #226

Earlier quoted context omitted.

Rust is very easy when you want to do easy things. You can actually just completely avoid the borrow-checker altogether if you want to. Just .clone(), or Arc/Mutex. It's what all the other languages (like Go or Java) are doing anyway. But if you want to do a difficult and complicated thing, then Rust is going to raise the guard rails. Your program won't even compile if it's unsafe. It won't let you make a buggy app.…

This argument goes only so far. Would you consider querying a database hard? Most developers would say no. But it’s actually a pretty hard problem, if you want to do it safely. In rust, that difficultly leaks into the crates. I have a project that uses diesel and to make even a single composable query is a tangle of uppercase Type soup. This just isn’t a problem in other languages I’ve used, which granted aren’t as s…

My feeling is that rust makes easy things hard and hard things work.

Re: Migrating away from Rust

#276

Post by CooCooCaCha »

doctorpangloss wrote: post #136
12_throw_away wrote: post #110

More than anything else, this sounds like a good lesson in why commercial game engines have taken over most of game dev. There are so many things you have to do to make a game, but they're mostly quite common and have lots of off-the-shelf solutions. That is, any sufficiently mature indie game project will end up implementing an informally specified, ad hoc, bug-ridden implementation of Unity (... or just use the inf…

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.

My experience is the opposite. Plenty of intellectual stimulation comes from actually making the game. Designing and refining gameplay mechanics, level design, writing shaders, etc.

What really drags you down in games is iteration speed. It can be fun making your own game engine at first but after awhile you just want the damn thing to work so you can try out new ideas.

Re: Migrating away from Rust

#278

Post by neonsunset »

lostmsu wrote: post #266

Related: just tried to switch to Rust when starting a new project. The main motivation was the combination of fearless concurrency and exhaustive error handling - things that were very painful in the more mature endeavor. Gave up after 3 days for 3 reasons: 1. Refactoring and IDE tooling in general are still lightyears away from JetBrains tooling and a few astronomical units away from Visual Studio. Extract function…

> 3. In contrast to .NET and NuGet ecosystem, non-Rust dependencies typically don't ship with precompiled binaries, meaning you basically have to have fun getting the right C++ compilers, CMake, sometimes even external SDKs and manually setting up your environment variables to get them to build.

Depending on your scenario, you may want either one or another. Shipping pre-compiled binaries carries its own risks and you are at the mercy of the library author making sure to include the one for your platform. I found wiring up MSBuild to be more painful than the way it is done in Rust with cc crate, often I would prefer for the package to also build its other-language components for my specific platform, with extra optimization flags I passed in.

But yes, in .NET it creates sort of an impedance mismatch since all the managed code assemblies you get from your dependencies are portable and debuggable, and if you want to publish an application for a specific new target, with those it just works, be it FreeBSD or WASM. At the same time, when it works - it's nicer than having to build everything from scratch.

Re: Migrating away from Rust

#279

Post by palata »

artursapek wrote: post #260
palata wrote: post #208

I really like Rust as a replacement for C++, especially given that C++ seems to become crazier every year. When reasonable, nowadays I always use Rust instead of C++. But for the vast majority of projects, I believe that C++ is not the right language, meaning that Rust isn't, either. I feel like many people choose Rust because is sounds like it's more efficient, a bit as if people went for C++ instead of a JVM langua…

Install Gentoo

As I said, I use Gentoo already ;-).

Re: Migrating away from Rust

#280

Post by janalsncm »

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.

Post reply on HN