7 ms·

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, replace

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.

the_mitsuhiko 1y ago
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.
- littlestymaar 1y ago
  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.
  - pclmulqdq 1y ago
    Everything in every ECS system is done with handles, but the parent comment is correct that many games use hairballs of pointers all over the place (and they are handles with ECS). There is never a borrow checker issue with handles since they divorce the concept of a pointer from the concept of ownership.
    - int_19h 1y ago
      But then the question becomes - why Rust, if you deliberately work around its single most prominent distinguishing feature?
      - littlestymaar 1y ago
        The main feature of rust isn't borrow checking, the feature is safe low level programming. Borrow checking is Rust's default way of doing this, but it's not the only one (the standard library has Reference Counting primitives built in). Borrow checking is a way to make manual memory management safe, ECS works around manual memory management entirely, so it doesn't need borrow checking to be safe (which is also why it's popular in C++, which doesn't have a borrow checker) but because it's Rust, you have strong guarantees about the safety of it, while in C++ you can still shoot yourself in the foot if you don't use ECS the right way. Also Rust is more than safety: https://steveklabnik.com/writing/rust-is-more-than-safety https://steveklabnik.com/writing/rust-is-more-than-safety
        int_19h 1y ago
        I would argue that borrow checking is the only feature that is actually unique (more or less) to Rust. If you don't need it, you can get the rest from elsewhere, often with better ergonomics.
        littlestymaar 1y ago
        If you don't care about performance, then sure. If you want to squeeze the maximum performance of your hardware (which is indeed the case for game engines) then all your options are Rust, C and C++. In which case is by far the more ergonomic choice on every aspects.
        int_19h 1y ago
        Or Zig. Or (if you want a stable, proven solution) Ada.
        littlestymaar 1y ago
        Neither is more ergonomic than Rust though. You could add a lot of research/experimental and/or legacy languages as well (Modula 3, Odin, D, why not FORTRAN, even) but none of them are credible alternatives to C or C++ like Rust has managed to become. And none of them are polished enough (be it in terms of errors messages, libraries, docs, onboarding material, build toolchain) to be considered superior to Rust in terms of developer ergonomics even if you set aside safety. And again, borrow checking isn't a feature, it's an implementation of the feature which is memory safety without performance tradeoff. Even when using a paradigm that doesn't interact with the borrow checker, you're still using the feature itself (especially because all of the underlying building blocks which aren't using ECS directly are benefiting from the borrow checker's validation).
- pcwalton 1y ago
  > 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. I completely disagree, having been doing game dev in Rust for well over a year at this point. I've been extremely productive in Bevy, because of the ECS. And Unity compile times are pretty much just as bad (it's true, if you actually measure how long that dreaded "Reloading Domain" screen takes).
  - hollerith 1y ago
    "ECS" == Entity-Component-System, "a software architectural pattern commonly used in game development and other simulations for organizing game objects and their data," according to Google Gemini.
Ygg2 1y ago
> The problem with Rust is that almost everything is still at an alpha stage. Replace Rust with Bevy and language with framework, you might have a point. Bevy is still in alpha, it's lacking plenty of things, mainly UI and an easy way to have mods. As for almost everything is at an alpha stage, yeah. Welcome to OSS + SemVer. Moving to 1.x makes a critical statement. It's ready for wider use, and now we take backwards compatibility seriously. But hurray! Commercial interest won again, and now you have to change engines again, once the Unity Overlords decide to go full Shittification on your poorly paying ass.
- pclmulqdq 1y ago
  Unfortunately, it is a failing of many projects in the Rust sphere that they spend quite a lot longer in 0.x than other projects. Rust language and library features themselves often spend years in nightly before making it to a release build. You can also always go from 1.0 to 2.0 if you want to make breaking changes.
  - Ygg2 1y ago
    > Unfortunately, it is a failing of many projects in the Rust sphere that they spend quite a lot longer in 0.x than other projects Yes. Because it makes a promise about backwards compatibility. > Rust language and library features themselves often spend years in nightly before making it to a release build. So did Java's. And I Rust probably has a fraction of its budget. In defense of long nightly feature more than once, stabilizing some feature like negative impl and never types early would have caused huge backwards breaking changes. > You can also always go from 1.0 to 2.0 if you want to make breaking changes. Yeah, just like Python! And split the community and double your maintenance burden. Or just pretend 2.0 is 1.1 and have the downstream enjoy the pain of migration.
    - bigstrat2003 1y ago
      > And split the community and double your maintenance burden. If you choose to support 1.0 sure. But you don't have to. Overall I find that the Rust community is way too leery of going to 1.0. It doesn't have to be as big a burden as they make it out to be, that is something that comes down to how you handle it.
