4 ms·

The entire Rust ecosystem for gamedev is kind of like that - it was only recently that people really started writing games entirely in Rust, and even now there

The entire Rust ecosystem for gamedev is kind of like that - it was only recently that people really started writing games entirely in Rust, and even now there are very few actual released commercial games out there. I think there's a bit of a loop happening where it's like, until Rust is considered "stable" for serious gamedev work, libraries will be developed in this kind of "unstable" way where breaking changes should be expected at any time, but at the same time, that instability is making it less of a serious contender for gamedev work.

thrdbndndn 2y ago
Forget about gamedev. An anecdote: a friend wrote a personal Rust project which purely works with website's APIs and some minor file operations (basically a scraper). And I, as his only user, have to constantly update my local Rust installation to newest dev to be able to compile his newest code base. I understand it's more about him being on edge than the language itself alone -- but it still feels insane for me. In most of other languages, you can't make your code so backwards incompatible even if you actively try.
- orphea 2y ago
  It's not more, it's 100% on your friend, I'm afraid. One is not supposed to jump to the newest version every time simply because one can. Updating the minimum supported Rust version is a breaking change that should not be done lightly.
  - steveklabnik 2y ago
    > Updating the minimum supported Rust version is a breaking change This is not the majority sentiment, for better or for worse. The project stopped releasing "what version of Rust do you use most" in the survey results in 2020 (which is a shame, imho) the vast, vast majority of folks use the latest stable, and very few use a previous version of stable. I have no real reason to believe this overall trend has changed since then. This is especially true for an application, which this project seems to be. Libraries may have more of a reason to explicitly lag behind the latest, but there's not really a good reason to bother if nobody else is going to depend on your code.
    - prophesi 2y ago
      That makes sense to me. I usually use asdf to version Rust in personal projects, so I'm not always on the latest. But when I work on a new release I'll almost always update rust and any of my other dependencies, as I'd otherwise never keep them up-to-date. Or if a new language feature I want to try just came out. And God forbid you fall behind on React Native major releases in a project. I think the Expo project's solution to this is for all of the native configuration be done via plugins and cross-platform config[0]. Otherwise you'll be dealing with large diffs of native Android/iOS code that would have even native mobile devs tread carefully. [0] https://docs.expo.dev/workflow/prebuild/#sensible-upgrades https://docs.expo.dev/workflow/prebuild/#sensible-upgrades
  - vilunov 2y ago
    > Updating the minimum supported Rust version is a breaking change that should not be done lightly. Why? As I see, requiring a higher minor version of your dependency including the compiler is not a breaking change (and does not warrant a major version bump wrt semver), as there should be no problem in bumping the minor version of any dependency, even if it's used for different packages.
  - noirscape 2y ago
    > Updating the minimum supported Rust version is a breaking change that should not be done lightly. Someone should tell that to Rust library devs, because from what I understand, their packaging ecosystem pretty much always assumes that all libraries are running on the latest version of Rust. There's no "commonly used versions" or LTS builds for Rust, so it seems that every packaging maintainer just supports the latest and everyone is up shitcreek if a new version changes and hard breaks code for older Rust. With how micropackage oriented Rust is, you practically can only jump to the newest version if you want your builds to keep working since I doubt you'll be using stdlib-only Rust. Compare and contrast every (anecdotal) Rust users favorite bugbear, Python, where if you're building a library, it's pretty commonly assumed that you can follow one of the two major deprecation points for Python versions (end of bugfixes or end of security updates), which means most major libraries usually follow one of the two for the internal features (and therefore lowest version) they use.
    - ffsm8 2y ago
      I've only done a few hello world style projects in rust, and my python experience is also almost 8 yrs ago now, so I might be wrong... But doesn't rust pull it's dependencies as bytecode vs python (which is a script language at its core) that pulls the source code? The bytecode would only ever work with the VM that it's been compiled against I think, which sounds to me like the real issue here...? I don't think you'd have this issue if you'd fetch your rust dependencies via git and then build them locally. And pre building for every version is expensive, which is likely why the rust ecosystem doesn't really do it right now. And I doubt it's gonna change unless a MAMA (Microsoft, Apple, Meta, Alphabet) company "embraces" it... The EEE style
      - steveklabnik 2y ago
        Crates.io stores packages as source code. Rust does not have a VM, and doesn't use bytecode. That being said, it could in theory serve them as binary code, which yes, would then mean that it would need to be stored per version and per architecture both, which would be quite a lot more than the source that's stored now.
    - 2y ago
