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

731–740 of 996 posts

Re: Leaving Rust gamedev after 3 years

#731

Post by KaiserPro »

pcwalton wrote: post #293
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…

> And my other biggest problem is that they keep painting other non-Rust things as being fundamentally flawed for not being Rust. "It's not memory safe" is the biggest one thrown around, but when was the last time memory safety was actually a big problem in games? Unity uses C# which is garbage collected, Godot uses its own scripting language which makes it nigh impossible to leak memory, Unreal AFAIK has its own too…

> automatically scale to multiple CPUs

We've been promised automatic CPU scaling in programming languages since at least 2001, and I've yet to see any practical version of it.

Re: Leaving Rust gamedev after 3 years

#732

Post by KronisLV »

lelanthran wrote: post #671
Repulsion9513 wrote: post #618

Earlier quoted context omitted.

> a crashing released game is better than a half-finished "perfect" game For who? I, and I'm pretty sure most other gamers, would rather a fully-finished "perfect" game that took twice as long.

> For who? I, and I'm pretty sure most other gamers, would rather a fully-finished "perfect" game that took twice as long. Evidence suggests otherwise. Of all demographics, gamers appear to be the most tolerant of buggy software. I'm playing a 2020 game right now that has (in about 30 hours of gameplay): 1. Crashed twice 2. Froze once 3. Has at least ONE reproducible bug that a player would run into at least once eve…

> 1. Crashed twice 2. Froze once 3. Has at least ONE reproducible bug that a player would run into at least once every mission (including the first one).

Sounds about on par even for enterprise software, in cases where shipping quickly is prioritized over overall quality, doubly so for gamedev which is notorious for long hours and scope creep.

Re: Leaving Rust gamedev after 3 years

#733

Post by pcwalton »

lelanthran wrote: post #703
pcwalton wrote: post #677

Earlier quoted context omitted.

Oh, come on, we're yet again extrapolating from "Rust is bad at rapid iteration on an indie game" to "Rust is bad at everything". If Rust were really that astoundingly unproductive of a language, then so many developers at organizations big and small wouldn't be using it. Our industry may be irrational at times, but it's not that irrational.

