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.
Leaving Rust gamedev after 3 years
381–390 of 996 posts
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…
To that end, whatever can help you explore the game play the fastest is what you want.
Re: Leaving Rust gamedev after 3 years
#383Earlier 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.
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
#384Earlier 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…
Re: Leaving Rust gamedev after 3 years
#385Earlier quoted context omitted.
Server side rendering for games.
That's a thing?
Re: Leaving Rust gamedev after 3 years
#386Earlier 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.
* So fast, they really don't need HCR.
Re: Leaving Rust gamedev after 3 years
#387Earlier 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.
Re: Leaving Rust gamedev after 3 years
#388Earlier quoted context omitted.
> at the cost of latency and throughput. Compared to what? Doing epoll manually?
Threading, probably.
Re: Leaving Rust gamedev after 3 years
#389Starting 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.
Re: Leaving Rust gamedev after 3 years
#390Earlier 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.
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.