- ratmice 2y ago
  It is also about how easy rust makes it to use libraries, and depend upon external libraries as a part of your public API. C in particular makes this pretty inconvenient, so a lot of projects include data structures and things that otherwise might be pulled in via library themselves. That lends itself towards less reliance on external deps but also more internal stability. At the very least I can say, that experiences I've had that are common in rust, where I have dependency X needing to be upgraded in lockstep (the same version) across multiple external dependencies with different maintainers. Are things that I've basically never experienced with C based languages. At least I don't think it is just that things need time to stabilize, but also just the packaging system causes network effects which you don't get the joy of experiencing if you don't have one.
  - cmrdporcupine 2y ago
    This is the right answer. Crates.io comes with a whole mixed bag of experiences. Increases initial project development velocity at the expense of long-term velocity (and sanity). After 2.5 years of doing Rust full-time it's the one thing I'd look back and say I'd rather see done entirely different.
    - throwaway17_17 2y ago
      What do you think some of the alternatives for library distribution and management are that would be more successful. I am an unabashed proponent of the C style manage t dependencies yourself in a manner consistent for your own work, but many people are 100% adverse to that position. Do you think a middle ground would be possible?
      - Ygg2 2y ago
        Then vendor your dependencies in Rust. If you don't want libraries to change and the depenency maintainer won't commit to stable API, you have to vendor it.
        marvin-hansen 2y ago
- satvikpendem 2y ago
  I don't understand, it's recommended practice to update your Rust install to the latest whenever there's a new version, because Rust itself is wholly backwards compatible, so 1.0 code should continue to compile with whatever the latest version is. Are you saying the libraries he's using are deprecating functionality instead of the core language? If so, then yeah I've had that issue too with certain libraries like clap.
  - nrabulinski 2y ago
    No, he’s saying his friend sees a new, shiny, just stabilized function in the standard library and first thing they do is jump to using it
    - satvikpendem 2y ago
      I mean, so what? I think in actuality what they're implying is that one shouldn't update Rust to latest, even though that's the recommendation. So it shouldn't matter what the friend does, as long as they're always on latest Rust. In fact, the friend is in the right, in this scenario.
      - hu3 2y ago
        > I mean, so what? That mindset leads to the start of this thread: > It might not be obvious how much effort it takes to manage bugfixes in dependencies where every few weeks there's a new breaking API change in egui/winit/wgpu, and while these probably seem extremely minor to those who spend all their time building an engine on top of said libraries, sinking a day or two in figuring things out and fixing stuff on every release is a gigantic waste of time in my view.
        satvikpendem 2y ago
        But not really, because the person we are talking about is, if I understand correctly, a user of the software their friend wrote, not someone who is implementing any features themselves and thus needs to rely on a stable API. All they need to do is to update their Rust version, which is really the same as any other software that must update over time. This same sentiment is also echoed by Steve Klabnik here [0], it seems. [0] https://news.ycombinator.com/item?id=41488337 https://news.ycombinator.com/item?id=41488337
- jeroenhd 2y ago
  There's nothing preventing you from using the defined-by-spec-but-not-actually implemented C++23 methods, either. You can write perfectly spec-compliant C++ code that will only work on the latest version of MS C++ because other compilers don't support the feature yet. Shortly after new C++ specs are released, it's even possible to write spec-compliant code that no production compiler can even compile! It's just that developers in the slow languages don't do that often. With the guarantee to be able to build older projects (version specified in the Cargo.toml file) and only one real mainstream compiler (the "can compile code but lacks any of the language checks" GCC version doesn't really count), there are few downsides to always having the latest compiler, something other languages sometimes struggle with. Coming from Rust, I made the foolish mistake of installing the latest Clang and GCC, only to find out that tons of software suddenly stopped compiling because apparently the code requires old compiler bugs/features to work (that are not emulated in newer versions). I've had similar issues with Java, where JRE 17 or 21 could not compile Java 8 projects without modifications to the project because of the new modules feature. In an environment where updating your compiler toolkit is basically worry-free, it's a lot easier to use recent or even unstable functions. This invites developers to make use of recently added APIs, whereas developers from other ecosystems will wait months or years before even considering new APIs that have been stabilised.

