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

721–730 of 996 posts

Re: Leaving Rust gamedev after 3 years

#721

Post by pjmlp »

jltsiren wrote: post #478
fooker wrote: post #450

Earlier quoted context omitted.

A C++ replacement must have really strong and seamless C++ interop to be considered by anyone currently using C++. You can't have a C++ replacement by ignoring existing C++ users and libraries, no matter how good the the language is. Swift from Apple and Carbon from Google are stronger contenders at this point.

No language from Apple / Google / Microsoft / whatever can ever be a serious replacement for C++. When the development of the language is dominated by a single entity, the risk that the interests of that entity override those of other users is simply too high. Vendor-specific languages are fine, if you are developing something for that vendor's ecosystem. But if you don't want to lock your code to a specific ecosyste…

C++ is only independent on the surface, as all the big players seat at WG21, and it goes where their votes say it goes, plus what actually gets implemented into compilers (none of them is 100% ISO compliant, each one has minor compliance issues).

Same applies to C, stuff like C23 is decided by who gets to join WG14.

In both cases, someone has to buy the final standard from ISO.

Re: Leaving Rust gamedev after 3 years

#722

Post by int_19h »

IshKebab wrote: post #702
jandrewrogers wrote: post #421

Earlier quoted context omitted.

That assertion was specifically qualified in the context of database engines, for which it is true. I definitely write bugs but I haven't seen a segfault or memory corruption in years. That is more of a C thing than a C++ thing. It is kind of difficult to have a segfault or memory corruption with explicitly paged object memory, since there can't be any pointers and these complex objects are bound-checked at compile-t…

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.

Re: Leaving Rust gamedev after 3 years

#723

Post by pjmlp »

jltsiren wrote: post #558
fooker wrote: post #515

Earlier quoted context omitted.

I don't disagree. Pragmatic considerations tend to win over ideological ones though. Consider Java's success.

I was thinking more about pragmatic issues, and Java is a good example of them. It's a widely used language, but it's also a huge failure. 25 years ago, Java was supposed to be the new general-purpose language you could use for everything. Universities rushed to teach it to everyone. There was a lot of initial success, but then Java started losing ground. The direction the language was going was not good for many app…

Powering 80% of the mobile phone market, Amazon infrastructure, the IDEs everyone around here likes to rave about, is good enough success.

Additionally, everyone and their dog seems keen in replicating Java application servers with Kubernetes and WASM.

Re: Leaving Rust gamedev after 3 years

#724

Post by otabdeveloper4 »

dboreham wrote: post #486
cmrdporcupine wrote: post #404

Earlier quoted context omitted.

"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." 100% this. As I say elsewhere in these threads: Rust is the language that Tokio ate. It isn't even just async viral-chain-effect, it's that on…

Disappointing to hear this after battling the same nonsense in JS for years.

Rust is a language made and used by Dunning-Kruger people who violently react to having to learn the prior art.

What did you really expect?

Re: Leaving Rust gamedev after 3 years

#725

Post by suby »

jsheard wrote: post #398
VelesDude wrote: post #344

Earlier quoted context omitted.

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…

That light flickering is quite cool, thanks for sharing. It reminds me of the Wilhelm scream, but on a much smaller scale of course.

Re: Leaving Rust gamedev after 3 years

#726

Post by Keyframe »

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.

"Fearless concurrency"

Re: Leaving Rust gamedev after 3 years

#727

Post by karmarepellent »

cmrdporcupine wrote: post #413
matheusmoreira wrote: post #363

Earlier quoted context omitted.

> 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. Can you please elaborate on this? I see a lot of similar concerns in other contexts too. Linux kernel's scheduler for example. Is it a throughput/latency tradeoff?

The current popularity of the async stuff has its roots in the classic "c10k" problem. ( https://en.wikipedia.org/wiki/C10k_problem ) A perception among some that threads are expensive, especially when "wasted" on blocking I/O. And that using them in that domain "won't scale." Putting aside that not all of use are building web applications (heterodox here in HN, I know)... Most people in the real world with real appl…

> Putting aside that not all of use are building web applications

Perfect moment to mention "rouille" which is a very lightweight synchronous web server framework. So even when you decide to build some web application you do not necessarily have to go down the tokio/async route. I have been using it for a while at work and for private projects and it turned out to be pretty eye-opening.

Re: Leaving Rust gamedev after 3 years

#728

Post by Tade0 »

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

> Also, ECS is, IMHO, a useful pattern for some systems, but it is a pain in the butt to use with gameplay or UI code.

Not a game developer, but each time I tried to make one not using ECS(or something at least similar in spirit) I quickly found myself not being able to proceed due to the sheer mess in the codebase.

How does one normally avoid that?

Re: Leaving Rust gamedev after 3 years

#729

Post by KaiserPro »

hi-v-rocknroll wrote: post #253
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,…

As a non-game dev who uses Rust and Elixir, Rust wouldn't be my first pick for a large gamedev studio for multiple reasons. As for alternatives worth evaluating: Crystal, Cython (compiled Python), or Nim could result in increased gamedev productivity over C++ or C#. Maybe even Go because the iteration and compile times are very fast, and the learning curve is very low.

> Cython (compiled Python), or Nim could result in increased gamedev productivity over C++ or C#

If you're starting from scratch, then maybe. Having had to crash learn games dev (ex VFX systems person) Unity + c# is just so nice to use. most of the easiness of python, but with proper strict typing. (which you can turn off, if you want)

plus the wealth of documentation, its great. I imagine unreal is quite good in that regard too.

Re: Leaving Rust gamedev after 3 years

#730

Post by KaiserPro »

Repulsion9513 wrote: post #618
CJefferson wrote: post #599

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.

perfect is the enemy of good. You never release anything thats perfect.

Perfect is impossible.

Post reply on HN