Live data from Hacker News

Leaving Rust gamedev after 3 years

loglog.games

411–420 of 996 posts

Re: Leaving Rust gamedev after 3 years

#411

As someone who's become a core contributor to Bevy lately, while also doing contract work in Unity on the side, I obviously disagree with the idea that Rust isn't up to the task of game dev. The grass isn't greener on the Unity side, with a mountain of technical debt holding the engine back. (They're still using Boehm GC in 2024!) Bevy is a breath of fresh air just because it's relatively new and free of legacy. Usin…

When will an editor be added? That’s what’s holding me back from jumping into Bevy. I actually think Rust is really hard, but I also think it would be beneficial to my career.

Right now it's blocked on cart rewriting the scene format.

Re: Leaving Rust gamedev after 3 years

#412
post #314

Earlier quoted context omitted.

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…

I'd say Rust does have that big ticket ecosystem push. Microsoft has been embracing Rust lately, with things like official Windows bindings [1]. The bigger problem is just inertia: large game engines are enormous. [1]: https://github.com/microsoft/windows-rs

Repo contributor here, just to curb some expectations a bit: it's one very smart guy (Kenny), his unpaid volunteer sidekick (me), and a few unpaid external contributors. (I'm trying to draw a line between those with and without commit access, hence all the edits.)

There's no other internal or external Microsoft /support/ that I'm aware of. I wouldn't necessarily use it as a signal of the company's intentions at this time.

That said, there are Microsoft folks working on the Rust compiler, toolchain, etc. side of things too. Maybe those are better indicators!

Re: Leaving Rust gamedev after 3 years

#413

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…

> The "async" system is optimized for someone who needs to run a very large web server, with a huge number of clients sending in requests. Can you please elaborate on this? I see a lot of similar concerns in other contexts too. Linux kernel's scheduler for example. Is it a throughput/latency tradeoff?

The current popularity of the async stuff has its roots in the classic "c10k" problem. (https://en.wikipedia.org/wiki/C10k_problem)

A perception among some that threads are expensive, especially when "wasted" on blocking I/O. And that using them in that domain "won't scale."

Putting aside that not all of use are building web applications (heterodox here in HN, I know)...

Most people in the real world with real applications will not hit the limits of what is possible and efficient and totally fine with thread-based architectures.

Plus the kernel has gotten more efficient with threads over the years.

Plus hardware has gotten way better, and better at handling concurrent access.

Plus async involves other trade-offs -- running a state machine behind the scenes that's doing the kinds of context switching the kernel & hardware already potentially does for threads, but in user space. If you ever pull up a debugger and step through an async Rust/tokio codebase, you'll get a good sense for what the overhead here we're talking about is.

That overhead is fine if you're sitting there blocking on your database server, or some HTTP socket, or some filesystem.

It's ... probably... not what you want if you're building a game or an operating system or an embedded device of some kind.

An additional problem with async in Rust right now is that it involves bringing in an async runtime, and giving it control over execution of async functions... but various things like thread spawning, channels, async locks, etc. are not standardized, and are specific per runtime. Which in the real world is always tokio.

So some piece of code you bring in in a crate, uses async, now you're having to fire up a tokio runtime. Even though you were potentially not building something that has anything to do with the kinds of things that tokio is targeted for ("scalable" network services.)

So even if you find an async runtime that's optimized in some other domain, etc (like glommio or smol or whatever) -- you're unlikely to even be able to use it with whatever famous upstream crate you want, which will have explicit dependencies into tokio.

Re: Leaving Rust gamedev after 3 years

#414
post #221

Earlier quoted context omitted.

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

Exactly, it's all about the ecosystem and very little about the language features

C++ classes with inheritance are a pretty good match for objects in a 3D (or 2D) world, which is why C++ became popular with 3D game programmers.

Re: Leaving Rust gamedev after 3 years

#415

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…

I believe that better tooling can help, yes. With refactoring, debugging, creating performance and style reports, updating documentation and a ton of other stuff.

Re: Leaving Rust gamedev after 3 years

#416
post #314

Earlier quoted context omitted.

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…

I'd say Rust does have that big ticket ecosystem push. Microsoft has been embracing Rust lately, with things like official Windows bindings [1]. The bigger problem is just inertia: large game engines are enormous. [1]: https://github.com/microsoft/windows-rs

So far I am way less productive in rust than in any language I've ever used for actual work, so to rewrite an entire game engine would seem like commercial suicide.

Re: Leaving Rust gamedev after 3 years

#417

Earlier quoted context omitted.

I'd say Rust does have that big ticket ecosystem push. Microsoft has been embracing Rust lately, with things like official Windows bindings [1]. The bigger problem is just inertia: large game engines are enormous. [1]: https://github.com/microsoft/windows-rs

Repo contributor here, just to curb some expectations a bit: it's one very smart guy (Kenny), his unpaid volunteer sidekick (me), and a few unpaid external contributors. (I'm trying to draw a line between those with and without commit access, hence all the edits.) There's no other internal or external Microsoft /support/ that I'm aware of. I wouldn't necessarily use it as a signal of the company's intentions at this…

That's disappointing on Microsoft's part, because their docs make it seem like windows-rs is the way of the future.

Thanks for your work, though!

Re: Leaving Rust gamedev after 3 years

#418

Earlier quoted context omitted.

> I just can't go back to Go with nil pointers and lack of decent enums/ADTs/pattern matching either. Go is simply a badly designed language where the idea of "simplicity" has been maligned and proven bad ideas likes nil/null, exceptions and such have been introduced in a seemingly modern language. One would think that decades of Java, Javascript, etc. code blowing up because of this issues would teach someone someth…

And yet it is incredibly productive. The poster that contrasted engineers with artists got it right I think. Go is an engineer’s language.

> Go is an engineer’s language.

No, Ada/Spark is an example of a good engineers language. Go is a mediocre effort at best. Rob Pikes defence is that it was designed for junior Googlers who "aren't capable of understanding a brilliant language". Yes that's a real quote.

Re: Leaving Rust gamedev after 3 years

#419
post #173
post #107

Earlier quoted context omitted.

I know rust, I don't know game development (I've dabbled slightly). If I choose to build a game I either need to make it work in rust* or I need to learn a new language (Unity -> C#, Unreal -> blueprints, Godot -> gdscript). So your advice to "just use Unity/Unreal/Godot" is the opposite of your advice "you should stick with what you know" in my case. I suspect the former is good advice, and the latter is therefore w…

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)

Re: Leaving Rust gamedev after 3 years

#420

Earlier quoted context omitted.

Exactly, it's all about the ecosystem and very little about the language features

C++ classes with inheritance are a pretty good match for objects in a 3D (or 2D) world, which is why C++ became popular with 3D game programmers.

Yeah, OOP makes sense for games. The language will matter a bit for which one takes off, but anything will work given enough support. Like, Python doesn't inherently make a lot of sense for data processing or AI, but it's good enough.
Post reply on HN