Live data from Hacker News

Leaving Rust gamedev after 3 years

loglog.games

381–390 of 996 posts

Re: Leaving Rust gamedev after 3 years

#381
post #375

Earlier quoted context omitted.

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

Aside from a physics simulation, I'm curious as to what you think would be a positive cost benefit from that level of multithreading for the majority of game engines. Graphical pipelines take advantage of the concept but offload as much work as possible to the GPU.

Animations are an example. I landed code in Bevy 0.13 to evaluate all AnimationTargets (in Unity speak, animators) for all objects in parallel. (This can't be done on GPU because animations can affect the transforms of entities, which can cause collisions, etc. triggering arbitrary game logic.) For my test workload with 10,000 skinned meshes, it bumped up the FPS by quite a bit.

Re: Leaving Rust gamedev after 3 years

#382

> wait I can't add this new thing because things will no longer compile, and there's no workaround other than code restructuring I definitely think that's a great feature. I want to learn on day 2 that the design is a dead end, not on day 101 when I ship on day 100 and there was a race condition on day 2 I never noticed. But the thing about gamedev (I guess - I'm not a game developer) is that the code being great and…

I think the point is that there are few "code related" dead ends in game code with good game play that can't be dealt with using enough effort. There are plenty of "game play related" dead ends that no amount of clean code can help out.

To that end, whatever can help you explore the game play the fastest is what you want.

Re: Leaving Rust gamedev after 3 years

#383

Earlier quoted context omitted.

I think whether you prefer Rust or a scripting language like Lua for high-level game logic comes down to what your needs are and personal preference. There are reasonable arguments on both sides.

> There are reasonable arguments on both sides. What are the reasonable arguments for using Rust[1] for game logic instead of a scripting language like Lua? [1] Or C++, etc.

Rust, in my view, is easy to justify over C++: the Cargo ecosystem makes high-quality libraries accessible, you'll spend less time debugging crashes, the language is more modern so you don't have to deal with stuff like header files, etc.

Compared to a scripting language like Lua, the benefits of Rust are more situational. Rust code runs a lot faster, and it takes better advantage of parallelism. It also has no garbage collection overhead. Does that outweigh the downsides? It's entirely dependent on your game and which logic in particular you're talking about.

Re: Leaving Rust gamedev after 3 years

#384

Earlier quoted context omitted.

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.

| Go because the iteration and compile times are very fast Safety is important and for certain applications, Rust is unrivaled. But for games, like web apps, where time to market and innovation can be just as if not more important than being free of runtime errors, Go is more suited to rapid development than Rust on compile times alone. Of course, the libraries and support for both aren't quite there yet, so at this…

I agree. We almost have a paradox of choice nowadays because it's easier than ever to create new language platforms. Rust is something different because its thesis is safety and performance by default, more or less optimized for systems development primarily, but at the bargain of making dangerous things more complicated to accomplish somewhat intentionally. Unconventional languages are sometimes used as a conspicuous challenge to attract developers or to attempt to move some parts of an industry into new territory.

Re: Leaving Rust gamedev after 3 years

#385

Earlier quoted context omitted.

Server side rendering for games.

That's a thing?

Absolutely! Any sort of multiplayer game needs a source of authority if you want to prevent cheats like a hacked client lying about its position, and a really good way to do that is load the geometry of your level and run physics checks server side at a lower frequency than once per frame. Godot and Unity both support headless builds for exactly this reason, it's basically the whole game engine, minus the renderer, audio, and UI systems, usually.

Re: Leaving Rust gamedev after 3 years

#386

Earlier quoted context omitted.

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.

Does Crystal support Hot Reloading? The slow compilation speed is a non-starter for me.

Haha. Nope. Maybe Nim, V*, Go*, or Elixir would be a better choice for such a use-case.

* So fast, they really don't need HCR.

Re: Leaving Rust gamedev after 3 years

#387

Earlier quoted context omitted.

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

Disagree the adoption of C++ was more about Moore's law than ecosystem, although having compilers that were beginning to not be completely rubbish also helped.

I worked on many of Activision's games 1995-2000 and C++ was the overwhelming choice of programming language for PC games. C was more common for console. In 1996 the quality of MSFT IDE/ Compiler, plus the CPUs available at the time was such that it could take an hour to compile a big game. By 1998 it was a few minutes. As I recall I think MSFT purchased another companies compiler and that really changed Visual Studio.

Re: Leaving Rust gamedev after 3 years

#388

Earlier quoted context omitted.

> at the cost of latency and throughput. Compared to what? Doing epoll manually?

Threading, probably.

Async/await isn't related to threading (although many users and implementations confuse them); it's a way of transforming a function into a suspendable state machine.

Re: Leaving Rust gamedev after 3 years

#389

Starting by saying I fundamentally agree wrt iteration speed. This is ultimately why [C/C++]/Lua was such a thing for a while, and it seems quite plausible that you could benefit from a core engine in rust bound to a scripting language. But ultimately I sense the subtext here is much the same as with other Rust problems: the object oriented baby has been thrown out with the bathwater, often in the name of premature o…

YMMV, but I find C# and TypeScript to have a "Goldilocks" mix of OOP and FP that you can take advantage of the strengths of each where it makes sense.

You’re absolutely right, they are incredibly pragmatic.

Re: Leaving Rust gamedev after 3 years

#390

Earlier quoted context omitted.

> My impression of Rust is that it's a very opinionated language It's not though. There's only one thing Rust is opinionated about. > that wants everybody to program in a specific way that emphasizes memory safety above everything. Well yes, that is literally the core proposition and purpose of the language. That's like saying java is opinionated because it wants to manage the memory. > I just don't think the kinds o…

Rust also is opinionated that you don't want to write shared libraries or plugins. You can do both, but only if you drop down to memory unsafe C interfaces. The default is statically compile all applications into one program. Rust also really wants you do to use their build system and package manager, you can avoid both but everything will fight you.

> Rust also is opinionated that you don't want to write shared libraries or plugins.

Not having a solution is not the same as having an opinion.

If you have years to spend on plugging at ABI stabilisation, generics and proc macros in dynamic linking, and redistributable std, I’m sure the core devs would be happy for you to.

> Rust also really wants you do to use their build system and package manager, you can avoid both but everything will fight you.

What do you mean everything will fight you? It sounds like you’re confusing rust and its ecosystem.

Post reply on HN