justmarc 1y ago
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 almost always a work in progress and almost never perfect, and done. It's something you live with. Try any of this in C or C++.
- pjmlp 1y ago
  They might be unsafe, but there is enough tooling to pick from 60 and 50 years of industrial use, approximately.
  - littlestymaar 1y ago
    Well, on the flip side with C++ some of it hasn't been updated beyond very basic maintenance and you can't even understand the code if you are just familiar with more modern C++…
    - pjmlp 1y ago
      Well it is upon each one to be good with their craft. If not, the language they pick doesn't really make a difference in the end. It is like complaining playing a music instrument to be in band or orchestra requires too much effort, naturally.
      - littlestymaar 1y ago
        Except here you are a trained pianist and the tour manager gave you a pipe organ or a harpsichord.
        pjmlp 1y ago
        Speaking as someone with musical background, that is where we discover those that actually understand music, from those that kind of get by. Great musicians make a symphony out of what they can get their hands on.
BuyMyBitcoins 1y ago
>”reverting to more conservative options” From what I’ve heard about the Rust community, you may have made an unintentionally witty pun.
littlestymaar 1y ago
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.
rcxdude 1y ago
I wouldn't say 'almost everything', but there are some areas which require a huge amount of time and effort to build a mature solution for, UI and game engines being one, where there are still big gaps.

the_mitsuhiko 1y ago

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.

littlestymaar 1y ago
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.
- pclmulqdq 1y ago
  Everything in every ECS system is done with handles, but the parent comment is correct that many games use hairballs of pointers all over the place (and they are handles with ECS). There is never a borrow checker issue with handles since they divorce the concept of a pointer from the concept of ownership.
  - int_19h 1y ago
    But then the question becomes - why Rust, if you deliberately work around its single most prominent distinguishing feature?
    - littlestymaar 1y ago
      The main feature of rust isn't borrow checking, the feature is safe low level programming. Borrow checking is Rust's default way of doing this, but it's not the only one (the standard library has Reference Counting primitives built in). Borrow checking is a way to make manual memory management safe, ECS works around manual memory management entirely, so it doesn't need borrow checking to be safe (which is also why it's popular in C++, which doesn't have a borrow checker) but because it's Rust, you have strong guarantees about the safety of it, while in C++ you can still shoot yourself in the foot if you don't use ECS the right way. Also Rust is more than safety: https://steveklabnik.com/writing/rust-is-more-than-safety https://steveklabnik.com/writing/rust-is-more-than-safety
      - int_19h 1y ago
        I would argue that borrow checking is the only feature that is actually unique (more or less) to Rust. If you don't need it, you can get the rest from elsewhere, often with better ergonomics.
        littlestymaar 1y ago
        If you don't care about performance, then sure. If you want to squeeze the maximum performance of your hardware (which is indeed the case for game engines) then all your options are Rust, C and C++. In which case is by far the more ergonomic choice on every aspects.
        int_19h 1y ago
        Or Zig. Or (if you want a stable, proven solution) Ada.
        littlestymaar 1y ago
        Neither is more ergonomic than Rust though. You could add a lot of research/experimental and/or legacy languages as well (Modula 3, Odin, D, why not FORTRAN, even) but none of them are credible alternatives to C or C++ like Rust has managed to become. And none of them are polished enough (be it in terms of errors messages, libraries, docs, onboarding material, build toolchain) to be considered superior to Rust in terms of developer ergonomics even if you set aside safety. And again, borrow checking isn't a feature, it's an implementation of the feature which is memory safety without performance tradeoff. Even when using a paradigm that doesn't interact with the borrow checker, you're still using the feature itself (especially because all of the underlying building blocks which aren't using ECS directly are benefiting from the borrow checker's validation).
