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

371–380 of 996 posts

Re: Leaving Rust gamedev after 3 years

#371

Post by valcron1000 »

zogrodea wrote: post #101
telekid wrote: post #28

This article describes almost exactly why I think gradual typing is actually a good thing. Type checkers shouldn't get in the way of your code compiling. Yes, the language has to be designed with this property from the beginning. Yes, you should always enforce complete checking in CI. But you should also be able to try half-baked ideas.

There are at least a few nascent statically typed languages (as in, full static typing rather than gradual) which nevertheless let code with type errors compile for the sake of testing. The two that I know of are Darklang [0] and Roc [1] which aim to let you compile code with type errors for the same reason you suggest. [0] "Dark is designed for continuous delivery. As such, we don’t like requiring you to make large…

Let me introduce you to `-fdefer-type-errors` in GHC Haskell:

https://ghc.gitlab.haskell.org/ghc/doc/users_guide/exts/defe...

Re: Leaving Rust gamedev after 3 years

#373

Post by melodyogonna »

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

Mojo soon

Re: Leaving Rust gamedev after 3 years

#374

Post by meheleventyone »

VelesDude wrote: post #344
pcwalton wrote: post #260

Earlier quoted context omitted.

> I'd expected some AAA title to be written in Rust by now. Why? Those kinds of game engines are enormous amounts of code, and there's little incentive to rewrite. I do strongly disagree that we aren't ever going to see large-scale game development in Rust; it just takes time. Whether games adopt an engine is largely about that engine's maturity rather than anything about the language. Bevy is quite young; 0.13 doesn…

It was a few years back that the question came up to the developers of a Call of Duty title. "Is there still code from Quake 3 in COD?". They dodge around it by saying something like "we cannot deny this but e use the most appropriate tech where needed". While not confirmation, I wouldn't be surprised if there is a few nuggets of Q3 in that code base still doing some of the basics. That would be really cool if it is…

A lot of big projects have amazing longevity to their older architectural decisions. Unreal still has a lot of stuff in it people that used UE1 would recognize, I did most of my professional development on UE3 and a bunch of that is still pretty recognizable. Similarly Chrome is a product of the time it was first created. And looking into the Windows source is probably like staring into the stygian abyss.

There is a lot of legacy and tech debt out there!

Re: Leaving Rust gamedev after 3 years

#375

Post by NBJack »

pcwalton wrote: post #335
delfinom wrote: post #296

Earlier quoted context omitted.

Kind of both in my opinion. But rust is bringing nothing to the table that games need. At best rust fixes crash bugs and not the usual logic and rendering bugs that are far more involved and plague users more often.

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.

Re: Leaving Rust gamedev after 3 years

#376

Post by mholub »

mr_00ff00 wrote: post #321
dario_od wrote: post #242

Earlier quoted context omitted.

You more or less described Zig

Sort of, although Zig certainly pushes itself towards the embedded world. I have tried Zig a bit and like it a lot, and I am sure it would be better for game dev than Rust, but I don't want to pass allocators around all day to all the objects in my game. Go without GC is more like a Go and Zig baby.

nothing really prevents you from defining global allocator in Zig

and having explicit allocator in standard library is actually a good thing, cause it's quite a common case in game development to use arena allocators which are being freed once per frame - so you don't really need to reinvent your data structures in Zig

I do have some concerns about Zig because it also introduces some friction for correctness sake like requiring to always use all variables, explicit casts everywhere - I want some compiler toggle to disable all of that and focus on problem but unfortunately it's not there

I am playing with Zig now and haven't really formed my opinion about game development specifically but I like it a lot so far

Re: Leaving Rust gamedev after 3 years

#377

Post by IggleSniggle »

pavlov wrote: post #314
meheleventyone wrote: post #276

Earlier quoted context omitted.

Disagree the adoption of C++ was more about Moore's law than ecosystem, although having compilers that were beginning to not be completely rubbish also helped.

Also C++ could be adopted incrementally by C developers. You could use it as “C with classes”, or just use operator overloading to make vector math more tolerable, or whatever subset that you happened to like. So there’s really three forces at play in making C++ the standard: 1) The Microsoft ecosystem. They literally stopped supporting C by not adopting the C99 standard in their compiler. If you wanted any modern co…

That description of problems bodes well for Zig

Re: Leaving Rust gamedev after 3 years

#378

Post by lelanthran »

pcwalton wrote: post #317
Xeamek wrote: post #299

Earlier quoted context omitted.

I mean, if you agree that the ideal for bevy would be lua integration, you are kinda agree with the author that Rust itself is suboptimal (at least in layer of game scropting), don't You?

I think whether you prefer Rust or a scripting language like Lua for high-level game logic comes down to what your needs are and personal preference. There are reasonable arguments on both sides.

> There are reasonable arguments on both sides.

What are the reasonable arguments for using Rust[1] for game logic instead of a scripting language like Lua?

[1] Or C++, etc.

Re: Leaving Rust gamedev after 3 years

#379

Post by xboxnolifes »

droopyEyelids wrote: post #163
int0x29 wrote: post #147

Earlier quoted context omitted.

> * There are very few people doing serious 3D game work in Rust. There's Veloren, and my stuff, and maybe a few others. No big, popular titles. I'd expected some AAA title to be written in Rust by now. That hasn't happened, and it's probably not going to happen, for the reasons the author gives. At one point the studio behind the Finals was writing game server code in Rust with an Unreal engine client. Not sure if t…

Backend 3d code?

I'm not familiar with the domain, but wouldn't 3D collision checking be considered backend 3D code? Even if it's not rendered, it still needs to be calculated.

Re: Leaving Rust gamedev after 3 years

#380

Post by Animats »

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.

In big-world high-detail games, the rendering operation wants so much time that the main thread has time for little else. There's physics, there's networking, there's game movement, there's NPC AI - those all need some time. If you can get that time from another CPU, rendering tends to go faster.

I tend to overdo parallelism. Load this file into a Tracy profile, version 0.10.0, and you can see what all the threads in my program are doing.[1] Currently I'm dealing with locking stalls at the WGPU level. If you have application/Rend3/WGPU/Vulkan/GPU parallism, every layer has to get it right.

Why? Because the C++ clients hit a framerate wall, with the main thread at 100% and no way to get faster.

[1] https://animats.com/sl/misc/traces/clockhavenspeed02.tracy

Post reply on HN