Live data from Hacker News

Leaving Rust gamedev after 3 years

loglog.games

511–520 of 996 posts

Re: Leaving Rust gamedev after 3 years

#511

Earlier quoted context omitted.

"I tend to agree about the "async contamination" problem. 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. I've been pushing back against it creeping into areas that don't really need it." 100% this. As I say elsewhere in these threads: Rust is the language that Tokio ate. It isn't even just async viral-chain-effect, it's that on…

Disappointing to hear this after battling the same nonsense in JS for years.

It's just endemic to the industry. Framework-itis

Re: Leaving Rust gamedev after 3 years

#512
post #24

My impression of Rust is that it's a very opinionated language that wants everybody to program in a specific way that emphasizes memory safety above everything. That's a good idea, I think, for the systems programming use cases that it was intended for. I don't see that as a particularly useful thing to value for game development. The part in the article about the Rust borrow checker constantly forcing refactors soun…

> My impression of Rust is that it's a very opinionated language It's not though. There's only one thing Rust is opinionated about. > that wants everybody to program in a specific way that emphasizes memory safety above everything. Well yes, that is literally the core proposition and purpose of the language. That's like saying java is opinionated because it wants to manage the memory. > I just don't think the kinds o…

> As soon as games are networked it starts being a problem, and these days non-networked games are pretty rare.

So have your network protocol parser in Rust and the entire rest of your game in whatever the hell you want.

All the practical safety you could desire without any language constraints for the other 99% of the code

Re: Leaving Rust gamedev after 3 years

#513

Earlier quoted context omitted.

The hardest part of a project is finishing it. I think the main issue is the fun problems to solve happen very early in the project and once those are done it becomes incredibly tedius and boring and I usually lose focus until the project dies. Its difficult to maintain motivation.

Interesting, I almost find it the opposite right now. Learning the engine is a pain in the ass -- it's not particularly hard, just tedious to learn all the APIs and quirks -- and then when you're initially building the thing, "it's not fun yet" for a quite a while. But then once you have the fundamentals down, you can add more abilities and characters and other features, that's the fun shit. I was working on the AI l…

I think the period between having a playable alpha and a polished release is the part people hate.

Or just grinding out content to make the game longer.

I hope you enjoy the process and succeed as a game dev.

Re: Leaving Rust gamedev after 3 years

#514
I'd be interested to hear the author's take on Nim [1], which seems to be better suited for game development than Rust by staying out of the dev's way [2], and supports hot-reloading (at least in Unreal Engine 5) [3]?

[1] https://nim-lang.org/

[2] https://youtu.be/d2VRuZo2pdA?si=E3N62oUJ-clXozCg

[3] https://www.youtube.com/watch?v=Cdr4-cOsAWA

Re: Leaving Rust gamedev after 3 years

#515
post #450

Earlier quoted context omitted.

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.

No language from Apple / Google / Microsoft / whatever can ever be a serious replacement for C++. When the development of the language is dominated by a single entity, the risk that the interests of that entity override those of other users is simply too high. Vendor-specific languages are fine, if you are developing something for that vendor's ecosystem. But if you don't want to lock your code to a specific ecosyste…

I don't disagree.

Pragmatic considerations tend to win over ideological ones though.

Consider Java's success.

Re: Leaving Rust gamedev after 3 years

#516

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…

Would it be possible to create a generic way to script Bevy? I'm sure there are a lot of people who are going to want to use C#, C++, or something else. I could imagine running a runtime in-process and Bevy communicating with it over a socket.

Re: Leaving Rust gamedev after 3 years

#517
post #501

I've done hobby gamedev in Bevy/Rust, Godot/C#, and Unity C#. It's honestly somewhat baffling to me that folks will choose Rust for gamedev right now. The state of the open sourced tools are just not there yet, especially when compared to Godot, and at the same time these games are running on PC hardware which tends to get faster every year. Also for ECS... one thing I tended to realize is that when developing a game…

> I think about Starcraft from 1998, created when virtually all PCs only had one core, and its 200 unit per faction cap. Blizzard hasn't increased this cap because it doesn't necessarily make the game more fun. That small scale was exactly why the game ends up being so much about micro, and while that may make it more competitive or interesting for spectators it makes it a lot less fun to play IMO. Total Annihilation…

supreme commanders very high unit cap leads to crazy end games. it allows your economy to grow exponentially for the entire game. which has a big impact on late game strategy

Re: Leaving Rust gamedev after 3 years

#518

I've become wary of commenting on articles that mention the pros and cons of various languages, but I still find it strange that so many people are so strongly focused on what their favourite language can do (usually better than others), instead of the project they're working on. When it should be the other way around. The joke he mentioned about having 50 engines written but only 5 games certainly rings true and I d…

Totally agree

My unpopular programming opinion: languages aren't that interesting to me

I'm much more interested in the problem being solved and algorithms in the abstract sense

Re: Leaving Rust gamedev after 3 years

#519

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…

The cache thing is a thing I think a lot of people with a more... naive... understanding of machine architecture don't clue into.

Even just synchronizing on an atomic can thrash branch prediction and L1 caches both, let alone working your way through a task queue and interrupting program flow to do so.

Re: Leaving Rust gamedev after 3 years

#520

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…

C# is that language (see Godot, Stride, FNA, Monogame).
Post reply on HN