Live data from Hacker News

Leaving Rust gamedev after 3 years

loglog.games

131–140 of 996 posts

Re: Leaving Rust gamedev after 3 years

#132

Earlier quoted context omitted.

Parts of the Rust community are toxic indeed, but I've been around long enough to recognize the same pattern in communities of other hot programming languages or frameworks in their up-and-coming phase. There's something about the new hot language/framework/paradigm that always attracts the type of people who wrap their identity up in the hot new thing. They take any criticisms of their new favorite thing as criticis…

> What I see now in certain Rust communities feels a lot like what I saw in Golang communities in the early days. I had similar experiences when React was the new kid on the block, too. Go was released in 2012, Rust in 2015. Are you saying we are still in the early days of Rust?

> Go was released in 2012, Rust in 2015. Are you saying we are still in the early days of Rust?

Release dates mean very little. Golang had rapid adoption early on. Rust only recently became one of the fastest growing languages. Golang stabilized a lot of things about the language and library early on. Rust still has a lot of common features gated behind nightly.

There is a fun tool for comparing the number of PRs on Github by language that shows the difference: https://madnight.github.io/githut/#/pull_requests/2024/1

So yes, I think we're in the early days of Rust.

Re: Leaving Rust gamedev after 3 years

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

> I just don't think the kinds of security bugs you get from C/C++ "unsafe" code are that big of a deal for games but they would be for a web site or an enterprise database.

Even for database engines specifically, modern C++ is essentially as safe as Rust and significantly more ergonomic. Rust's safety features can't reason about the case when all of your runtime objects live in explicitly paged memory with indefinite lifetimes and no fixed memory address, which is the norm in database kernels. You have to write the same code to make handling these objects safe and correct in Rust that you have to write in C++. You can't use normal pointers and allocators for this even if you wanted to.

Rust's safety is designed more for normal dynamic memory applications.

Re: Leaving Rust gamedev after 3 years

#134

> Making a fun & interesting games is about rapid prototyping and iteration, Rust's values are everything but that I found this to be true of C after many, many years coding in C. I noticed that the first selection of data layout stayed throughout the life of the code (with a lot of tweaks, additions, etc.). But didn't really think that much about it. Until I started writing code in D. It was easy to change the data…

That's a good example. I actually think dot syntax is really under-utilized sometimes. Although personally, I'd prefer that if v was a reference/pointer to a struct, that v.b simply performs a pointer offset, instead of auto-dereferencing like ->.

Re: Leaving Rust gamedev after 3 years

#135
As someone in a similar position (also ~3 years doing gamedev in Rust but only free time + open source), I feel very similarly.

There's low hanging fruit i've been complaining about for years where Rust is protecting us from ourselves - orphan rules, global state, ... Look, we're adults, we can make decisions with tredeoffs.

Compile times are a tougher one, I understand that Rust does analysis that is more complex than many langs and i feel ungrateful to people who spend their free time improving Rust. But also i don't think the complexity justifies all of it. Make dynamic linking easier, reduce how much needs to be recompiled, compile generics to dynamic dispatch in debug builds, etc. - there's gotta be a ton of stuff that can investigated.

ECS just plain sucks. People use it because what they want at first is some way to have relationships between entities. References/pointers are the obvious solution in most langs but in rust, they're obviously out. The second option is Vec and indices but that falls apart as soon as you start removing entities. The next step up the ladder of complexity should be generational arenas but for some reason people immediately reach for the big guns - ECS. And it infests their game with two things that make gamedev a slog - dynamic typing and boilerplate.

Boilerplate is obvious to anyone who has done gamedev the "obvious" way before. What could be projectile.shooter.score += 1 is multiple lines which (depending on your particular choice of ECS) usually involve generics. You shift your focus from tweaking your game logic and tuning the experience to typing out boiletplate.

Dynamic typing means entities are no longer structs with fields where you can understand how they relate to each other at a glance but instead any component can be anywhere, entities are no longer real, refactoring always causes silent bugs.

However, by far the biggest issue is the community's handling of criticism.

There are practically no experienced gamedevs coming to Rust from other langs so there's nobody to give Rustaceans a reality check. Rust gamedevs are almost always writing their first game (or, yes, engine). And there's nothing wrong with that, i was writing my first game at one point too. But their attitude is that they chose Rust because they heard it's the best and they got invested in the language because it's hard(er) to learn and now with all this investment if they hear rust or their particular favorite engine might not be that great, it feels like wasted effort so they get emotional and defensive.

