| I would disagree with this. Some points: - UI frameworks and Game Engine tends to be huge when completed to a point where they are an easy choice for anything beyond some fun projects. The _huge_ majority of them have organizations/money backing in some form, through sometimes implicit. So the huge majority of open source versions of them no matter which language they are in will never be competitive. - the state of established UI frameworks is kinda a mess, the divergence between the research world and what is practically used is in most places quite often humongous (e.g. what the blog post describes is conceptually a version of using continuations for GUI libraries and state handling in them, something well established as "a grate idea, if you can make it work nicely with the limitation of widely used programming languages" in computer since since I think 10+ years or so), and it's pretty common that patterns people are used to (e.g. inheritance for code reuse) are actually anti-patterns which kinda somewhat happens to be usable in that case but have serious issues you IMHO often don't notice until using them in larger projects (as in many people working on the software in parallel) where it's then often blamed on other things - due the the mess the state handling in GUIs often ends up in it tends to profit from using a GC and the using borrows only in rust will likely fail. But then given the perf-characteristics and what tends to be a hot paths of GUIs _you really don't need to write borrows only code_, using an Rc/Arc and similar tends to be perfectly fine, i.e. the issue is in my experience more people obsessing over micro optimizations for that context - on the other hand for game engine you often want to avoid GC for the engine/core parts themself (i.e. not dialog script and similar) and in general have a much stricter state handling using stuff like a ECS, there is no reason for rust to not handle that well. Through writing the ECS library might involve usafe code, due to it involving writing fundamental data structures. Most importantly in recent years "memory safety" of C++ has become an increasingly bigger issues for AAA-games, especially for multiplayer games where there is a risk of a hacking the users computer through the game client, and the money spend on combating that issue is non trivial to a point that you probably should avoid most code which conceptually works in C++ but couldn't work in rust due to the borrow checker (assuming you already have a well done ECS library with the right soundly implemented data structures). - similar to writing fundamental data structures, writing a game engine proper is really really hard but seems simple as long as it's only a "toy", rust isn't good at that, sure. But also there is limited value at being good at writing throw away toys which can't be used in any production context IMHO. What does matter is if you can have a nicely usable production ready _maintainable_ game engine in rust, and AFIK yes you can somewhat already have. |