Live data from Hacker News

Leaving Rust gamedev after 3 years

loglog.games

821–830 of 996 posts

Re: Leaving Rust gamedev after 3 years

#821

Earlier quoted context omitted.

Interfaces or traits are not ECS though. ECS is mostly concerned about how data is layed out in memory for efficient processing. The composability is (more or less) just a nice side effect.

This is correct. I wonder how Rust models SoA wirh borrowing. Is it doable or becomes very messy? I usually have some kind of object that apparently looks like OOP but points all its features to the SoA. All that would be borrowing and pointing somewhere else in slices or similar in Rust I assume?

AFAIK tagged-index-handles are typically used for this (where the tag is a generation-counter to detect 'dangling handles'), which more or less side-steps the borrow checker restrictions (e.g. see https://floooh.github.io/2018/06/17/handles-vs-pointers.html).

Re: Leaving Rust gamedev after 3 years

#822
post #247

As a game developer for about two decades, I've never considered Rust to be a good programming language choice. My priorities are reasonable performances and the fastest iteration time possible. Gameplay code should be flexible, we have tons and tons of edge cases _by design_ because this is the best way to create interesting games. Compilation time is very important, but also a flexible enough programming structure,…

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

How many of those crashes were caused by memory safety issues though?

A lot of those crashes might simply be called a "panic" in Rust.

Re: Leaving Rust gamedev after 3 years

#823
post #809

Earlier quoted context omitted.

Ok, I'll give you fold expressions and structured bindings as actually important language updates. The rest are mostly just tweaks that plug feature gaps which shouldn't have existed in the first place when the basic feature was introduced in C++11 or earlier. IMHO by far most things which the C++ committee accepts as stdlib updates should actually be language changes (like for instance std::tuple, std::variant or st…

[flagged]

Oh I followed the C++ standardization process quite closely for about 15 years up until around C++14 and still follow it from the sidelines (having mostly switched back to C since then), and I'm fully aware of the fact that C++ has designed itself into a complexity corner where it is very hard to add new language features (after all, C++ has added more new problems that had then to be fixed in later standards than it inherited from C in the first place).

I still think the C++ committee should mainly be concerned about the language instead of shoehorning stuff into the stdlib, even if fixing the language is the harder problem.

And I can't be alone in this frustration, otherwise Carbon, Circle and Herb Sutter's cppfront wouldn't have happened.

Re: Leaving Rust gamedev after 3 years

#824
post #615
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…

I sometimes wonder if the problem with rust is that we have not yet had a major set of projects which drive solutions to common dev problems. Go had google driving adoption, which in turn drove open source efforts. The language had to remain grounded to not interfere with the doing of building back-end services. Rust had mozilla/servo which was ultimately unsuccessful. While there are more than a few companies uinf r…

Microsoft is rewriting quite a bit of their C# to Rust for performance reasons. Especially within their business line products. Rust have also become rather massive in the underlying tech in the telecommunications infra structure in several countries.

So I’m not sure that your take is really so on point. Especially as far as comparing it with Go goes (heehee), at least not in terms of 3rd party libraries where most of the Go ecosystems seems to be either maintained by one or two people or abandoned as those two people got new jobs. I think Go is cool by the way, but there is a massive difference in the maturity of the sort of libraries we looked into using during our PoCs.

Anyway. A lot of Rust adoption is a little quiet, and well, rather boring. So maybe that’s why you don’t hear too much about it.

Re: Leaving Rust gamedev after 3 years

#825
post #470
post #46

> Rust gamedev ecosystem lives on hype I've been saying this for years. I've tried to get into Rust multiple times the past few years and one of the things I've tried was gamedev with Rust (specifically the library ggez when it was still being worked on, and a little bit of Bevy). I admittedly never got far, but I gave it a solid shot. My experience was instantly terrible. Slow compile times and iterations, huge pack…

> but when was the last time memory safety was actually a big problem in games? Unity uses C# which is garbage collected, Godot uses its own scripting language which makes it nigh impossible to leak memory, Unreal AFAIK has its own tools that makes memory management trivial. So.... Sounds like memory safety is indeed a problem? Otherwise why do so many solutions exist for it? Yeah, Rust definitely is not the only sol…

> So.... Sounds like memory safety is indeed a problem? Otherwise why do so many solutions exist for it?

Memory safety and memory management are different things. Scripting languages remove the burden of manual memory management; as a side effect, they also tend to be memory safe, but that hasn't been the main motivation.

Re: Leaving Rust gamedev after 3 years

#826

Earlier quoted context omitted.

I love Rust, but a crashing released game is better than a half-finished "perfect" game, or a game where you couldn't iterate quickly, and ended up with a perfectly tuned, unfun game.

> a crashing released game is better than a half-finished "perfect" game For who? I, and I'm pretty sure most other gamers, would rather a fully-finished "perfect" game that took twice as long.

It's a chicken-egg problem. You won't even see 10% of the bugs lurking in your game without releasing it to a wider audience, no matter how long you worked on it or how good your QA process is (that's what Steam's Early Access is for after all). YMMV depending on the complexity of the game of course.

But even if your game code is perfect and completely bug free, there are so many weird PC configs and buggy drivers in the wild that your game will crash for some users. And for the affected users it doesn't matter whether that crash is caused by crappy game code, or some crappy 3rd party software interfering with your game. For the user it's always the game's fault ;)

Re: Leaving Rust gamedev after 3 years

#827

Earlier quoted context omitted.

So you're saying if you write your database engine in C++ you're not going to see any segfaults? https://jira.mariadb.org/browse/MDEV-14248?jql=text%20~%20%2...

No, they're saying that you will still see segfaults if you write it in Rust, because Rust's borrow checker is unusable in that environment.

That doesn't seem to be at all what they're saying, but in any case I checked SurrealDB (biggest Rust DB I could find) and there was exactly one report of a segfault and the developers couldn't reproduce it.

As far as I can tell about 5% of mariadb bugs mention segfaults, compared to 0.2% for SurrealDB.

I mean it's fairly obvious that even if some code in a Rust database is `unsafe` because it deals with manual paging and DMA and whatever, most of the code is going to be safe code.

Re: Leaving Rust gamedev after 3 years

#828
post #615

Earlier quoted context omitted.

I sometimes wonder if the problem with rust is that we have not yet had a major set of projects which drive solutions to common dev problems. Go had google driving adoption, which in turn drove open source efforts. The language had to remain grounded to not interfere with the doing of building back-end services. Rust had mozilla/servo which was ultimately unsuccessful. While there are more than a few companies uinf r…

I really think the problem of Rust is the borrow checker. Seriously. It is good but it is overkill. You have to do and plan all things around it and discourages a lot of patterns or makes them really difficult to refactor. I would encourage people to understand Hylo's object model and mutable value semantics. I thinks something like that is far better, more ergonomic and very well-performing (in theory at least).

You can use unsafe code and pointers if you really want, but code will be unsafe, like C or C++.

Re: Leaving Rust gamedev after 3 years

#829
I'm amazed that we still willingly put heavy compute into compile steps

The trade off is always reload ability

We have CI, we have LSP places we can put heavy checks without sacrificing our ability to hot reload fast

In some checkers you can put in your own custom checks too

Re: Leaving Rust gamedev after 3 years

#830

Earlier quoted context omitted.

Based on what I've seen, various forms of censorship and suppression are often employed in such cases, rather than outright "flaming" or other discussion-based approaches. It really depends on where and how the discussion is taking place, and what censorship methods the website/platform/medium involved offers. Sometimes users are just outright banned or shadow-banned, if those happen to be options. Sometimes forum th…

Ok, do you have a concrete example of this?

[deleted]
Post reply on HN