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

441–450 of 996 posts

Re: Leaving Rust gamedev after 3 years

#441

Post by TheRoque »

pcwalton wrote: post #279
mrkeen wrote: post #211

Earlier quoted context omitted.

> There's decades of work to catch up on First you gotta get OpenGL going, with its horrible stateful API, give up on it and go to DirectX9. Do a complete rewrite when DirectX10 comes out. Get your real-time lighting happening with shadow volumes, run into patent issues and get strong-armed into putting Creative sound into your game. Cycle between GLSL, HLSL, and Cg. End up switching to shadow mapping anyway. Drop Li…

Exactly. Bevy has the advantage of being built using the "right way" from the start. This makes an enormous difference in the ease of hacking on rendering code. Ironically, the main thing holding Bevy back is the bickering at the W3C. WebGPU is still not widely supported, so we have to support WebGL 2 (with reduced functionality in some cases), and that adds a lot of complexity.

> Bevy has the advantage of being built using the "right way" from the start

I think the article is precisely criticizing this type of comment... You make people believe that Bevy is some kind of safe bet for the future, that it took inspiration from the greatest to build even better foundations for a game engine... And it seems common in the Rust community: make audacious unverifiable claims to enroll other "believers". But it's easy to claim when the tool itself has a fraction of the functionalities of Unreal, Unity or Even Godot. Heck, last time I used it (about 2 years ago) there wasn't even any built-in physics stuff. You have to install plugins from every corner, some require old Bevy versions, some other require newer versions... It's seriously unusable to just "get things done"

Re: Leaving Rust gamedev after 3 years

#442

Post by james4k »

I've been leaning into Rust almost purely to escape from the mess that is C/C++ tooling which always makes considering a new dependency a time sink.

Can someone explain the obsession with combining ECS with generational arenas?

Re: Leaving Rust gamedev after 3 years

#443

Post by jibe »

hi-v-rocknroll wrote: post #396
stephc_int13 wrote: post #267

Earlier quoted context omitted.

Yeah this is a common problem in the industry, we rarely have enough time to refactor what should be considered prototype-level code into robust code.

The game dev industry could form a consortium to launch its own dedicated general purpose language built from scratch to compile very fast like V or Go, run predictability, be much safer, be more reusable, and be extremely productive with the lessons learned from C, C++, C#, and more. Also, I think LLMs will be able to run against code bases to suggest mass codemods to clean things up rather than having humans make a…

Jonathan Blow’s Jai is an attempt at something like this. It’s looking promising so far!

Re: Leaving Rust gamedev after 3 years

#444

Post by celdon25 »

netbioserror wrote: post #429
celdon25 wrote: post #331

Earlier quoted context omitted.

> As an additional bonus, 99.9% of the code you write in a GC language never has to be about memory at all. This is a bit of an oversimplification. If you are sloppy with "memory management" (unnecessary object lifetimes, unnecessary duplication, etc) even in a GC language, it is possible to have noticeable performance impacts. I'm not saying these languages aren't the right tool for the job, but it is not a free pas…

Yes, but that's only true for long-running applications. Most gigantic monolithic web server applications, for example, do not need to be gigantic monolithic web server applications. My Nim CLI application does a subset of common tasks, outputs to stdout, and is invoked by our PHP server for each task. It (and the Rust and C programs it replaced) can barely blip a fraction of a percent amount of system memory in the…

> Architecting these sorts of services properly can assist in making tool choices that drastically boost maintainability and feature delivery, especially for small teams

I hate hearing this argument, because it glosses over the hard realities of building products, even if it sounds good on paper. Companies don't often have the resources to hire people that can do this early on, or the time to do this early on even if they do have the talent. And it might not be correct to do so when you have uncertain future requirements.

If that talent is you, you might not even be trusted to make those kinds of decisions until a year or two of tenure. And you might have junior (or even 'senior') devs on the side making changes that make this harder to do, without anyone realizing it.

So the reality is that you can't expect systems to be "architected properly" and you get what you get. It's an incremental process.

Re: Leaving Rust gamedev after 3 years

#445

Post by summerlight »