thrdbndndn 2y ago

Forget about gamedev. An anecdote: a friend wrote a personal Rust project which purely works with website's APIs and some minor file operations (basically a scraper). And I, as his only user, have to constantly update my local Rust installation to newest dev to be able to compile his newest code base. I understand it's more about him being on edge than the language itself alone -- but it still feels insane for me. In most of other languages, you can't make your code so backwards incompatible even if you actively try.

orphea 2y ago
It's not more, it's 100% on your friend, I'm afraid. One is not supposed to jump to the newest version every time simply because one can. Updating the minimum supported Rust version is a breaking change that should not be done lightly.
- steveklabnik 2y ago
  > Updating the minimum supported Rust version is a breaking change This is not the majority sentiment, for better or for worse. The project stopped releasing "what version of Rust do you use most" in the survey results in 2020 (which is a shame, imho) the vast, vast majority of folks use the latest stable, and very few use a previous version of stable. I have no real reason to believe this overall trend has changed since then. This is especially true for an application, which this project seems to be. Libraries may have more of a reason to explicitly lag behind the latest, but there's not really a good reason to bother if nobody else is going to depend on your code.
  - prophesi 2y ago
    That makes sense to me. I usually use asdf to version Rust in personal projects, so I'm not always on the latest. But when I work on a new release I'll almost always update rust and any of my other dependencies, as I'd otherwise never keep them up-to-date. Or if a new language feature I want to try just came out. And God forbid you fall behind on React Native major releases in a project. I think the Expo project's solution to this is for all of the native configuration be done via plugins and cross-platform config[0]. Otherwise you'll be dealing with large diffs of native Android/iOS code that would have even native mobile devs tread carefully. [0] https://docs.expo.dev/workflow/prebuild/#sensible-upgrades https://docs.expo.dev/workflow/prebuild/#sensible-upgrades
- vilunov 2y ago
  > Updating the minimum supported Rust version is a breaking change that should not be done lightly. Why? As I see, requiring a higher minor version of your dependency including the compiler is not a breaking change (and does not warrant a major version bump wrt semver), as there should be no problem in bumping the minor version of any dependency, even if it's used for different packages.
- noirscape 2y ago
  > Updating the minimum supported Rust version is a breaking change that should not be done lightly. Someone should tell that to Rust library devs, because from what I understand, their packaging ecosystem pretty much always assumes that all libraries are running on the latest version of Rust. There's no "commonly used versions" or LTS builds for Rust, so it seems that every packaging maintainer just supports the latest and everyone is up shitcreek if a new version changes and hard breaks code for older Rust. With how micropackage oriented Rust is, you practically can only jump to the newest version if you want your builds to keep working since I doubt you'll be using stdlib-only Rust. Compare and contrast every (anecdotal) Rust users favorite bugbear, Python, where if you're building a library, it's pretty commonly assumed that you can follow one of the two major deprecation points for Python versions (end of bugfixes or end of security updates), which means most major libraries usually follow one of the two for the internal features (and therefore lowest version) they use.
  - ffsm8 2y ago
    I've only done a few hello world style projects in rust, and my python experience is also almost 8 yrs ago now, so I might be wrong... But doesn't rust pull it's dependencies as bytecode vs python (which is a script language at its core) that pulls the source code? The bytecode would only ever work with the VM that it's been compiled against I think, which sounds to me like the real issue here...? I don't think you'd have this issue if you'd fetch your rust dependencies via git and then build them locally. And pre building for every version is expensive, which is likely why the rust ecosystem doesn't really do it right now. And I doubt it's gonna change unless a MAMA (Microsoft, Apple, Meta, Alphabet) company "embraces" it... The EEE style
    - steveklabnik 2y ago
      Crates.io stores packages as source code. Rust does not have a VM, and doesn't use bytecode. That being said, it could in theory serve them as binary code, which yes, would then mean that it would need to be stored per version and per architecture both, which would be quite a lot more than the source that's stored now.
  - 2y ago
