I respectfully disagree with the author's title choice.
My first impression is, of course, that the issue is there is no production Game or GUI framework around.
The author seems to complain mainly about the choices of frameworks and how bad or opinionated they are. I agree. Even Egui is too opinionated, but it makes sense on some level.
It is no problem to use bindings to some software written in C++. Rust was created to solve this exact problem: rewrite big projects that were written in C++, by slow mutation in Rust.
Honestly, I would add further that until the Unreal Engine uses Rust, we should not expect widespread Rust adoption. It will likely start with a company creating its own really custom game engine, the game becoming a bestseller, and it will spread iteratively over the years from there.
Or maybe there will be a better option beyond Rust at that point.
Beyond that: One should see Rust as writing C with someone watching over you to remind you that you need to know the writer for each memory value. It picks up work off you. Or it should. If it doesn't, yes that is a problem, and we/you are doing it wrong.
But yes, if you are doing something that the borrow checker complains about, in other languages, either that semantic difference would have been hidden, or you would be paying for it later.
There, the author makes a point that he wants the code to work now. That is possible, and you can hotwire bad code in Rust, too. But I am sure that code is why we end up with games like Jedi Survivor.
There is no fundamental inability of Rust to do the things the author demands.
If you want dynamic loading, use https://crates.io/crates/libloading (And you don't need to use the library).
Do you want a global state? I will disagree with you, but take a look at, e.g., how the Dioxus project is doing it. Again I think that is always a terrible mistake, and people are thinking really of using an arena or a registry really.
My first impression is, of course, that the issue is there is no production Game or GUI framework around.
The author seems to complain mainly about the choices of frameworks and how bad or opinionated they are. I agree. Even Egui is too opinionated, but it makes sense on some level.
It is no problem to use bindings to some software written in C++. Rust was created to solve this exact problem: rewrite big projects that were written in C++, by slow mutation in Rust.
Honestly, I would add further that until the Unreal Engine uses Rust, we should not expect widespread Rust adoption. It will likely start with a company creating its own really custom game engine, the game becoming a bestseller, and it will spread iteratively over the years from there. Or maybe there will be a better option beyond Rust at that point.
This is the status quo: https://www.youtube.com/shorts/_zwKHgtQpc8 Let us be realistic.
Beyond that: One should see Rust as writing C with someone watching over you to remind you that you need to know the writer for each memory value. It picks up work off you. Or it should. If it doesn't, yes that is a problem, and we/you are doing it wrong.
But yes, if you are doing something that the borrow checker complains about, in other languages, either that semantic difference would have been hidden, or you would be paying for it later.
There, the author makes a point that he wants the code to work now. That is possible, and you can hotwire bad code in Rust, too. But I am sure that code is why we end up with games like Jedi Survivor.
There is no fundamental inability of Rust to do the things the author demands. If you want dynamic loading, use https://crates.io/crates/libloading (And you don't need to use the library). Do you want a global state? I will disagree with you, but take a look at, e.g., how the Dioxus project is doing it. Again I think that is always a terrible mistake, and people are thinking really of using an arena or a registry really.