This was a really good summary of what Rust feels like in my opinion. I’m still a beginner myself but I recognize what this article is saying very much.
The hacker news comments are as usual very good too:
The hacker news comments are as usual very good too
lol
I’m only saying this because I’ve seen this posted on several boards , and there’s to much negative attitude towards the blogger.
I don’t understand people being defensive, it’s not like the author hates rust, as a matter of fact he loves rust and chose to write a game in it for 3 years. He’s just sharing his experience with the language, and some one might find it useful, even the language devs might appreciate feedback from the community.
How is the language going to improve, if all we do I show hostility towards those who critiques some parts of the language, it’s going to be C++ all over again, if people stop doing that because being afraid of getting community backlash. The elitist attitude isn’t helpful and has never been.
That being said, there is an overwhelming force in the Rust community that when anyone mentions they’re having problems with Rust the language on a fundamental level, the answer is “you just don’t get it yet, I promise once you get good enough things will make sense”. This is not just with Rust, if you try using ECS you’re told the same thing. If you try to use Bevy you’ll be told the same thing. If you try to make GUIs with whichever framework you choose (be it one of the reactive solutions or immediate mode), you’ll be told the same thing. The problem you’re having is only a problem because you haven’t tried hard enough.
Ugh, I hate this attitude in the Rust community. It’s the elitist neckbeard attitude the early linux forums were known for that’s still present in places like the Arch community.
The best advice I read about these places is to avoid them and just do stuff that works. Writing Haskell and don’t want to worry about whatever highbrow computer science gatekeeping concepts? Use the beautiful escape hatch to imperative programming: monads.
do { blablabla }
. Is the Rust borrow checker complaining about ownership? A quick.clone()
to a new variable will probably shut it up and allow you to move on. “Ermagerd, scripts should be in bash and only readable to you!”, a quick ruby or python script should solve that for you. “systemd is -”, just stop reading there and keep using systemd. It does the job.This is where experienced people will often say that this becomes less of an issue once you get better at the language. My take is, while that is 100% true, there’s a fundamental problem of games being complex state machines where requirements change all the time.
This is probably the best argument in the article. Rust is probably great for systems that don’t have a lot of changing requirements, but fast iteration and big changes probably aren’t its strong suit. I’ve found that planning a project ahead of time has reduced the amount of refactoring needed regardless of language, but that’s because I was solving a static problem and thinking of a little bit of flexibility towards other features. Games probably aren’t like that.
No language fits every usecase and it’s completely find for it not to fit this dude’s flow of writing games nor the types of games he’s writing. It’s a good thing he came to the conclusion sooner than later.
So… dev blames skill issues on language? Classic.
EDIT: For the record, I’m not saying the author is bad at Rust. I’m saying they’re bad at making games and balancing tradeoffs. They keep saying that they don’t like rust because they just want to worry about making a game, not fighting the language. And yet, they seem to continually make decisions that favor performance over ergonomics. Then they whine about how the Rust community is supposedly pressuring them to make bad decisions.
Ha they literally said about 5 times in this page that people often say “it’s just a skill issue”… and here you are.
I love Rust but the author’s points are 100% valid.
TLDR: “I picked a systems programming language to write and iterate on a bunch of gameplay scripting. Why does Rust not meet the needs of a gameplay scripting language like <every link in the article which either refers to dedicated game-programming scripting languages, or Unity which is whole goddamn commercial game engine>. Hmm yes, the problem must lie with Rust, not with the choices I made in my project.”
Just try to write a complete game with nothing but open source libraries in C++, or C#, or Java. Good luck with that. The author is switching to Unity for a very good reason. It turns out a commercial product made by 6000 people delivers value…
You use a systems programming language to write your engine. And then a scripting language to write your game. Everybody in gamedev knows this, I thought.