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

631–640 of 996 posts

Re: Leaving Rust gamedev after 3 years

#631

Post by neonsunset »

philosopher1234 wrote: post #605
paulddraper wrote: post #534

Earlier quoted context omitted.

Go is infamous for its gc latency spikes, which is the thing that games cannot tolerate. Though 1.18 helped a lot, you'd have to do some major persuasion to game devs that Go's gc is the kind of thing they'd want in their game. --- EDIT: Not sure the downvote, Go is know for its (historically at least) unsuitability for RTC or game dev.

I’ve heard that go has very low latency gc, i haven’t heard of it having spikes

The problem with Go is its inadequate FFI, which is important for gamedev which tends to be FFI and syscall-heavy due to embedding another gamescript language and/or calling into underlying rendering back-end, sometimes interacting with input drivers directly, etc.

Which is why C# has been chosen so often (it has performance not much worse than C++ (you can manually optimize to match it), zero or almost zero-cost FFI, and can also be embedded, albeit with effort).

There are also ways to directly reduce GC frequency by writing less allocation-heavy code, without having to resort to writing your own drop-in GC implementation (which is supported but I haven't seen anyone use that new API just yet aside from a few toy examples, I suppose built-in GC is good enough).

Re: Leaving Rust gamedev after 3 years

#632

Post by valcron1000 »

akavi wrote: post #70
BoorishBears wrote: post #23

Earlier quoted context omitted.

Isn't that just Swift/Kotlin?

It's any of: Rust + (garbage collector) Swift + (cross platform support) Kotlin + (proper pattern matching) Unfortunately, none quite hit that central sweet spot, IMO

Well, Kotlin + (proper pattern matching) = Scala

Re: Leaving Rust gamedev after 3 years

#633

Post by gpm »

sullyj3 wrote: post #611
gpm wrote: post #107

Earlier quoted context omitted.

I know rust, I don't know game development (I've dabbled slightly). If I choose to build a game I either need to make it work in rust* or I need to learn a new language (Unity -> C#, Unreal -> blueprints, Godot -> gdscript). So your advice to "just use Unity/Unreal/Godot" is the opposite of your advice "you should stick with what you know" in my case. I suspect the former is good advice, and the latter is therefore w…

Learning a new language is basically trivial relative to the effort of bootstrapping everything yourself to compensate for a lacking ecosystem, or the effort of banging your head against the fundamental unsuitability of a tool for a job. Anyone who's learned one or two languages should be able to pick up the basics of any of the standard ones pretty much instantaneously.

Exactly

Re: Leaving Rust gamedev after 3 years

#634

Post by vvanders »

NBJack wrote: post #375
pcwalton wrote: post #335

Earlier quoted context omitted.

The ability of engines like Bevy to automatically schedule dependencies and multithread systems, which relies on Rust's strictness around mutability, is a big advantage. Speaking as someone who's spent a long time looking at Bevy profiles, the increased parallelism really helps. Of course, you can do job queuing systems in C++ too. But Rust naturally pushes you toward the more parallel path with all your logic. In C+…

Aside from a physics simulation, I'm curious as to what you think would be a positive cost benefit from that level of multithreading for the majority of game engines. Graphical pipelines take advantage of the concept but offload as much work as possible to the GPU.

We were doing threading beyond that in 2010, you could easily have rendering, physics, animation, audio and other subsystems chugging along on different threads. As I was leaving the industry most engines were trending towards very parallel concurrent job execution systems.

The PS3 was also an interesting architecture(i.e. SPUs) from that perspective but it was so distant from the current time that it never really took off. Getting existing things ported to it was a beast.

Bevy really nails the concurrency right IMO(having worked on AA/AAA engines in the past) it's missing a ton in other dimensions but the actual ECS + scheduling APIs are a joy. Last "proper" engine I worked on was a rats-nest of concurrency in comparison.

That said as a few other people pointed out, the key is iteration, hot-reload and other things. Given the choice I'd probably do(and have done) a Rust based engine core where you need performance/stability and some dynamic language on top(Lua, quickjs, etc) for actual game content.

Re: Leaving Rust gamedev after 3 years

#635

Post by pshc »

logicprog wrote: post #573
tomtheelder wrote: post #288

Earlier quoted context omitted.

Absolutely agree. I think people saw that a lot of games are written in C++ and got confused into thinking that the right thing to do is to build your entire game in a systems language. The fact that we have games written entirely in C++ is mostly just due to the enormous amount of inertia that game engines have, and the fact that many of them have origins that go back decades to a time when the programming language…

> I wouldn't be surprised if the "next great game engine" had a Rust core and some other language- I mean why not C# at this point?- for game code. That's why, the first time I saw Bevy and Amathyst, I had an immediate "they're doing it wront$ reaction. IMHO, to be a true game engine in the modern sense, instead of merely a game framework, your engine needs to be a precompiled, standalone executable in a systems lang…

Yeah, that bifurcation makes practical sense. Have you considered WebAssembly for the game script layer?

Re: Leaving Rust gamedev after 3 years

#636

Post by alimnes »

popcar2 wrote: post #46

> Rust gamedev ecosystem lives on hype I've been saying this for years. I've tried to get into Rust multiple times the past few years and one of the things I've tried was gamedev with Rust (specifically the library ggez when it was still being worked on, and a little bit of Bevy). I admittedly never got far, but I gave it a solid shot. My experience was instantly terrible. Slow compile times and iterations, huge pack…

> Rust game development feels like a solution looking for a problem to fix.

The same can be said for ordinary CRUD backends. Java, C#, Go and Typescript (Node, Deno or Bun) are all memory safe with good type systems and more than good enough performance. Evangelism around Rust is unfortunately still a thing. A good example is the latest hype in the community because some Google Manager said at a Rust conference that writing Rust is as fast as writing Go. Anyone having done more than a toy program in Rust and Go knows how wrong this statement is. The reasons are given in the article.

Re: Leaving Rust gamedev after 3 years

#637

Post by MerrimanInd »

beders wrote: post #462
MerrimanInd wrote: post #281

Earlier quoted context omitted.

I've been playing around with an idea about OOP for awhile, not sure if it'll ring true or not but I'll run it up the flagpole for feedback. I think FP is a great way to program actions and agency but OOP is a great way to model the world. I like Rust's trait system because the polymorphism is based on what you want an object to do not what it is . But when you're creating models of the world it's usually really conv…

I shall recommend this talk for you https://www.youtube.com/watch?v=rX0ItVEVjHc

I love a long, deep-dive, nerdy talk like this! I'll check it out, thanks.

Re: Leaving Rust gamedev after 3 years

#638

Post by valcron1000 »

SeanAnderson wrote: post #236

I've experienced a lot of these concerns while building https://github.com/MeoMix/symbiants I have a simple question that maybe someone smarter than me can answer confidently: If I want to build something akin to Dwarf Fortress (in terms of simulation complexity) as a browser-first experience - what stack should I choose? Originally, I prototyped something out using React, PixiJS, and ReactPixi ( https://github.com/M…

If you're targeting the browser first why not use a browser first library like PhaserJS [0]?. I don't see a reason to work around with WASM; HTML5 canvas might be everything that you need.

[0] https://phaser.io/

Re: Leaving Rust gamedev after 3 years

#639

Post by aapoalas »

lugu wrote: post #565
lastgeniusua wrote: post #198

> The most fundamental issue is that the borrow checker forces a refactor at the most inconvenient times. Rust users consider this to be a positive, because it makes them "write good code", but the more time I spend with the language the more I doubt how much of this is true. Good code is written by iterating on an idea and trying things out, and while the borrow checker can force more iterations, that does not mean…

The author is asking for a "give me a break" feature. I would say that in a strongly typed functional language, this is akin to mutating objects. The author seems to wish for an unsafe option to locally turn off the borrower check. Is it something Rust could not offer?

You can always dip into raw pointers and come back up for a reference, or eg. do a transmute to a static lifetime. Absolutely not okay according to the language rules but it will compile and will probably also run without an issue if you're not doing something wrong in your code (eg. Wanting to keep a reference to a string while you also mutate it.)

I'm actually surprised that the author didn't seem to consider this much of an option.

Re: Leaving Rust gamedev after 3 years

#640

Post by alimnes »

iknowstuff wrote: post #143
fleventynine wrote: post #78

Earlier quoted context omitted.

I'm a Rust fan (mostly for embedded firmware with minimal deps), but even after 10 years of playing with the language it's not clear to me that advanced GUI or gamedev fits well with the borrow checker. It requires a significant paradigm shift in architecture, and I'm not convinced it's worth making that shift, especially if your application can tolerate a garbage collector (which many games and most UI apps can).

https://dioxuslabs.com/blog/release-050 Seems promising, very React-esque with little boilerplate

Development speed is many times lower than with Typescript frameworks, while the result is not faster or significantly more stable.

Why should anyone choose Dioxus over Sveltekit, Next or Nuxt? I never had an issue with a frontend app that the borrow checker would have catched. Error handling was an issues some years ago but is solved by now when using one of those modern frameworks. (I don't know if Dioxus has error boundaries, though.)

Those Rust fullstack frameworks make sense only for people wanting to use Rust, not for people looking for the right tool for the job.

Post reply on HN