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

601–610 of 996 posts

Re: Leaving Rust gamedev after 3 years

#601

Post by logicprog »

thegrim33 wrote: post #82
sanderjd wrote: post #62

Earlier quoted context omitted.

I think I just read about 10 versions of this comment on this page, and definitely not a single response to the criticism that could be described as incendiary. I don't think I even saw a single comment just now that fundamentally pushed back on the premise of this article, let alone in an incendiary way. It's early yet, and maybe this thread will look very different in a few hours though?

The author maybe somewhat hit on the reason for this in the article, where they mentioned that they're already seeing some of the rabid, toxic, Rust proponents already moving onto the next "hot" thing and doing their thing there. So maybe after a few years of Rust we've arrived at the turning point now where enough of those types of people have finally moved on and the Rust community has significantly changed.

I don't think that's the case. N=1, but I'm usually a quite staunch, and occasionally incendiary, proponent of Rust, because the arguments against it / criticisms of it I usually see seem fundamentally misguided or even disingenuous to me — whereas in this thread, I've been only agreeing, because the criticisms are fair (I agree Rust isn't built for, and is quite bad at, prototyping, fast iteration, flexible code, etc), if I think a bit overblown (I think many of the patterns the author complains about being forced to use like command lists and generational arenas are very good). That could be the difference you're seeing, IMO.

Re: Leaving Rust gamedev after 3 years

#602

Post by sullyj3 »

metaltyphoon wrote: post #551
tick_tock_tick wrote: post #180

Earlier quoted context omitted.

The mod vs folder rs stuff is just embarrassing for Rust. I have no idea why they support more then 1 method.

The do it because the first one sucked ass and the second is a huge improvement but you still have to support the old way.

Which is which and why?

Re: Leaving Rust gamedev after 3 years

#603

Post by Klonoar »

jsheard wrote: post #255
Klonoar wrote: post #240

Earlier quoted context omitted.

Rust has had tier 3 support for the Switch since 1.64, I believe. Someone had actually done it even before that but IIRC NDAs mucked up any movement on making that public.

Yeah, that Switch support was added by the homebrew side of the fence though so I don't know if it's something that developers would be able to use in an officially licensed game. Nintendo might not care so much as long as the game works, as mentioned it's Sony in particular that I've heard is picky about which compilers their developers use.

Ah, good point - was context I didn't have.

Re: Leaving Rust gamedev after 3 years

#604

Post by pcwalton »

VS1999 wrote: post #593
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!

The problem is that most of the gameplay code is linear, and people have already gotten good at splitting parallel work across threads. Serious physics engines (see jolt) are already designed to run on another thread and distribute the work across multiple cores. The main part of graphics drivers when using opengl or vulkan run on another thread and the UI you access just passes data to it. Rust's parallelism hasn't…

Among those who have tried both, I can confidently say that the idea that C/C++ parallelism is as easy to achieve as parallelism in Rust is very much a minority view. There's a reason why nobody tried to parallelize CSS styling in a production browser before Stylo came along.

Re: Leaving Rust gamedev after 3 years

#605

Post by philosopher1234 »

paulddraper wrote: post #534
hi-v-rocknroll wrote: post #253

Earlier quoted context omitted.

As a non-game dev who uses Rust and Elixir, Rust wouldn't be my first pick for a large gamedev studio for multiple reasons. As for alternatives worth evaluating: Crystal, Cython (compiled Python), or Nim could result in increased gamedev productivity over C++ or C#. Maybe even Go because the iteration and compile times are very fast, and the learning curve is very low.

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

Re: Leaving Rust gamedev after 3 years

#606

Post by pcwalton »

raincole wrote: post #598
pcwalton wrote: post #293

Earlier quoted context omitted.

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

It's a good feature, but still a niche one. It's a bit like choosing Unity only because of DOTS. For a few projects perhaps it make sense. But just a few ones.

Nobody said that every game needs that level of performance. But saying that it's a solution looking for a problem is not true.

I'm fully in favor of having Bevy support dynamic languages, as implemented in for example bevy_mod_scripting [1], for projects that don't need that parallel performance.

[1]: https://github.com/makspll/bevy_mod_scripting

Re: Leaving Rust gamedev after 3 years

#607

Post by littlestymaar »

otterley wrote: post #439
jvanderbot wrote: post #422

Earlier quoted context omitted.

I know. But threading, and earlier processes, were less scalable but potentially faster ways of handling concurrent requests.

It's also much easier to reason about, since scheduling is no longer your problem and you can just write sequential code.

That's one way to see it. But the symmetric view is equally valid: async await is easier to reason about because you see were the block points are instead of having to guess which function is blocking or not.

In any case you aren't writing sequential code, it's still concurrent code, and there's a trade-off between the writing simplicity of writing it as if it was sequential code, and the reading simplicity of having things written down explicitly.

This “write-time vs read-time” trade of is everywhere in programming BTW, that's also the difference between error-as-return-values and exception, or between dynamic typing and static one for instance.

Re: Leaving Rust gamedev after 3 years

#608

Post by littlestymaar »

zamalek wrote: post #431
littlestymaar wrote: post #282

Earlier quoted context omitted.

> at the cost of latency and throughput. Compared to what? Doing epoll manually?

A reactor has to move the pending task to some type of work queue. The task has to pulled off the work queue. The work queue is oblivious as to the priority of your tasks. Tasks aren't as expensive as context switching, but they aren't free either: e.g. likely to ruin CPU caches. Less code is fewer instructions is less time. If you care enough, you generally should be able to outdo the reactor and state machines. Whe…

So yeah, you're thinking about the comparison between async/await and manual state machines management with epoll. But that's not what most people have in mind when you're saying async/await have performance impact, most of them would immediately think you're talking about the difference with threads.

Re: Leaving Rust gamedev after 3 years

#610

Post by littlestymaar »

cmrdporcupine wrote: post #410
littlestymaar wrote: post #282

Earlier quoted context omitted.

> at the cost of latency and throughput. Compared to what? Doing epoll manually?

If I'm not doing slow blocking I/O, I'm not doing epoll anyways. But the moment somebody drops async into my codebase, yay, now I get to pay the cost.

Either you are doing slow IO (in some of your dependency) or you don't have anyone dropping async in your code though…
Post reply on HN