Live data from Hacker News

Leaving Rust gamedev after 3 years

loglog.games

391–400 of 996 posts

Re: Leaving Rust gamedev after 3 years

#391
I only skimmed this article, but, despite it being very negative about Rust, I almost 100% agree with it: Rust is a HORRIBLE choice for game dev. I might quibble with how they outline the costs and benefits of some of the design patterns that rust forces you into, for instance I think command lists are actually incredibly useful and perfectly fine as a game development thing and not the huge problem they consider them to be, and generational arenas basically solve any pointer ownership problems in game development in my opinion, but they are right in the main.

I know, because I've tried it. Once. I would #never* recommend Rust to game developers, especially not indie ones. In fact I'd recommend against it strenuously!

And this is precisely because Rust is explicitly and knowingly focused on correctness, safety, perfectly clean code, etc at the cost of iteration speed and flexibility and dynamicism, and that's bad for designing game mechanics and even just getting a game done — games have an inherently short life span and development cycle, so safety and correctness and code quality don't matter a whole lot. It's okay if they crash, etc, as long as they work enough to play. It's okay if the code is ugly, you probably won't be working on it for very long. This is even moreso the case, as the author says, because in writing a game you really want to be able to iterate quickly and just. Do shit as an experiment, even if it's temporary, to see how it feels.

On the other hand, who I would recommend Rust to is the people writing game engines, where you really will probably be working on that code for years to come, where stability and correctness is pretty important, and so where Rust's strengths will really shine — but crucially, even then, I'd tell them to make it a real engine, not a game framework like Bevy, by adding a highly flexible, dynamic scripting language like Lua or even C#, and a data format for specifying scenes and entities, and an editor. That way you don't write your game in Rust at all!

Re: Leaving Rust gamedev after 3 years

#392
I've been working in gamedev since 2007 and toyed with Rust since 2014. I simply don't think that majority of games, especially indie games, have performance requirements high enough to justify using anything other than a high-level, garbage collected language.

Of course, some titles like Factorio are outliers. But for majority of games time you would spend to work with manual memory management in C or borrow checker in Rust would better be spent on other things.

Re: Leaving Rust gamedev after 3 years

#393
post #247

Earlier quoted context omitted.

> My priorities are reasonable performances and the fastest iteration time possible. I bought Mount & Blade II Bannerlord in 2020-03-30. I love it to death, but come on... // 2024-02-01 $ curl https://www.taleworlds.com/en/News/552 | grep "Fixed a crash that" | wc -l 29 // 2023-12-21 $ curl https://www.taleworlds.com/en/News/549 | grep "Fixed a crash that" | wc -l 6 // 2023-12-14 $ curl https://www.taleworlds.com/en/…

My impression is that this is due to their non-robust programming style. They do not add fallback behavior when e.g. receiving a null object. It would still be a bug, but could be a log entry instead of crash.

Arbitrary recovery to null pointers isn't a good way to do robust programming. I recommend doing the exact opposite actually.

https://en.wikipedia.org/wiki/Crash-only_software

https://medium.com/@vamsimokari/erlang-let-it-crash-philosop...

Re: Leaving Rust gamedev after 3 years

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

Many tried c++ in early 90s, but wasnt it too slow/memory intensive? You had to implement lots of inline c/assembly to have a bit of performance. Nowadays everything is heavily optimized, but back then not.

If you’re referring to game dev specifically, there have been (and continue to be) concerns around the weight of C++ exception handling, which is deeply-embedded in the STL. This proliferated in libraries like the EASTL. C++ itself however is intended to have as many zero-cost abstractions as possible/reasonable.

The cost of exception handling is less of a concern these days though.

Re: Leaving Rust gamedev after 3 years

#395
post #262

Earlier quoted context omitted.

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…

He is actively developing his new game in parallel to creating the language. Not to mention smaller projects like 'Braid- anniversary edition'.

Isn't the traditional advice that if you try to write both a game engine and a game that you'll get neither?

Re: Leaving Rust gamedev after 3 years

#396
post #247

Earlier quoted context omitted.

> My priorities are reasonable performances and the fastest iteration time possible. I bought Mount & Blade II Bannerlord in 2020-03-30. I love it to death, but come on... // 2024-02-01 $ curl https://www.taleworlds.com/en/News/552 | grep "Fixed a crash that" | wc -l 29 // 2023-12-21 $ curl https://www.taleworlds.com/en/News/549 | grep "Fixed a crash that" | wc -l 6 // 2023-12-14 $ curl https://www.taleworlds.com/en/…

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 zillion changes or refactoring fragile areas of tech debt. LLMs are already being applied to generate test cases.

Re: Leaving Rust gamedev after 3 years

#397

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.

Re: Leaving Rust gamedev after 3 years

#398

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 neat real-world example of ancient Quake code surviving to this day is visible in Valves games - the hardcoded patterns for flickering lights in Quake 1 survived into GoldSrc and then into Source and then into Source 2, most recently showing up in Half Life Alyx, 24 years on from their original appearance in Quake 1.

https://www.alanzucconi.com/2021/06/15/valve-flickering-ligh...

Basically all of the bigger systems will have been Ship-of-Theseus'd several times over by now, but little things like that can slip through the cracks.

Re: Leaving Rust gamedev after 3 years

#399
post #67

Earlier quoted context omitted.

> incendiary responses to rust criticism can be I've not experienced this. Do you have examples of the rust community flaming someone for having negative opinions about the language?

[flagged]

You were flagged for no such thing.

You were flagged for a pointless quip about "woke"ness. Other people repeated more civil and reasonably argued forms of your same point about the language and its community and received no such downvotes.

No need to play martyr.

Re: Leaving Rust gamedev after 3 years

#400
post #68
post #19

As much as I love Rust I sometimes wonder if I'd be more productive in a simpler language. If I wrote it every day I'm not sure that would be true, but as a hobbyist coming back to Rust sometimes takes me a bit to get back in the zone. Also, still not a fan of async, as it is woefully incomplete and fairly complicated in some use cases. That said, I just can't go back to Go with nil pointers and lack of decent enums/…

Rust is in a separate class of go and swift and kotlin and etc. The class it competes on is pretty C, C++, and itself. Yes it's easier to write trivial code in python than Rust. Yes it's harder to manage memory manually than it is to let a gc handle it. I don't see the point. Rust is a systems programming language. It's hard to write a server in it than it is to hack something in node, but it will also be faster and…

Swift has a systems programming subset, and an even smaller embedded programming subset.

Of course "smaller" is significant here; it has less features and you might not like using it anymore.

Post reply on HN