kibwen wrote: post #221
Animats wrote: post #137

That's a good article. He's right about many things. I've been writing a metaverse client in Rust for several years now. Works with Second Life and Open Simulator servers. Here's some video.[1] It's about 45,000 lines of safe Rust. Notes: * 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 writ…

> I'd expected some AAA title to be written in Rust by now. I'm disinclined to believe that any AAA game will be written in Rust (one is free to insert "because Rust's gamedev ecosystem is immature" or "because AAA game development is increasingly conservative and risk-averse" at their discretion), yet I'm curious what led you to believe this. C++ became available in 1985, and didn't become popular for gamedev until…

Yeah, gaming industry has become mature enough to build up its own inertia so it will take some time for new technologies to take off. C# has become a mainstream gamedev language thanks to Unity, but this also took more than a decade.

Re: Leaving Rust gamedev after 3 years

#446

Post by BaculumMeumEst »

littlestymaar wrote: post #231
colund wrote: post #48

I find that Jonathan Blow ranting about Rust game development here https://www.youtube.com/watch?v=4t1K66dMhWk . He adds interesting perspectives to the discussio, how the language makes the Rust game developer resort to arrays and their so called Rust point of views.

Well the problem with Jonathan's argument here is that he's spent the past decade mostly ranting about Rust and working to make a perfect game programming language, instead of making games. So it turn out that even if he's opinion on Rust is correct, he would still have been much more productive using it than trying to build his own language for a decade… (But he already shipped his masterpiece and he's a millionaire…

Writing games in C++ feels horrible which is a large part of he wrote the language.

Re: Leaving Rust gamedev after 3 years

#447

Post by throwawaymaths »

mholub wrote: post #376
mr_00ff00 wrote: post #321

Earlier quoted context omitted.

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

To be fair though that sort of friction only affects things in the small. They can be annoying but you'll never have to refactor outside the scope of the friction itself.

In practice, it's only really a problem if you're doing codegen.

Re: Leaving Rust gamedev after 3 years

#448

Post by Ygg2 »

JoshTriplett wrote: post #368
Ygg2 wrote: post #199

Earlier quoted context omitted.

Disclaimer: I'm aware you guys are working on relaxing orphan rules, and I wish you the best of luck. But as an outsider, orphan rule doesn't seem to be going anywhere soon. And if the original poster had said that I would be ok. Instead what they said is: > It's a great example of something I'd call "muh safety", desire for perfection and complete avoidance of all problems at all costs, even if it means significantl…

> But you still need a resolution mechanism to fix the error At least initially, the resolution mechanism could be "don't include more than one implementation".

Assuming you have no control over trait implementation, how would that work?

To reuse the canonic example:

    // crate "types"

    pub struct Thing;

    // crate "traits"

    pub trait Action {}

    // crate "alpha_v0" 

    impl traits::Action for types::Thing {}


    // crate "beta_v1" 

    impl traits::Action for types::Thing {} // Doesn't exist for beta_v0
Say by transitive dependencies, alpha_v0 and beta_v0 are imported, and due to vulnerability, you upgrade beta_v0 -> beta_v1 (let's assume that trait is essential for the vulnerability resolution).

Now what? You either have to skip future updates, or keep the vulnerable beta_v0 crate.

Re: Leaving Rust gamedev after 3 years

#450

Post by fooker »

tkubacki wrote: post #419
fooker wrote: post #173

Earlier quoted context omitted.

Perhaps the more appropriate advice is : Use the right tool for the job. Use C++ for writing a high performance library or a database engine. Use Go or Java for writing a server. Use C for writing a kernel module. Use shell scripts for automation. Use python for trying out ML ideas or heavier duty scripts. Use Rust for ... I'm not quite sure what it's the right tool for yet. I suspect it's trying to become the right…

It's C++ replacement just not yet there for game dev (maybe never for game dev)

A C++ replacement must have really strong and seamless C++ interop to be considered by anyone currently using C++. You can't have a C++ replacement by ignoring existing C++ users and libraries, no matter how good the the language is.

Swift from Apple and Carbon from Google are stronger contenders at this point.

Post reply on HN