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:

https://news.ycombinator.com/item?id=40172033

you are viewing a single comment's thread
view the rest of the comments

[–] onlinepersona@programming.dev 27 points 6 months ago (22 children)

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.

Anti Commercial-AI license

[–] asdfasdfasdf@lemmy.world 13 points 6 months ago (20 children)

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 agreed up until this. Fearless refactoring is a huge benefit of Rust. If the type system of another language allows the refactoring more easily without as many compilation failures, it will probably surface more runtime bugs.

[–] porgamrer@programming.dev 0 points 6 months ago (1 children)

I greatly fear refactoring in Rust. Making a single conceptual change can require a huge number of code changes in practice, especially if it's a change to ownership.

Refactoring in languages like Java and C# is effortless in comparison, and not error prone at all in a modern codebase.

You can use RC and clone everywhere, but now your code is unreadable, slow, and might even have memory leaks.

You can use slotmaps everywhere, but now you're embedding a different memory model with verbose syntax that doesn't even have first-class references.

I don't even dislike Rust; I recently chose it for another project. I just think it has clear weaknesses and this is one of them.

[–] arendjr@programming.dev 3 points 6 months ago

I greatly fear refactoring in Rust. Making a single conceptual change can require a huge number of code changes in practice, especially if it’s a change to ownership.

I think this is a fair criticism, but I think you and the poster you responded to are talking about different things. Usually when people use the term “fearless” in relation to Rust, it means the language provides a high level of confidence that what you’re delivering is free of mistakes. This certainly applies to refactoring too, where usually after you are done, and things compile again, you can be reasonably confident things work as before (assuming you didn’t make other changes the type system can’t catch for you).

The kind of fear you are describing sounds more like a discouragement because of the amount of work ahead of you. That’s fair, because Rust does sometimes make things harder. I just think many Rust developers will disagree with you, not because you’re wrong, but because they may not feel the same type of discouragement, possibly because they’ve learned to appreciate the rewards more.

load more comments (18 replies)

load more comments (19 replies)