Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Leaving Rust gamedev after 3 years

loglog.games

Post reply on HN
Print view View original

331–340 of 996 posts

Re: Leaving Rust gamedev after 3 years

#331

Post by celdon25 »

netbioserror wrote: post #305

I use Nim at work. It is a joy. I replaced a prototype Rust application which was confirmedly not a joy. None of Rust's highly opinionated safety semantics necessarily imply a better end product, and often make delivering an end product much more difficult. Rust has use cases, but it is a specialized hammer for a specific domain of nails. It is not the cure-all everyone wants it to be. If you're asking if you should…

> As an additional bonus, 99.9% of the code you write in a GC language never has to be about memory at all.

This is a bit of an oversimplification. If you are sloppy with "memory management" (unnecessary object lifetimes, unnecessary duplication, etc) even in a GC language, it is possible to have noticeable performance impacts. I'm not saying these languages aren't the right tool for the job, but it is not a free pass to ignore hardware limitations.

Re: Leaving Rust gamedev after 3 years

#332

Post by IshKebab »

jandrewrogers wrote: post #133
bdw5204 wrote: 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 indefinit…

> modern C++ is essentially as safe as Rust

This isn't even close to being true. I think memory safety isn't as important for games as it is for most software (though it is still quite important for multiplayer games!). But even if you write the most modern C++ possible I guarantee you are going to spend some of your time debugging segfaults, memory corruption and heisenbugs. Don't try and claim "I don't write bugs". Everyone does.

Re: Leaving Rust gamedev after 3 years

#333

Post by mrkeen »

lionkor wrote: post #297
mrkeen wrote: 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/…

With Rust and the exact time iteration times, management and deadlines, you end up with the same amount, just theyre panic!() instead. Thats an improvement, sure, but its fighting a symptom.

With modern languages that take safety more seriously, it's a lot easier to spot places where the code 'goes wrong'.

In an older language, you have nothing to tell you whether you're about to dereference null:

   foo.bar.baz = ...;
Even if you've coded it 100% correctly, that line of code still looks the same as code which will segfault. You need to look elsewhere in codebase to make sure the right instructions populated those fields at the right time. If I'm scrolling past, I'll slow down everytime to think "Hey, will that crash?"

Compare that with more safety focused languages where you can see the null-dereferences on the page. Unwrap() or whatever it is in Rust. Since they're visually present, you can code fast by using the unsafe variants, come back later, and know that they won't be missed in a code review. You can literally grep for unsafe code to refactor.

Re: Leaving Rust gamedev after 3 years

#334

Post by kbolino »

sidkshatriya wrote: post #254
kbolino wrote: post #220

Earlier quoted context omitted.

Having worked with Go for about a decade now, I largely agree that nil is a pain in the ass to work with, and the language has largely done nothing to make it better. However, Go (mostly) doesn't have exceptions. Ordinary problems are represented by non-nil errors, which are values. Panics exist but really are reserved for exceptional situations (with the number 1 cause being, of course, dereferencing nil).

Nil in go is my biggest gripe with the language. Why keep repeating “the billion dollar mistake” in a relatively newly designed language??

There are a lot of ways in which Go handles nil better than C handles NULL. At the very least, a panic is better than a segfault. And carefully written code can avoid most kinds of nil panics entirely. So I guess the language's authors thought this would be enough to overcome the mistake. But I don't think they went far enough. The very limited type system and the lack of nil-safe operators make it not very ergonomic to write and read such "carefully written" code; design decisions in some key parts of the standard library completely undermine the language's attempts to minimize nil; and then there's the "untyped nil" default value for interfaces, which panics if you just look at it funny.

Re: Leaving Rust gamedev after 3 years

#335

Post by pcwalton »

delfinom wrote: post #296
hot_gril wrote: post #268

Earlier quoted context omitted.

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

Kind of both in my opinion. But rust is bringing nothing to the table that games need. At best rust fixes crash bugs and not the usual logic and rendering bugs that are far more involved and plague users more often.

