3 years of fulltime Rust game development, and why we're leaving Rust behind

This page summarizes the projects mentioned and recommended in the original post on news.ycombinator.com

InfluxDB - Power Real-Time Data Analytics at Scale
Get real-time insights from all types of time series data with InfluxDB. Ingest, query, and analyze billions of data points in real-time with unbounded cardinality.
www.influxdata.com
featured
SaaSHub - Software Alternatives and Reviews
SaaSHub helps you find the best software and product alternatives
www.saashub.com
featured
  • rust-ecosystem

    Rust wants & tracking for Embark 🦀

  • InfluxDB

    Power Real-Time Data Analytics at Scale. Get real-time insights from all types of time series data with InfluxDB. Ingest, query, and analyze billions of data points in real-time with unbounded cardinality.

    InfluxDB logo
  • symbiants

    Ant Colony Sim + Daily Mental Health Exercises

  • I've experienced a lot of these concerns while building https://github.com/MeoMix/symbiants

    I have a simple question that maybe someone smarter than me can answer confidently:

    If I want to build something akin to Dwarf Fortress (in terms of simulation complexity) as a browser-first experience - what stack should I choose?

    Originally, I prototyped something out using React, PixiJS, and ReactPixi (https://github.com/MeoMix/antfarm). The two main issues I ran into were the performance of React's reconciler processing tens of thousands of entities when most weren't changing (despite heavy memoization) and GC lurching due to excess object allocations. My takeaway was that if I wanted to continue writing in JS/TS that I would need to write non-idiomatic code to avoid excess allocations and abandon React. This approach would result in me effectively creating my own engine to manage state.

    I decided to not go that direction. I chose Rust because no GC is a language feature (especially good since GCs in WASM are heavy) and I chose Bevy because it seemed like a fairly structured way to mutate a large amount of code.

    Progress has been slow for a lot of the reasons listed in this article. I've written a lot of this off to WASM being a new frontier for game dev and rationalized it by noting there's not a lot of complex simulation games running in browser (that I'm aware of). It's not clear to me if that's actually true, though.

  • antfarm

  • I've experienced a lot of these concerns while building https://github.com/MeoMix/symbiants

    I have a simple question that maybe someone smarter than me can answer confidently:

    If I want to build something akin to Dwarf Fortress (in terms of simulation complexity) as a browser-first experience - what stack should I choose?

    Originally, I prototyped something out using React, PixiJS, and ReactPixi (https://github.com/MeoMix/antfarm). The two main issues I ran into were the performance of React's reconciler processing tens of thousands of entities when most weren't changing (despite heavy memoization) and GC lurching due to excess object allocations. My takeaway was that if I wanted to continue writing in JS/TS that I would need to write non-idiomatic code to avoid excess allocations and abandon React. This approach would result in me effectively creating my own engine to manage state.

    I decided to not go that direction. I chose Rust because no GC is a language feature (especially good since GCs in WASM are heavy) and I chose Bevy because it seemed like a fairly structured way to mutate a large amount of code.

    Progress has been slow for a lot of the reasons listed in this article. I've written a lot of this off to WASM being a new frontier for game dev and rationalized it by noting there's not a lot of complex simulation games running in browser (that I'm aware of). It's not clear to me if that's actually true, though.

  • bevy_mod_scripting

    Bevy Scripting Plugin

  • As someone who's become a core contributor to Bevy lately, while also doing contract work in Unity on the side, I obviously disagree with the idea that Rust isn't up to the task of game dev. The grass isn't greener on the Unity side, with a mountain of technical debt holding the engine back. (They're still using Boehm GC in 2024!) Bevy is a breath of fresh air just because it's relatively new and free of legacy. Using Rust instead of C++ is just one part of that. Bevy has a more modern design throughout: for instance, it has a relatively straightforward path to GPU-driven rendering in an integrated system, without having to deal with three incompatible render pipelines (BiRP, HDRP, URP).

    What I find more interesting is the parts of the article that boil down to "Rust isn't the best language for rapid development and iteration speed". And that may well be true! I've long thought that the future of Bevy is an integrated Lua scripting layer [1]. You don't even need to get into arguments about the suitability of the borrow checker: it's clear that artists and designers aren't going to be learning Rust anytime soon. I'd like to see a world in which Rust is there for the low-to-mid-level parts that need performance and reliability, and Lua is there for the high-level logic that needs fast iteration, and it's all a nicely integrated whole.

    Long-term, I think this world would actually put Bevy in a better place than the existing engines. Unity forces you into C# for basically everything, which is both too low-level for non-programmers to use and too high-level for performance-critical code (unless you have a source license, which no indie developer has). Unreal requires C++, which is even more difficult than Rust (IMO), or Blueprints, which as a visual programming language is way too high-level for anything but the simplest logic. Godot favors GDScript, which is idiosyncratic for questionable gain. I think Rust and Lua (or something similar) would put Bevy in a Goldilocks spot of having two languages that cover all the low-, mid-, and high-level needs well.

    As for the other parts of the article, I disagree with the ECS criticism; ECS has some downsides, but the upsides outweigh the downsides in my view. I do agree that Bevy not having an official editor is an ongoing problem that desperately needs fixing. Personally, I would have prioritized the editor way higher earlier in Bevy's development. There is space_editor [2] now, which is something.

    [1]: https://github.com/makspll/bevy_mod_scripting

    [2]: https://github.com/rewin123/space_editor

  • space_editor

    bevy prefab editor

  • As someone who's become a core contributor to Bevy lately, while also doing contract work in Unity on the side, I obviously disagree with the idea that Rust isn't up to the task of game dev. The grass isn't greener on the Unity side, with a mountain of technical debt holding the engine back. (They're still using Boehm GC in 2024!) Bevy is a breath of fresh air just because it's relatively new and free of legacy. Using Rust instead of C++ is just one part of that. Bevy has a more modern design throughout: for instance, it has a relatively straightforward path to GPU-driven rendering in an integrated system, without having to deal with three incompatible render pipelines (BiRP, HDRP, URP).

    What I find more interesting is the parts of the article that boil down to "Rust isn't the best language for rapid development and iteration speed". And that may well be true! I've long thought that the future of Bevy is an integrated Lua scripting layer [1]. You don't even need to get into arguments about the suitability of the borrow checker: it's clear that artists and designers aren't going to be learning Rust anytime soon. I'd like to see a world in which Rust is there for the low-to-mid-level parts that need performance and reliability, and Lua is there for the high-level logic that needs fast iteration, and it's all a nicely integrated whole.

    Long-term, I think this world would actually put Bevy in a better place than the existing engines. Unity forces you into C# for basically everything, which is both too low-level for non-programmers to use and too high-level for performance-critical code (unless you have a source license, which no indie developer has). Unreal requires C++, which is even more difficult than Rust (IMO), or Blueprints, which as a visual programming language is way too high-level for anything but the simplest logic. Godot favors GDScript, which is idiosyncratic for questionable gain. I think Rust and Lua (or something similar) would put Bevy in a Goldilocks spot of having two languages that cover all the low-, mid-, and high-level needs well.

    As for the other parts of the article, I disagree with the ECS criticism; ECS has some downsides, but the upsides outweigh the downsides in my view. I do agree that Bevy not having an official editor is an ongoing problem that desperately needs fixing. Personally, I would have prioritized the editor way higher earlier in Bevy's development. There is space_editor [2] now, which is something.

    [1]: https://github.com/makspll/bevy_mod_scripting

    [2]: https://github.com/rewin123/space_editor

  • glicol-cli

    glicol cli: cross-platform music live coding in terminal

  • I've worked on Ambient Engine and now on the Bevy engine. I totally agree with these points, very valuable. I only make some comments from my professional (audio) perspective:

    We need the highlight author's affirmation of cli. Rust's tui (ratatui) is great. I used it to make Glicol-cli [1]. If you are a Linux user, you are welcome to test the music production of the code.

    Speaking of game audio, I actually think rust is perfect for audio. I have also continued to develop Glicol recently, and my recent goal (starting tomorrow) is the bevy_glicol plug-in. I want to solve bevy's audio problem on the browser.

    All in all, even though I've had my share of pain with ecs, I still think rust is very valuable for game and app development, maybe not multiplayer AAA, maybe practical apps.

    [1] https://github.com/glicol/glicol-cli

    [2] https://github.com/chaosprint/glicol

  • glicol

    Graph-oriented live coding language and music/audio DSP library written in Rust

  • I've worked on Ambient Engine and now on the Bevy engine. I totally agree with these points, very valuable. I only make some comments from my professional (audio) perspective:

    We need the highlight author's affirmation of cli. Rust's tui (ratatui) is great. I used it to make Glicol-cli [1]. If you are a Linux user, you are welcome to test the music production of the code.

    Speaking of game audio, I actually think rust is perfect for audio. I have also continued to develop Glicol recently, and my recent goal (starting tomorrow) is the bevy_glicol plug-in. I want to solve bevy's audio problem on the browser.

    All in all, even though I've had my share of pain with ecs, I still think rust is very valuable for game and app development, maybe not multiplayer AAA, maybe practical apps.

    [1] https://github.com/glicol/glicol-cli

    [2] https://github.com/chaosprint/glicol

  • SaaSHub

    SaaSHub - Software Alternatives and Reviews. SaaSHub helps you find the best software and product alternatives

    SaaSHub logo
  • windows-rs

    Rust for Windows

  • I'd say Rust does have that big ticket ecosystem push. Microsoft has been embracing Rust lately, with things like official Windows bindings [1].

    The bigger problem is just inertia: large game engines are enormous.

    [1]: https://github.com/microsoft/windows-rs

  • embryo-engine

    An intensely data-driven, dynamic ECS-based game engine optimized and specialized for immersive sims and sandbox open world RPG games, designed with modding and easily creating large amounts of content and complex simulations specifically in mind. For those who look back on Deus Ex, Thief, or Morrowind fondly.

  • Quick note: I'm actually very slowly prototyping something like this here: https://github.com/alexispurslane/embryo-engine/

    I'm disabled so I don't have a lot of energy to work on it often, but, especially once I nail down the last few design issues, I'd really love help, or even just a few eyes on the project to encourage me ;)

  • Nim

    Nim is a statically typed compiled systems programming language. It combines successful concepts from mature languages like Python, Ada and Modula. Its design focuses on efficiency, expressiveness, and elegance (in that order of priority).

  • awesome-cl

    A curated list of awesome Common Lisp frameworks, libraries and other shiny stuff.

  • I know you're not asking for recommendations, but Lisp, particularly SBCL, really seems to check all your boxes. I say this as someone who generally reaches for Scheme when it comes to Lisps too.

    There are a few game engines[0] for CL, but most of them seem to be catered specifically to 2D games.

    [0] https://github.com/CodyReichert/awesome-cl?tab=readme-ov-fil...

  • Umpire

    Combat Quest of the Millennium

  • * https://github.com/joshhansen/Umpire

  • SWARMMO

  • No blog unfortunately, the notes are all on paper. I have github page for the game where I ramble a bit: https://github.com/mikhmha/SWARMMO

    But I'm planning to release the game for testing next month! Its a browser "MMO" game too so its going to be easy to try out.

  • phaser

    Phaser is a fun, free and fast 2D game framework for making HTML5 games for desktop and mobile web browsers, supporting Canvas and WebGL rendering.

  • If you're targeting the browser first why not use a browser first library like PhaserJS [0]?. I don't see a reason to work around with WASM; HTML5 canvas might be everything that you need.

    [0] https://phaser.io/

  • SpacetimeDB

    Multiplayer at the speed of light

  • I don't use Rust for game dev but I do for low level libraries and find it easier than C++ to get started. I have enjoyed it more than Java and like it for different reasons than Go, but it feels good to program in.

    As for the design patterns that a complex game requires, if you are considering Rust for game dev and ecs design patterns it might be useful to check out projects that are Rust centric like https://spacetimedb.com/.

  • Bannerlord.CSharp.Scripting

    C# scripting for Mount & Blade 2: Bannerlord

  • And yet the fact that Bannerlord game logic is entirely in C# makes this possible:

    https://github.com/int19h/Bannerlord.CSharp.Scripting

    which in turn makes it a lot easier and more convenient to mod. Try that with Rust...

  • ffi-overhead

    comparing the c ffi (foreign function interface) overhead on various programming languages

  • The overhead for Go in benchmarks is insane in contrast to other languages - https://github.com/dyu/ffi-overhead Are there reasons why Go does not copy what Julia does?

  • todo-backend

  • rune

    An embeddable dynamic programming language for Rust. (by rune-rs)

  • burn

    Burn is a new comprehensive dynamic Deep Learning Framework built using Rust with extreme flexibility, compute efficiency and portability as its primary goals.

  • You can use libtorch directly via `tch-rs`, and at present I'm porting over to Burn (see https://burn.dev) which appears incredibly promising. My impression is it's in a good place, if of course not close to the ecosystem of Python/C++. At very least I've gotten my nn models training and running without too much difficulty. (I'm moving to Burn for the thread safety - their `Tensor` impl is `Sync` - libtorch doesn't have such a guarantee.)

    Burn has Candle as one of its backends, which I understand is also quite popular.

  • RustTokioBenchmark

    Simple benchmark comparing tokio mpsc with standard rust one

  • > If you ever pull up a debugger and step through an async Rust/tokio codebase, you'll get a good sense for what the overhead here we're talking about is.

    So I didn't quite do that, but the overhead was interesting to me anyway, and as I was unable to find existing benchmarks (surely they exist?), I instructed computer to create one for me: https://github.com/eras/RustTokioBenchmark

    On this wee laptop the numbers are 532 vs 6381 cpu cycles when sending a message (one way) from one async thread to another (tokio) or one kernel thread to another (std::mpsc), when limited to one CPU. (It's limited to one CPU as rdtscp numbers are not comparable between different CPUs; I suppose pinning both threads to their own CPUs and actually measuring end-to-end delay would solve that, but this is what I have now.)

    So this was eye-opening to me, as I expected tokio to be even faster! But still, it's 10x as fast as the thread-based method.. Straight up callback would still be a lot faster, of course, but it will affect the way you structure your code.

    Improvements to methodology accepted via pull requests :).

  • SaaSHub

    SaaSHub - Software Alternatives and Reviews. SaaSHub helps you find the best software and product alternatives

    SaaSHub logo
NOTE: The number of mentions on this list indicates mentions on common posts plus user suggested alternatives. Hence, a higher number means a more popular project.

Suggest a related project

Related posts

  • Bellclone: a simple 2D game about jumping

    2 projects | /r/rust | 17 Sep 2021
  • Exploring Rust game development, what should I look out for?

    3 projects | /r/rust_gamedev | 25 Feb 2021
  • Macroquad egui DevTools: Rust Game Debugging UI

    3 projects | dev.to | 2 May 2024
  • Egui 0.27 – easy-to-use immediate mode GUI for Rust

    3 projects | news.ycombinator.com | 27 Mar 2024
  • Rust for Embedded Systems: Current State, Challenges and Open Problems

    4 projects | news.ycombinator.com | 4 Mar 2024