Live data from Hacker News

Migrating away from Rust

deadmoney.gg

51–60 of 799 posts

Re: Migrating away from Rust

#51
post #14

The article title is half-true. It wasn't so much they migrated away from Rust, but that they migrated away from Bevy, which is an alpha quality game engine. I wouldn't have read the article if it'd been labeled that, so kudos to the blog writer, I guess.

[deleted]

Re: Migrating away from Rust

#52
post #14

The article title is half-true. It wasn't so much they migrated away from Rust, but that they migrated away from Bevy, which is an alpha quality game engine. I wouldn't have read the article if it'd been labeled that, so kudos to the blog writer, I guess.

The problem with Rust is that almost everything is still at an alpha stage. The vast majority of crates are at version 0.x and are eventually abandoned, replaced, or subject to constant breaking changes While the language itself is great and stable, the ecosystem is not, and reverting to more conservative options is often the most reasonable choice, especially for long-term projects.

It's still true for game dev indeed, but for back-end or CLI tools it hasn't been true in like 7 years or so.

Re: Migrating away from Rust

#53

It’s incredible how many projects and articles have been written around ECS with very little results. Quake 1-3 uses a single array of structs, with sometimes unused properties. Is your game more complex than quake 3? The “ECS” upgrade to that is having an array for each component type but just letting there be gaps: transform[eid].position += … physics[eid].velocity = …

[deleted]

Re: Migrating away from Rust

#55

Earlier quoted context omitted.

The problem with Rust is that almost everything is still at an alpha stage. The vast majority of crates are at version 0.x and are eventually abandoned, replaced, or subject to constant breaking changes While the language itself is great and stable, the ecosystem is not, and reverting to more conservative options is often the most reasonable choice, especially for long-term projects.

I have totally disagree here. I don't even look at crate versions but the stuff works, very well. The resulting code is stable, robust and the crates save an inordinate amount of development time. It's like lego for high end, high performance code. With Rust and the crates you can build actual, useful stuff very quickly. Hit a bug in a crate or have missing functionality? contribute. Software is something that is alm…

They might be unsafe, but there is enough tooling to pick from 60 and 50 years of industrial use, approximately.

Re: Migrating away from Rust

#56
GC isn't a big problem for many types of apps/games, and most games don't care about memory safety. Rust's advantages aren't so important in this domain, while its complexity remains. No surprise he prefers C# for this.

Re: Migrating away from Rust

#57

Earlier quoted context omitted.

The problem with Rust is that almost everything is still at an alpha stage. The vast majority of crates are at version 0.x and are eventually abandoned, replaced, or subject to constant breaking changes While the language itself is great and stable, the ecosystem is not, and reverting to more conservative options is often the most reasonable choice, especially for long-term projects.

I really don’t think Rust is a good match for game dev. Both because of the borrow checker which requires a lot of handles instead of pointers and because compile times are just not great. But outside of games the situation looks very different. “Almost everything” is just not at all accurate. There are tons of very stable and productive ecosystems in Rust.

Borrow checker is mostly a strawman for this discussion, the post is about using Bevy as an engine and Bevy uses an ECS than manages the lifetime of objects for you automatically. You will never have an issue with the borrow checker when using Bevy, not even once.

Re: Migrating away from Rust

#58

It’s incredible how many projects and articles have been written around ECS with very little results. Quake 1-3 uses a single array of structs, with sometimes unused properties. Is your game more complex than quake 3? The “ECS” upgrade to that is having an array for each component type but just letting there be gaps: transform[eid].position += … physics[eid].velocity = …

Hype as usual, too many people waste time on how to implement engines, instead of how to make a game fun to play.

Re: Migrating away from Rust

#59
post #46

Anyone else get an empty page on mobile Firefox when they try to go the article? All that renders for me is a comment entry box. If I go back to news I can see the article list just fine.

Same on mobile safari

Re: Migrating away from Rust

#60

I love Rust, but this lines up with my experience roughly. Especially the rapid iteration. Tried things out with Bevy, but I went back to Godot. There are so many QoL things which would make Rust better for gamedev without revamping the language. Just a mode to automatically coerce between numeric types would make Rust so much more ergonomic for gamedev. But that's a really hard sell (and might be harder to implement…

What numeric types typically need conversions?

The fact you need a usize specifically to index an array (and most collections) is pretty annoying.
Post reply on HN