> Oh, come on, we're yet again extrapolating from "Rust is bad at rapid iteration on an indie game" to "Rust is bad at everything". I am saying that Rust development has a lower velocity than mainstream GC'ed languages (Java, C#, Go, whatever). I didn't think that you are disputing this claim; if you are disputing this, I'd like to know why you think otherwise.

> I am saying that Rust development has a lower velocity than mainstream GC'ed languages (Java, C#, Go, whatever).

That's not what you said: you said you're going to be less productive in Rust than nearly any other language, not "mainstream GC'd languages".

> I didn't think that you are disputing this claim; if you are disputing this, I'd like to know why you think otherwise.

Depending on the domain, I am disputing that, because of things like the Cargo ecosystem, easy parallelism, ease of interop with native code, etc. There is no equivalent to wgpu in other languages, for example.

Re: Leaving Rust gamedev after 3 years

#734

Post by pjmlp »

spiderice wrote: post #694
pjmlp wrote: post #687

Earlier quoted context omitted.

Yep, Stadia might have failed, but GeForce Now and XBox Cloud Gaming have enough customers to keep them going.

That’s complete different. They are rendering the client and streaming it to users. That doesn’t make the client side code “server side” any more than you streaming Fortnite on Twitch does.

Nope, XBox XDK has facilities for code to be aware of rendering server side.

Re: Leaving Rust gamedev after 3 years

#735

Post by pcwalton »

lelanthran wrote: post #676
pcwalton wrote: post #584

Earlier quoted context omitted.

Here's a trace of a Bevy demo: https://i.imgur.com/oXUxC2h.png You can see that all the CPUs are being maxed out. This actually does result in significant FPS increases. Does it matter for every game? No. But it does result in better performance!

>> but the ability of engines like Bevy to analyze system dependencies and automatically scale to multiple CPUs is a big deal >> Is it? The article addresses that, and basically calls it a pointless feature > You can see that all the CPUs are being maxed out. You're missing the forest for the trees - the poster above basically said "seeing all the CPUs being maxed out is a pointless feature" and you reply with "but s…

No, the original article said that you don't get parallelism from Bevy in practice:

> Unfortunately, after all the work that one has to put into ordering their systems it's not like there is going to be much left to parallelize. And in practice, what little one might gain from this will amount to parallelizing a purely data driven system that could've been done trivially with data parallelism using rayon.

It's not saying "yes, you get parallelism, but I don't need the performance"; it's claiming that in practice you don't get (system-level) parallelism at all. That's at odds with my experience.

Re: Leaving Rust gamedev after 3 years

#736

Post by fulafel »

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…

Most modern languages are memory safe and they don't get called out for emphasizing that or being opinionated. I think with Rust that attention results from its choice of memory management model which gets in the way a lot in ways described in the article.

Re: Leaving Rust gamedev after 3 years

#737

Post by dragonwriter »

valcron1000 wrote: post #622

Very interesting article but I feel the need to question some things. - The very first thing that comes to mind is why actually use Rust for gamedev. From the article it seems like the author got into Rust through Godot, but that does not explain why commit to use Rust for a full game. What was the reasoning behind picking Rust? - It feels to me that there's a mix of criticism to Rust as a language, Rust as a communi…

I’ve only done a few toy projects using ECS, but the author seems to be struggling with ECS on a basic conceptual level. E.g.,

---quote---

For example, modelling Health as a general purpose mechanism might be useful in a simple simulation, but in every game I end up wanting very different logic for player health and enemy health. I also often end up wanting different logic for different types of non-player entities, e.g. wall health and mob health. If anything I've found that trying to generalize this as "one health" leads to unclear code full of if player { ... } else if wall { ... } inside my health system, instead of having those just be part of the big fat player or wall systems.

---end quote---

The solution here is to have a Health component but not a generic Health system (actually, a generic Health system sounds like a code smell for another reason, because systems map to actions, while components map to attributes; systems that interact with a Health component would be things like a damage or healing system) -- but if you need something to work different for player health and wall health and enemy health, you can just have three systems, which, respectively, do Query, Query, Query.

Re: Leaving Rust gamedev after 3 years

#738

Post by gg2222 »

cogman10 wrote: post #42
_eojb wrote: post #27

This is a very brave post to write given how incendiary responses to rust criticism can be, but this matches my experience entirely.

> incendiary responses to rust criticism can be I've not experienced this. Do you have examples of the rust community flaming someone for having negative opinions about the language?

Check this response to the article within these HN comments: https://news.ycombinator.com/item?id=40177534

Not actually flaming but quite condescending towards the article writer. Not even properly reading the article and coming to conclusions.

This is on HN which is generally more neutral towards Rust. I imagine in Rust circles these types of responses would come out a lot more.

Re: Leaving Rust gamedev after 3 years

#739

Post by obdev »

neonsunset wrote: post #706
obdev wrote: post #692

Earlier quoted context omitted.

I mean, if we are allowed to lie in order to promote Rust, why don't we just smear all the C/C++ code bases in the world as security hazard needed to be sorted out ASAP? Unless we already do...

I doubt security is the matter everyone is concerned with but rather the quality of tooling and developer experience. It is, of course, difficult to convey to developers who only experienced C and C++ build systems, or Ruby tooling and brittleness, or Python way of managing dependencies, or setting up the packaging when using Java, that fast and easy to use solutions do not come from trade-offs but from just better w…

I value good tooling as much as the next software engineer. We have good IDEs, build systems, package managers in Java and .NET lands; but we also have a decent environment of established, well-maintained libraries and frameworks.

Rust is deemed to have good tooling, but the third-party library ecosystem is following the NPM/RubyGems culture with all the fragmented dependencies, plus the added complexity of compile times due to lack of ABI compatibility.

Meanwhile, monolithic projects like Tokio also keep strengthening their reign among the small peasant crates.

I'm learning Rust, after decades of various languages with garbage collector, and I believe in the language itself and its tooling. But everything else about Rust irks me.

Re: Leaving Rust gamedev after 3 years

#740

Post by suby »

vacuity wrote: post #218
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…

Now I'm wondering how far people could go a hypothetical Rustscript* that transpiles to Rust (or hooks into rustc?), introduces extra features such as reflection, removes lifetimes, and changes the defaults around things like monomorphization. * name intentionally made to make people angry

If you're removing lifetimes from the script, I'm not sure how you're then transpiling to Rust, unless you wrap everything with reference counting, at which point you're better off using a language with GC.
Post reply on HN