I've personally chatted with over half a dozen other gamedevs who came to rust with years of experience under their belt and a common pattern is that they avoid the rust (gamedev) community because they're beat down by the negativity heaped upon them every time they try to discuss the negatives. It doesn't matter they take every effort to offer constructive criticism, it becomes a social instead of technical topic.

I came to Rust because i care about code correctness and, well, quality (of tooling, docs, testing). And Rust delivers there on a lot of that. But i also wanted to write games of a larger scale than can be done in one person. My hope was that there'd be other people with the same values who wanna build cool games together. Instead there's a low single digit number of serious open source projects and a bunch of small one man games and a a whole lot of loud people who seem to think gamedev is about hyping up an engine like it's a sports team.

Myself, I apparently chose the wrong engines for my games in both cases. Not because they're bad technically. In fact, having 5 years of gamedev experience before Rust, i think my choices are better from a technical perspective but there's just not the critical mass to build a serious open source game around them.

Re: Leaving Rust gamedev after 3 years

#136
post #27

This is a very brave post to write given how incendiary responses to rust criticism can be, but this matches my experience entirely.

This is a textbook example of poisoning the well. [0] We see it used in every discussion about pros and cons of a language on HN.

It's some variation of "People who like this language can't handle criticism/are part of a cult/etc." The idea being that this will preclude anyone from responding to a criticism, because that would confirm the comment.

[0] https://www.logicallyfallacious.com/logicalfallacies/Poisoni...

Re: Leaving Rust gamedev after 3 years

#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 written in Rust by now. That hasn't happened, and it's probably not going to happen, for the reasons the author gives.

* He's right about the pain of refactoring and the difficulties of interconnecting different parts of the program. It's quite common for some change to require extensive plumbing work. If the client that talks to the servers needs to talk to the 2D GUI, it has to queue an event.

* The rendering situation is almost adequate, but the stack isn't finished and reliable yet. The 2D GUI systems are weak and require too much code per dialog box.

* 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.

* I have less trouble with compile times than he does, because the metaverse client has no built-in "gameplay". A metaverse client is more like a 3D web browser than a game. All the objects and their behaviors come from the server. I can edit my part of the world from inside the live world. If the color or behavior or model of something needs to be changed, that's not something that requires a client recompile.

The people using C# and Unity on the same problem are making much faster progress.

[1] https://video.hardlimit.com/w/7usCE3v2RrWK6nuoSr4NHJ

Re: Leaving Rust gamedev after 3 years

#138
post #73

In my experience, fundamentally when you're starting a software project, you need to make a strong up-front decision between two things: 1. I am using technology in order to build this thing. 2. I am building this thing in order to use this technology. Developers often fall in the (2) camp but don't admit it. There's an allure to using the new, sexy tech that will solve all their problems, whether that's Rust, Kubern…

> you need to make a strong up-front decision

Can one always realistically do so? I suspect the underlying unspoken assumption is that one must be ideally informed about all the possible potential pitfalls and gotchas they may face when using any given technology. Aka having a very good (ideally, perfect) knowledge of the technology and its surrounding ecosystem.

It wasn't just once or twice when I've picked some very promising library or tool only to learn something isn't exactly as I hoped (or as it was advertised - docs can lie, too) after I've already spent some non-negligible time implementing something with it. Save for some teenage keyboard mashing some decades ago I'm not a game developer, but I suspect this is universal experience no matter the niche.

> Developers often fall in the (2) camp but don't admit it.

There's also a mixed approach, where people admit "I want to build this thing and use this technology, and I suspect they're a potential good match so I'm gonna try both at the same time". Any even slightly creative person must have an urge to learn and explore new things, even if they aren't exactly necessary for a task at hand. Checking on the promise, if it holds true - sometimes it does and you get a new tech you love, quite frequently it doesn't and you have a bad day.

Re: Leaving Rust gamedev after 3 years

#139

The Rust community is one of the top arguments against rust. I've never before been so condescended to as when attempting to ask questions there. Their lack of care for perf also drives me up a wall. Anytime they propose adding an extra layer of indirection to get around the borrow checker, I have to explain yet again that with the way modern CPUs work, extra layers of indirection have serious cache-related perf cost…

> when attempting to ask questions there

Could you please give an indication of which venues you've encountered this kind of condescension in? I don't tend to see this in the spaces I frequent, but I know it is happening, and I wish it weren't. We try, sometimes, to provide some official messaging discouraging this kind of condescension, but perhaps there's something more we can do.

Post reply on HN