Comfy, the 2D rust game engine, is now archived

Rust’s development experience

• Several commenters distinguish between:
  • Runtime: generally “as fast as C/C++”.
  • Build times: slower, but not the main complaint.
  • Development time: strongly disputed.
• Critics say non‑trivial Rust projects are slower to develop due to the borrow checker and ownership model, especially without prior Rust experience.
• Supporters argue overall dev time can be lower because many bugs are caught at compile time; they claim less time spent on debugging “language-design bugs.”
• Others counter that this only pays off when debugging time would otherwise dominate, and that wrestling with the compiler is itself costly.
• There is debate about how hard the borrow checker really is; some say “improve your programming style,” others point to seasoned Rust users struggling for years on certain designs.

Rust and game development

• Core complaint from the archived engine: Rust makes rapid, “quick and dirty” iteration painful, which is critical in game design where fun must be discovered experimentally.
• Rust “doesn’t do quick and dirty”: even throwaway prototypes must satisfy strict safety rules unless one leans on unsafe/unwrap or a separate scripting layer.
• Some report good experiences with Rust game engines (e.g., ECS patterns, Bevy) and say prototyping is fine if you accept rough code and/or scripting.
• Others assert game code prioritizes iteration speed over long‑term correctness; C++ is seen as more permissive for fast experimentation, despite safety risks.

Ecosystem stability & dependencies

• Major frustration: frequent breaking changes in key Rust gamedev libraries (egui, winit, wgpu). Maintaining an engine atop these moving targets was described as a time sink.
• Comparisons: SDL is cited as changing APIs roughly once a decade and maintaining compatibility layers; Rust crates often stay <1.0 with many breaking releases.
• Some argue this is expected for 0.x semver and that projects can pin versions and ignore updates unless needed.
• Others note dependency graphs and transitive version mismatches can still cause pain, especially with many small crates.
• Vendoring dependencies (and using Bazel/Buck) is proposed as a way to regain control and stability, at the cost of more manual management.

Tooling, hot reloading, and scripting

• Commenters emphasize that high‑performance engines (C++, Rust, C#) are typically paired with scripting (Lua, Python, etc.) for gameplay iteration.
• There is disagreement over how mature Rust’s hot‑reloading and scripting support is; examples exist but are described as “new,” “experimental,” and sometimes “wildly unsafe.”
• Some argue C++ has more battle‑tested hot‑reload tooling; others note certain external tools can work at the binary/debug-info level with Rust as well.

Language choices & alternatives

• The engine author reportedly moved to C++ and OpenGL; some find this odd given C++’s complexity, but others say C++’s flexibility suits rapid, messy game prototyping.
• OpenGL as a target is debated:
  • One side calls it deprecated and a questionable choice for new projects.
  • Others respond it’s a stable, simple API, still widely usable directly or via compatibility layers; “deprecated” status from Khronos is contested.
• Some suggest C# (with GC and mature tooling) if one is already open to managed languages.
• Alternatives like Odin and traditional engines (Unity, Unreal, Godot) are mentioned as more pragmatic for small teams than writing custom Rust/C++ engines.

Community dynamics and sentiment

• Multiple commenters note strong Rust evangelism and “rewrite it in Rust” culture; this reportedly provokes backlash and “anti‑Rust” sentiment.
• There is disagreement over whether an organized “anti‑Rust movement” exists; most call that idea conspiracy‑like, attributing criticism to normal pushback against hype.
• Some see Rust as gradually becoming a “standard systems language”; others strongly dispute any notion of a single “standard language.”

Contrasting personal experiences

• One developer reports excellent results using Rust for a high‑performance daemon: stable libraries, no serious breakage over a year, responsive maintainers, and robust behavior in production—while still disliking the syntax and finding async/Tokio confusing.
• Others relay the opposite: returning to hobby Rust projects after a month often meant fixing broken dependencies or compiler requirements, leading them to abandon Rust for such work.