The ability of engines like Bevy to automatically schedule dependencies and multithread systems, which relies on Rust's strictness around mutability, is a big advantage. Speaking as someone who's spent a long time looking at Bevy profiles, the increased parallelism really helps.

Of course, you can do job queuing systems in C++ too. But Rust naturally pushes you toward the more parallel path with all your logic. In C++ the temptation is to start sequential to avoid data races; in systems like Bevy, you start parallel to begin with.

Re: Leaving Rust gamedev after 3 years

#336

Post by p0nce »

WalterBright wrote: post #43

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

I agree, and D with the GC lets me prototype quickly. Its type system gets progressively stricter with constraints, for code that survives. I wouldn't want all the type system to apply to prototype code or a nascent program.

Re: Leaving Rust gamedev after 3 years

#337

Post by ativzzz »

duped wrote: post #264
ativzzz wrote: post #177

Earlier quoted context omitted.

Because often, and especially with heavily interactive programs like games or UIs (any web page), you don't know if something will be good or not until you build some working version of it. The more barriers there are (type checkers, compiler errors, etc), the longer it will take you to prototype something usable to check if what you're building is good. Sometimes, it's useful to bypass these things for a prototype a…

But a type error isn't an edge case! It means you've written something the compiler can't understand. > This is why typescript is so popular on the web - you can quickly prototype something with JS, then once you find the right solution, add types and productionize the code I think you've got it backwards - TS is popular because people want to use types up front, but it has to work with JS, which is so dynamic that i…

> But a type error isn't an edge case! It means you've written something the compiler can't understand.

I get it! But the compiler here is getting in the way, so Rust is the wrong tool choice here, or for anything that requires quick prototyping (like the OP said)

> writing code that where it is so difficult to use type information

It's not difficult, it just takes longer. Typing up front works well when you know exactly what you're building. When you don't, or are doing experimental design, they just get in the way until you've settled on a direction. This direction is not due to technical constraints or language choice, it's simply that designing complex user interactions is hard and you don't know it's correct until you have users use it

> dynamically typed languages

Because the cost of prototyping in a dynamic lang and then fully rewriting in a performant language is higher than having slower iteration speeds in typed languages. But also, this is why a large number of new non-web GUIs use electron (or are mac exclusive, which offers other benefits for GUI development)

> I think you've got it backwards - TS is popular because people want to use types up front,

Personally, I mix it up. There are things I know what their types will be no matter what so i add them up front. Then there are other things which I do not know, and I add those types at the end once i'm performing the final cleanup before code review

The nicest part is, TS runs regardless. I often refactor my types frequently since I get them wrong a lot (especially the up front ones) and have TS in a failing state while developing, but the TS compiler doesn't get in my way, and still works for the types that I expect to have working

Re: Leaving Rust gamedev after 3 years

#338

Post by meinersbur »

mrkeen wrote: post #247
stephc_int13 wrote: post #219

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

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.

Re: Leaving Rust gamedev after 3 years

#339

Post by notnullorvoid »

nu11ptr wrote: 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/…

As much as I dislike many of the legacy issues with JavaScript I find TypeScript to be the best language to iterate with. If Rust had GC without need for wrappers like RC though I think that would be my preferred iteration language. I mostly try to write my TS in a manner that would translate to Rust, but that's hard to do sometimes when it comes to memory management.

Re: Leaving Rust gamedev after 3 years

#340

Post by gpm »

tick_tock_tick wrote: post #192
cogman10 wrote: post #42

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?

I'd go read their mailing list and Reddit forms; especially when people run into issues doing stuff that's very simple in other languages. Never seen a more toxic programming community. Hopefully they calm down, or really get drown out, once there are a real number of jobs for people using Rust. Right now the evangelists outnumber the rank and file who are just using a language to get work done.

Rust hasn't had a mailing list for roughly a decade now...
Post reply on HN