Live data from Hacker News

Leaving Rust gamedev after 3 years

loglog.games

921–930 of 996 posts

Re: Leaving Rust gamedev after 3 years

#921
post #824
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…

Quiet adoption often means that a couple people in a company chose to invest in at least a small effort. It's unknown if those people would do it again, and they are unlikely to invest 2-3 devs to improve the rust library and language ecosystem.

Major adoption gets you tools like guice, 50+ person tools teams, and more.

Re: Leaving Rust gamedev after 3 years

#922

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 that is almost never used and when it is the benefits are mostly lost because of real world needs and constraints, and that the problems it solves are easier solved through other solutions and add-on systems that are…

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 context of this article, and my comment, is game development. Not game performance or engine optimization, which while related seem like related but smaller aspects of the overall topic.

The way I interpret the claims is that bevy is putting far too much focus on performance and multi-threading when by far the important thing to focus on for game development is allowing the actual game developers to rapidly iterate.

Bevy might be very fast and performant, but if that seems to have come at the cost of (or been optimized for over) features that make it easier to use in ways that game developers need, then the criticism may have merit. Whether that's true or not I don't know, but hopefully that explains why a response about how it definitely can use lots of threads and make good use of many cores isn't really seen as a good rebuttal to the criticisms leveled.

Re: Leaving Rust gamedev after 3 years

#923

Earlier quoted context omitted.

Godot 4 already has hot reloading.

Not for shaders while the game is running? https://github.com/godotengine/godot-proposals/issues/5269

For testing shaders you can use the editor, at least.

Re: Leaving Rust gamedev after 3 years

#924
Reading the part about global state reminds me of some of my thoughts building backend web apps. Not having global namespace pollution is fine, but not having any global registry of some sort can make things far harder for the size that most things are going to be.

Re: Leaving Rust gamedev after 3 years

#925

Earlier quoted context omitted.

? I believe the Rust efforts in Firefox were largely successful. I think Servo was for experimental purposes and large parts were then added to Firefox with Quantum: https://en.wikipedia.org/wiki/Gecko_(software)#Quantum

My recollection was that those were separate changes - servo didn’t get to the stage where it could be merged, but it was absolutely the plan to build a rendering engine that outperformed every other browser before budget cuts hit.

We did port Servo’s WebRender to Firefox and shipped it everywhere. The only caveat is that it took multiple years of upgrades, fixes, and rewriting it.

Re: Leaving Rust gamedev after 3 years

#926
post #507

Earlier quoted context omitted.

> The main reason is that you can't ship that Rust code on PS5 in a sensible manner. Really - why’s that?

Sony requires that you use their tooling, which you can only get under NDA.

I remember a meeting of local gamedevs with sony in '95. A guy at the back piped up with "So when will the C++ compiler be ready? We've written our whole game in C++".

Crickets. Two Sony dudes at the front look at each other like, "You tell him".

IMHO Rust is the wrong language for game development. But so is C++ TBH.

Re: Leaving Rust gamedev after 3 years

#927
post #705

Earlier quoted context omitted.

Funny how at the end of the talk a senior looking guy asks him, “Why not just use C?” and the speaker basically admits that that would be his choice but for “cultural” reasons.

And then he went to work for Unity on HPC#, the C# Burst compiler toolchain.

… and monetary reasons :)

Re: Leaving Rust gamedev after 3 years

#928

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).

It depends what you measure

For software that must get it right Rust can be more productive. The early cycles of development are slow, especially for people who have not surrendered to the borrow checker, yet. But the lack of simple mistakes, or more accurately the compiler's early detection of simple mistakes dramatically speeds up development

But in a lot of software those mistakes, whilst important, will not "crash the aeroplane ", so it is not worth that extra cost in the early cycles

I am not a game developer, or player, but games are in that category I think

Re: Leaving Rust gamedev after 3 years

#930

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…

> Evidence suggests otherwise. Of all demographics, gamers appear to be the most tolerant of buggy software.

Evidence suggests otherwise. Of all demographics, game studios appear to be the most tolerant of buggy software. bladeblablabla

Just go look at CP2077 or BF2042 or Fallout 76 or ...

So many games out there that no one wanted to play until they finally actually made a game that was ready for release, a year or more after they released it.

Post reply on HN