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

831–840 of 996 posts

Re: Leaving Rust gamedev after 3 years

#831

Post by VancouverMan »

cogman10 wrote: post #510
VancouverMan wrote: post #481

Earlier quoted context omitted.

Based on what I've seen, various forms of censorship and suppression are often employed in such cases, rather than outright "flaming" or other discussion-based approaches. It really depends on where and how the discussion is taking place, and what censorship methods the website/platform/medium involved offers. Sometimes users are just outright banned or shadow-banned, if those happen to be options. Sometimes forum th…

Ok, do you have a concrete example of this?

I haven't rigorously tracked all of the instances I've seen of this happening over the years, but I've tried to quickly find some more prominent examples for you.

This bug report, for example, has various "This comment has been minimized.", "rust-lang deleted a comment from ...", "rust-lang locked and limited conversation to collaborators" interference:

https://github.com/rust-lang/team/pull/671

A Reddit thread discussing the situation from that bug report mentioned above has numerous "[removed]" comments and down-voted comments:

https://old.reddit.com/r/rust/comments/qzme1z/moderation_tea...

When Rust is discussed here, it's common enough for reasonable and relevant Rust-related comments to be voted down, sometimes severely. These threads have some examples I quickly found via a search of high-activity Rust submissions:

https://news.ycombinator.com/item?id=24334731&p=2

https://news.ycombinator.com/item?id=24343867

https://news.ycombinator.com/item?id=23802674

https://news.ycombinator.com/item?id=26812047&p=2

https://news.ycombinator.com/item?id=29488336

https://news.ycombinator.com/item?id=11340100

https://news.ycombinator.com/item?id=24337001

Here's an example of a recent submission on this site for an article very reasonably and thoroughly questioning Rust. It got some attention, and now it's currently marked as "[flagged]":

https://news.ycombinator.com/item?id=40091427

Keep in mind that strict "moderating" (ie, censoring) has been an integral part of the Rust community's identity for many years now via its Code of Conduct and Moderation Team -

https://www.rust-lang.org/policies/code-of-conduct

https://www.rust-lang.org/governance/teams/moderation

Re: Leaving Rust gamedev after 3 years

#832

Post by orthoxerox »

astrange wrote: post #388
jvanderbot wrote: post #295

Earlier quoted context omitted.

Threading, probably.

Async/await isn't related to threading (although many users and implementations confuse them); it's a way of transforming a function into a suspendable state machine.

Games need async/await for two main reasons:

- coding multi-frame logic in a straightforward way, which is when transforming a function into a suspendable state machine makes sense

- using more cores because you're CPU-bound, which is literally multithreading

Both cases can be covered by other approaches, though:

- submitting multi-frame logic as job parameters to a separate system (e.g., tweening)

- using data parallelism for CPU-intensive work

Re: Leaving Rust gamedev after 3 years

#833

Post by nazgulsenpai »

leduyquang753 wrote: post #647
DarkNova6 wrote: post #88

Earlier quoted context omitted.

Just a small addition: Godot also has great C# support. It is a real charm to work with.

Last time I tried Godot with C# in Visual studio, when I debugged I could not see the console output, and when I ran with the console output I could not debug (the breakpoints weren't hit). A Google search later and turns out it wasn't just me.

Godot C# works pretty seamlessly with VSCode and has improved dramatically over the years. It did regress a bit in Godot 4 after swapping to the newer .net "core" (in terms of platform support) but as of 4.2 I have had no issues at all.

Re: Leaving Rust gamedev after 3 years

#834

Post by davidalayachew »

celdon25 wrote: post #627
davidalayachew wrote: post #546

Earlier quoted context omitted.

Complete distraction of a question -- for that video clip, what is the song playing at the time stamp you selected? Is that in-game music? I figure not.

Don't know the song but that is the ingame music for that specific map, and gets triggered each time certain enemy buildings are destroyed. Different music for each type of building