pcwalton 1y ago
> 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. I completely disagree, having been doing game dev in Rust for well over a year at this point. I've been extremely productive in Bevy, because of the ECS. And Unity compile times are pretty much just as bad (it's true, if you actually measure how long that dreaded "Reloading Domain" screen takes).
- hollerith 1y ago
  "ECS" == Entity-Component-System, "a software architectural pattern commonly used in game development and other simulations for organizing game objects and their data," according to Google Gemini.

Ygg2 1y ago

> The problem with Rust is that almost everything is still at an alpha stage. Replace Rust with Bevy and language with framework, you might have a point. Bevy is still in alpha, it's lacking plenty of things, mainly UI and an easy way to have mods. As for almost everything is at an alpha stage, yeah. Welcome to OSS + SemVer. Moving to 1.x makes a critical statement. It's ready for wider use, and now we take backwards compatibility seriously. But hurray! Commercial interest won again, and now you have to change engines again, once the Unity Overlords decide to go full Shittification on your poorly paying ass.

pclmulqdq 1y ago
Unfortunately, it is a failing of many projects in the Rust sphere that they spend quite a lot longer in 0.x than other projects. Rust language and library features themselves often spend years in nightly before making it to a release build. You can also always go from 1.0 to 2.0 if you want to make breaking changes.
- Ygg2 1y ago
  > Unfortunately, it is a failing of many projects in the Rust sphere that they spend quite a lot longer in 0.x than other projects Yes. Because it makes a promise about backwards compatibility. > Rust language and library features themselves often spend years in nightly before making it to a release build. So did Java's. And I Rust probably has a fraction of its budget. In defense of long nightly feature more than once, stabilizing some feature like negative impl and never types early would have caused huge backwards breaking changes. > You can also always go from 1.0 to 2.0 if you want to make breaking changes. Yeah, just like Python! And split the community and double your maintenance burden. Or just pretend 2.0 is 1.1 and have the downstream enjoy the pain of migration.
  - bigstrat2003 1y ago
    > And split the community and double your maintenance burden. If you choose to support 1.0 sure. But you don't have to. Overall I find that the Rust community is way too leery of going to 1.0. It doesn't have to be as big a burden as they make it out to be, that is something that comes down to how you handle it.

justmarc 1y ago

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 almost always a work in progress and almost never perfect, and done. It's something you live with. Try any of this in C or C++.

pjmlp 1y ago
They might be unsafe, but there is enough tooling to pick from 60 and 50 years of industrial use, approximately.
- littlestymaar 1y ago
  Well, on the flip side with C++ some of it hasn't been updated beyond very basic maintenance and you can't even understand the code if you are just familiar with more modern C++…
  - pjmlp 1y ago
    Well it is upon each one to be good with their craft. If not, the language they pick doesn't really make a difference in the end. It is like complaining playing a music instrument to be in band or orchestra requires too much effort, naturally.
    - littlestymaar 1y ago
      Except here you are a trained pianist and the tour manager gave you a pipe organ or a harpsichord.
      - pjmlp 1y ago
        Speaking as someone with musical background, that is where we discover those that actually understand music, from those that kind of get by. Great musicians make a symphony out of what they can get their hands on.

BuyMyBitcoins 1y ago

>”reverting to more conservative options” From what I’ve heard about the Rust community, you may have made an unintentionally witty pun.

littlestymaar 1y ago

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.

rcxdude 1y ago

I wouldn't say 'almost everything', but there are some areas which require a huge amount of time and effort to build a mature solution for, UI and game engines being one, where there are still big gaps.