[eftychis]

This comment might not be liked by the usual commenters in these threads, but I think it is worth stressing:

First: I have experience with Bevy and other game engine frameworks; including Unreal. And I consider myself a seasoned Rust, C etc developer.

I could sympathize with what was stated by the author.

I think the issue here is (mainly) Bevy. It is just not even close to the standard yet (if ever). It is hard for any generic game engine to compete with Unity/GoDot. Nevermind, the de facto standard of Unreal.

But if you are a C# developer and using Unity already, and not C++ in Unreal, going to a bloated framework that is missing features that is Bevy makes little sense. [And here is also the minor issue, that if you are a C# developer, honestly you don't care about low level code, or not having a garbage collector.]

Now if you are a C++ developer and use Unreal, they only point to move to Rust (which I would argue for the usual reasons) is if Unreal supports Rust. Otherwise, there is nothing that even compares to Unreal. (That is not custom made game engine.)

[the__alchemist]

The way I read about Bevy in online discussions obfuscates this. Someone who is new to game development could be confused into thinking Bevy is a fair competitor with the other engines you mentioned. And equate Bevy with Rust, or Bevy with Rust in game dev. I think stomping this out is critical to expectation management, and perhaps rust's future in game dev.

[hu3]

Not only Bevy. In this very thread someone is suggesting an even less mature Rust game engine: https://news.ycombinator.com/item?id=43825564

From my experience one has to take Rust discussions with a grain of salt because often shortcomings and disclosures are handwaved and/or ommited.

[the__alchemist]

I've learned to do the same. I see this in the embedded world as well.

And within rust, I've learned to look beyond the most popular and hyped tools; they are often not the best ones.

[JeremyBarbosa]

As someone who has used Bevy in the past, that was my reading as well. It is an incredible tool, but some of the things mentioned in the article like the gnarly function signature and constant migrations are known issues that stop a lot of people from using it. That's not even to mention the strict ECS requirement if your game doesn't work well around it. Here is a good reddit thread I remember reading about some more difficulties other people had with Bevy:

https://old.reddit.com/r/rust_gamedev/comments/13wteyb/is_be...

I wonder how something simpler in the rust world like macroquad[0] would have worked out for them (superpowers from Unity's maturity aside).

[0] https://macroquad.rs/

[yyyk]

>if you are a C# developer, honestly you don't care about low level code, or not having a garbage collector.

You can go low level in C#**, just like Rust can avoid the borrow checker. It's just not a good tradeoff for most code in most games.

** value types/unsafe/pointers/stackalloc etc.

[neonsunset]

Structs in C# or F# are not low-level per se, they simply are a choice and used frequently in gamedev. So is stackalloc because using it is just 'var things = (stackalloc Thing[5])' where the type of `things` is Span<Thing>. The keyword is a bit niche but it's very normal to see it in code that cares about avoiding allocations.

Note that going more hands-on with these is not the same as violating memory safety - C# even has ref and byreflike struct lifetime analysis specifically to ensure this not an issue (https://em-tg.github.io/csborrow/).

[yyyk]

Right, it depends on how far one wants to go to avoid allocations. structs and spans are safe. But one can go even deeper and pin pointers and do Unsafe.AsPointer and get a de-facto (unsafe) union out of it....

>https://em-tg.github.io/csborrow/

Oooh... I didn't know scoped refs existed.

[int_19h]

If you want an unsafe union, that's what StructLayout.Explicit and FieldOffset is for - a struct with all fields placed at offset 0 is exactly the same as a C union.

[ecshafer]

Imo the place for rust in game dev isnt in games at all, but base libraries and tools. Writing your proc generation library in rust that is an isolated package you can call in isolation, or similar is where its useful.

[eftychis]

I agree. [Unless fully adopted by a serious game engine, of course.] Rust's "superpower" is substituting critical C++ code in-place, with the goal of ensuring correctness and soundness. And increasing the development velocity as a result.