ratmice 2y ago
It is also about how easy rust makes it to use libraries, and depend upon external libraries as a part of your public API. C in particular makes this pretty inconvenient, so a lot of projects include data structures and things that otherwise might be pulled in via library themselves. That lends itself towards less reliance on external deps but also more internal stability. At the very least I can say, that experiences I've had that are common in rust, where I have dependency X needing to be upgraded in lockstep (the same version) across multiple external dependencies with different maintainers. Are things that I've basically never experienced with C based languages. At least I don't think it is just that things need time to stabilize, but also just the packaging system causes network effects which you don't get the joy of experiencing if you don't have one.
- cmrdporcupine 2y ago
  This is the right answer. Crates.io comes with a whole mixed bag of experiences. Increases initial project development velocity at the expense of long-term velocity (and sanity). After 2.5 years of doing Rust full-time it's the one thing I'd look back and say I'd rather see done entirely different.
  - throwaway17_17 2y ago
    What do you think some of the alternatives for library distribution and management are that would be more successful. I am an unabashed proponent of the C style manage t dependencies yourself in a manner consistent for your own work, but many people are 100% adverse to that position. Do you think a middle ground would be possible?
    - Ygg2 2y ago
      Then vendor your dependencies in Rust. If you don't want libraries to change and the depenency maintainer won't commit to stable API, you have to vendor it.
      - marvin-hansen 2y ago
satvikpendem 2y ago
I don't understand, it's recommended practice to update your Rust install to the latest whenever there's a new version, because Rust itself is wholly backwards compatible, so 1.0 code should continue to compile with whatever the latest version is. Are you saying the libraries he's using are deprecating functionality instead of the core language? If so, then yeah I've had that issue too with certain libraries like clap.
- nrabulinski 2y ago
  No, he’s saying his friend sees a new, shiny, just stabilized function in the standard library and first thing they do is jump to using it
  - satvikpendem 2y ago
    I mean, so what? I think in actuality what they're implying is that one shouldn't update Rust to latest, even though that's the recommendation. So it shouldn't matter what the friend does, as long as they're always on latest Rust. In fact, the friend is in the right, in this scenario.
    - hu3 2y ago
      > I mean, so what? That mindset leads to the start of this thread: > It might not be obvious how much effort it takes to manage bugfixes in dependencies where every few weeks there's a new breaking API change in egui/winit/wgpu, and while these probably seem extremely minor to those who spend all their time building an engine on top of said libraries, sinking a day or two in figuring things out and fixing stuff on every release is a gigantic waste of time in my view.
      - satvikpendem 2y ago
        But not really, because the person we are talking about is, if I understand correctly, a user of the software their friend wrote, not someone who is implementing any features themselves and thus needs to rely on a stable API. All they need to do is to update their Rust version, which is really the same as any other software that must update over time. This same sentiment is also echoed by Steve Klabnik here [0], it seems. [0] https://news.ycombinator.com/item?id=41488337 https://news.ycombinator.com/item?id=41488337
jeroenhd 2y ago
There's nothing preventing you from using the defined-by-spec-but-not-actually implemented C++23 methods, either. You can write perfectly spec-compliant C++ code that will only work on the latest version of MS C++ because other compilers don't support the feature yet. Shortly after new C++ specs are released, it's even possible to write spec-compliant code that no production compiler can even compile! It's just that developers in the slow languages don't do that often. With the guarantee to be able to build older projects (version specified in the Cargo.toml file) and only one real mainstream compiler (the "can compile code but lacks any of the language checks" GCC version doesn't really count), there are few downsides to always having the latest compiler, something other languages sometimes struggle with. Coming from Rust, I made the foolish mistake of installing the latest Clang and GCC, only to find out that tons of software suddenly stopped compiling because apparently the code requires old compiler bugs/features to work (that are not emulated in newer versions). I've had similar issues with Java, where JRE 17 or 21 could not compile Java 8 projects without modifications to the project because of the new modules feature. In an environment where updating your compiler toolkit is basically worry-free, it's a lot easier to use recent or even unstable functions. This invites developers to make use of recently added APIs, whereas developers from other ecosystems will wait months or years before even considering new APIs that have been stabilised.