hachyderm.io is one of the many independent Mastodon servers you can use to participate in the fediverse.
Hachyderm is a safe space, LGBTQIA+ and BLM, primarily comprised of tech industry professionals world wide. Note that many non-user account types have restrictions - please see our About page.

Administered by:

Server stats:

10K
active users

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

creativecommons.orgDeed - Attribution-NonCommercial-ShareAlike 4.0 International - Creative Commons

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.

I think you’re wrong. But this is clearly an article of faith amongst rust developers

What I said isn’t even what I’d consider subjective. There is a very clear, logical, scientific reason for that. Not sure what you think I’m wrong about.

I’ve worked in game dev so I get the point about iteration. It’s not about doing proper reactors - it’s about quick hacks to try something out. When your hack is good, then you do it properly - or maybe not at all if the hack works.

The respondents here are acting like code must be at all times provably correct and and Rust is great because it helps with that. That is indeed very cool but it’s SLOW when you need quick iteration. It’s not that you need to quickly iterate the code per so, it’s usually the game experience you’re iterating and that doesn’t actually NEED code to be perfect or even good.

@kaffiene @asdfasdfasdf It`s slow when you don`t know what youŕe doing. For example, build a linked list in #rustlang is different then build one in java, because you can´t leave the variables in a wrong state. It's only a different approach, not a slow approach.

OK. I’m dumb. There are dozens of languages where I appear to not be dumb using so I’ll stick to them I guess

That’s a sad attitude to have. Rust is really great, but it does have a learning curve. If you do want to give it a shot, just reach out online and there are many people who can help with suggestions.

Yeah it’s sad that I just want to get stuff done and use the tools that are actually good at that. Point me to great Rust gamedev tools that are actually getting used to ship great games and I’ll give them a go. I think criticising people who raise valid issues about Rust in a context where it has no cut through and no depth says more about you, frankly. Programming languages aren’t all good at everything and that’s not a personal slight on you or the Rust communiry

@kaffiene @asdfasdfasdf i think part of the issue is that one group of devs is saying "rust is great for gamedev" by which they mean its a great language to develop games which are closer to game engines themselves in, or even custom engines. Then another group says "no it sucks" but they are talking about the scripting approach, where you don't care what happens under the hood

Rust fits the first group well, and the second not at all, and the issue is that both dont see the difference between

Yeah, at this point I’m talking about Rust’s fit as a general purpose language and being good at refactoring. I think Rust is great for both of those and that it isn’t very subjective.

But regarding Rust for game dev, I have no idea. I have never done game dev, so it’s definitely possible it isn’t good for it for some reason.

I’m also saying scripting languages will break very easily when you refactor things. I didn’t think that was that controversial…

laund [moved]

@asdfasdfasdf i'm talking about gamedev sepcifically. there just hasnt been enough time for there to be a Unreal, Unity or Godot built for Rust as the main language. i don't think its clear beforehand that in that context it wont work, but you'd also have to solve the no stable ABI issue first.

Game engines need many years of time to develop to a point of what gamedevs coming from one of the big ones will expect, and there just hasnt been enough time yet to put in that effort.