Live data from Hacker News

Leaving Rust gamedev after 3 years

loglog.games

241–250 of 996 posts

Re: Leaving Rust gamedev after 3 years

#241

Rust... what is it good for? "Systems programming" ... Rust is not good for raw performance. Neither for prototyping and iteration. Personally I think operating systems (kernels) should be as performant as possible, and C/C++ has been good enough for decades. Anyone really unhappy with Linux/BSD/Windows/macOS performance? What systems are we talking about that benefits from Rust? Advanced weapon systems that should a…

Well, as far as I can tell, in the big language shootout (which is still the only decent language benchmark I know, but if you have others, I'd be happy to read them), in all the individual benchmarks I've looked at Rust is either first or within 3% performance of being first. So, this suggests that Rust is actually pretty good for raw performance.

In addition, I know that I'm way more productive for prototyping and iteration in Rust than in C, C++ (and I used to write C++ code professionally for a while), JavaScript, Go, Python (and I've been writing professionally in these three languages for a while now) etc. I _might_ be more productive in Java or OCaml. Yes, this is entirely anecdotal and it depends heavily on the kind of problems you're dealing with. I tend to focus on problems that have complicated invariants, and for which reproducing/pinpointing the issue in a debugger is a big annoyance.

> Google, fb, amazon, etc. use C/C++ to squeeze the most performance out of anything I/O heavy, and security is not an issue that deep in the stack, that's not the exploitation layer.

Interestingly, all these companies are migrating some of their systems to Rust. This suggests that they find the language convincing enough.

Re: Leaving Rust gamedev after 3 years

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

You more or less described Zig

Re: Leaving Rust gamedev after 3 years

#243

Earlier quoted context omitted.

Yes. C was invented in the '70s and only got standardized 20 years later. And Rust's ~20 years is young in systems lang terms (the alternatives, C and C++, are 50 and 40 years old). And nobody had TikTok back then.

You’re moving the goalposts though, the question was about Go. Which 3 years ago was nothing like Rust today. Because it’s much more pragmatic “here’s the trade-offs we had to make and why” language. Growing in and out of a cult isn’t a natural part of a language’s evolution like the GP comment suggested.

This is definitely untrue. I was bullied out of the golang community for asking about generics when I first started learning it. Obviously, I don't think my experience is indicative of the entire community, but the experience from the community left a bad taste in my mouth.

Re: Leaving Rust gamedev after 3 years

#244
post #154

Earlier quoted context omitted.

> Type checkers shouldn't get in the way of your code compiling. I don't get it, what's the point of type checking if not to reject invalid programs? The point of a type system isn't simply to add annotations to a programmer (and some type systems can omit them entirely) but to define the subset of programs that are correct within the set of all the programs that can be expressed. I understand (and have used in produ…

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…

Exactly this. Typing in the final version is great. Typing up front is almost always getting in the way.

Most interesting programs involve a lot of figuring things out as you go, and so any "tax" on that process is one you hope to avoid. The last thing you want is for the language itself to be the source of that tax any more than it has to be.

Re: Leaving Rust gamedev after 3 years

#245

Excellent article. Rust is my favorite language for several uses, but I'm becoming less optimistic about it as a versatile language long-term. An important point regarding the article is that it mixes rust shortfalls, and shortfalls of any language other than C++ for games. I've personally used Bevy for a 3D wave function renderer, but moved away from it in favor of a custom WGPU-engine due to Bevy's complicated ECS…

Why is async such a dealbreaker for this guy? Especially for web dev.

Re: Leaving Rust gamedev after 3 years

#246
post #5

Has there been any progress towards shipping Rust on consoles? I know the specifics are all under NDA, but to my knowledge nobody has even hinted that they've done it yet, even among the studios which are openly using Rust for backend or tooling stuff (e.g. Embark and Treyarch). OP only appears to release their games on PC so it's not a concern for them, but for the majority of developers not being able to fit into c…

[deleted]

Re: Leaving Rust gamedev after 3 years

#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/News/547 | grep "Fixed a crash that" | wc -l
  101
Maybe feeling like you're iterating fast isn't the same as getting to the destination faster.

Edit: Lol guys calm down with the down-vote party. I was counting crashes, not bugs:

  $ curl https://www.taleworlds.com/en/News/547 | grep "Fixed a bug that" | wc -l
  308
Does your C++ not crash, just theirs?

Re: Leaving Rust gamedev after 3 years

#248

> The problem you're having is only a problem because you haven't tried hard enough. You just need to read another 50,000 word fasterthanlime essay. Then you'll not have problems any more. > That being said, there is an overwhelming force in the Rust community that when anyone mentions they're having problems with Rust the language on a fundamental level, the answer is "you just don't get it yet, I promise once you g…

Rust is a language with a very high mental cost to use effectively. It requires some fundamental paradigm shifts in the way you write software, hence it's a hard language to be productive in. For some tasks, the tradeoff is worth it. Some individuals are naturally very inclined to use it. But for most people, for most tasks, it's simply not the right tool. It's not a general purpose language by any stretch of the ima…

If there were only two programming languages in the whole world, just two, no more; one better fitted for OS kernels and one better fitted for game programming, which one would be considered a general purpose language?

I would argue, OS programming is definitely more general than game programming. Rust is great for OS related tasks, math, deep learning n other stuff, and maybe not so great at GUIs, or even bad at that, or just inconvenient as the article points out.

That means, it should be used for general stuff, and for programming games should be used a niche language, like Lua, Python etc. Especially for fast iteration and experimentation, break things and move lightning fast, typed languages are in disadvantage for sure, compared to untyped/weakly typed.

Re: Leaving Rust gamedev after 3 years

#249

Rust... what is it good for? "Systems programming" ... Rust is not good for raw performance. Neither for prototyping and iteration. Personally I think operating systems (kernels) should be as performant as possible, and C/C++ has been good enough for decades. Anyone really unhappy with Linux/BSD/Windows/macOS performance? What systems are we talking about that benefits from Rust? Advanced weapon systems that should a…

> Anyone really unhappy with Linux/BSD/Windows/macOS performance? I wasn't unhappy with Windows' performance in the 90s until I saw BeOS. This is the kind of thing we're in the dark about what could be because the faster, rewritten fron scratch, free from API baggage systems are nowhere to be found.

Haven't used BeOS, but to clarify, I do have issues with Windows and performance, especially general input latency and responsiveness when compared to Linux, as I use both daily. But overall I think it's decent, and at the very least, not the fault of the language used, but more about legacy issues and technical debt. Anyone having worked with winapi and mfc knows the codebase is a mess.

Re: Leaving Rust gamedev after 3 years

#250
post #154

Earlier quoted context omitted.

> Type checkers shouldn't get in the way of your code compiling. I don't get it, what's the point of type checking if not to reject invalid programs? The point of a type system isn't simply to add annotations to a programmer (and some type systems can omit them entirely) but to define the subset of programs that are correct within the set of all the programs that can be expressed. I understand (and have used in produ…

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…

I agree with this, but I don't think dynamic types is the only solution. Something like Roc[0] strikes a better balance: it gives you a flag for development, and when enabled, all compilation errors become warnings. The compiler substitutes every function it couldn't compile with one that panics at runtime.

[0] https://www.roc-lang.org/

Post reply on HN