Very helpful, ty vm.

Re: Leaving Rust gamedev after 3 years

#835

Post by FrustratedMonky »

melodyogonna wrote: post #819
FrustratedMonky wrote: post #781

Seems like a few contradictory ideas here. Rust is supposed to be a better safer C/C++. Then lot of comments here that games are best done in C++. So why can't Rust be used for games? What is really missing beyond an improved ecosystem of tools. All also built on Rust.

This is not a matter of tools though, did you read the article? The main pain point is that Rust semantically makes fast iteration impossible

Did I read the article? You?.

But the conversation in the thread is making point that Rust does lack tooling, libraries, that would make lacking fast iteration a valid trade off.

And a common theme is that C++ is better, and last I checked it is also not great at fast iteration.

Re: Leaving Rust gamedev after 3 years

#836

Post by neonsunset »

devjab wrote: post #824
lumost wrote: post #615

Earlier quoted context omitted.

I sometimes wonder if the problem with rust is that we have not yet had a major set of projects which drive solutions to common dev problems. Go had google driving adoption, which in turn drove open source efforts. The language had to remain grounded to not interfere with the doing of building back-end services. Rust had mozilla/servo which was ultimately unsuccessful. While there are more than a few companies uinf r…

Microsoft is rewriting quite a bit of their C# to Rust for performance reasons. Especially within their business line products. Rust have also become rather massive in the underlying tech in the telecommunications infra structure in several countries. So I’m not sure that your take is really so on point. Especially as far as comparing it with Go goes (heehee), at least not in terms of 3rd party libraries where most o…

Microsoft rewrote one, maybe two microservices as it was driven by a lead interested in using Rust and is rewriting parts of NT kernel (way more important).

Re: Leaving Rust gamedev after 3 years

#837

Post by arc619 »

pcwalton wrote: post #735
lelanthran wrote: post #676

Earlier quoted context omitted.

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

To be fair, you've posted a toy example. Real games are often chains of dependent systems, and as complexity increases, clean threading opportunities decrease.

So, while yes it's nice in theory, in practice it often doesn't add as much performance as you'd expect.

Re: Leaving Rust gamedev after 3 years

#838

Post by afiori »

pcwalton wrote: post #735
lelanthran wrote: post #676

Earlier quoted context omitted.

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

The article is not saying that Bevy does not parallelize but that the impredictability of parallelism (both in ordering and in timing) forces the developer to add enough dependency constraints that there is not much left to parallelize.

Re: Leaving Rust gamedev after 3 years

#839

Post by Capricorn2481 »

mrkeen wrote: post #86

> As far as a game is concerned, there is only one audio system, one input system, one physics world, one deltaTime, one renderer, one asset loader. I thought this way when I was doing Java dev around 10 years ago. I thought it excused the singleton pattern. I was wrong! You should always be able to construct an object by explicitly passing dependencies to it. Especially for testing. It really is no fun if your rende…

Unit testing in Game dev is largely useless.

Re: Leaving Rust gamedev after 3 years

#840

Post by IshKebab »

codethief wrote: post #814
imiric wrote: post #109

This is a sobering read. Thank you for sharing. This sums it up for me: > Rust as both language and community is so preoccupied with avoiding problems at all cost that it completely loses sight of what matters, delivering an experience that is so good that whatever problems are there aren't really important. This doesn't mean "ship crap games", it means focusing on the game being a good game, not on the code being go…

To be fair, many (non-game dev) Rust projects I have seen/used do provide great user experience precisely because they are laser-focused on performance and have blown existing alternatives out of the water. (Think ripgrep, fzf, etc.) Prototyping is certainly necessary but it shouldn't be at the cost of runtime performance – at least not too much –, because it will typically be very difficult to improve performance af…

> ripgrep, fzf

I think these are great examples of where prototyping and rapid iteration are really not needed at all, and hence Rust shines here.

Writing a game is completely different.

Post reply on HN