4 ms·

> 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

by ndiddy 2y ago

> 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. That's insane. For comparison SDL does breaking API changes every ~10 years (and they implement the previous version's API as a wrapper around the current version's API to support legacy software). Maybe the egui/winit/wgpu devs just expect that every end-user will just pin their package versions for the duration of a project, but it seems like a real burden for devs of libraries like Comfy that depend on them.

desdenova 2y ago
The rust ecosystem is young, most of those libraries haven't even reached 1.0. Basing any serious project on 0.x libraries is always subject to this issue.
- littlestymaar 2y ago
  I'm always puzzled with people saying that things move too quickly and that they fail to keep up, in any language. Why do you guys even try to keep up in the first place? Unless there's a bug in a dependency you're using, if version 0.4 works, you don't have to use 0.5 or 0.6. Or maybe there's a new feature that you need in the newer version, then you can afford to spend time doing the migration but in this case you should also be happy the the pace of development is fast because that's how the feature ended up landing in the first place. For most use-cases, it's fine to stay on out of date libraries for years, and that's what the Linux distros do all the time (mostly patching crippling bugs and security vulnerabilities).
  - mysterydip 2y ago
    90% agree. The scenario that I've seen that messes with this is when you include lib x which has dependency on version 0.5 of y, but your code depends on version 0.4 of y.
    - tstenner 2y ago
      cargo handles this just fine, unless you get lib y objects through the lib x api
- aeurielesn 2y ago
  I believe a post from one or two weeks ago showed it seems more of a systematic Rust ecosystem problem.
  - CaptainOfCoit 2y ago
    What, exactly, is the problem? That libraries/projects remain below 1.0 for too long? Because lots of breaking changes before a 1.0.0 release is to be expected for anything following semver (which as far as I know, most if not all of the Rust ecosystem uses).
- q3k 2y ago
  > Basing any serious project on 0.x libraries is always subject to this issue. So I guess I'll hold off on having random numbers in Rust then [1]. [1] - https://docs.rs/rand/latest/rand/ https://docs.rs/rand/latest/rand/
  - swfsql 2y ago
    It's already at 0.8, just another 20% and..!
- mcpar-land 2y ago
  On the flip side of this, when libraries in rust do reach 1.0, they often are just done. The serialization/deserialization library serde which has become the de-facto standard has been on 1.0.xxx for the past seven years. https://crates.io/crates/serde/versions https://crates.io/crates/serde/versions I think this speaks to rust's strengths in that if you know your spec, you can write a rock-solid version of it - and its weakness, where if you don't know your spec you'll be making breaking changes a lot.
rapsey 2y ago
Things move quickly because there is so much development being put into these base libraries. Which is of course a blessing and a curse.
lewispollard 2y ago
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.
viraptor 2y ago
wgpu only got the first non-0 release this July and started 4-ish years ago. They didn't even have a chance of taking 10 years. I'm sure SDL wasn't very API stable in 1998.
- seba_dos1 2y ago
  4 years after starting SDL was already deep into 1.2, which is the API that's still supported today via sdl12-compat (and the original codebase as well, which is still maintained even though it's deprecated).
rollcat 2y ago
I cannot find the article right now, but it was a wonderful piece on why a language like Rust is by design incompatible with the whole idea/process of making games. (I hope it rings a bell for someone who can find it.) It went something like this: you start with a nice little tidy spec for basic arithmetic; how "a + b" must be the same as "b + a", etc. Then the designer comes back to you and asks for the ability to make numbers blue. You're like wtf but ok, when you add a blue "a" to a non-blue "b", the result becomes blue; you must remove half of your tests (because they no longer even apply) and rewrite the other half to match the spec, and a week of work later the result somehow still makes some mathematical sense. Then the designer comes back to you with the request to make even numbers shoot sparks on death, and to remove all fives... And it's just how it goes. Games need to be iterated on quickly and efficiently, with a tight feedback loop on what ends up being fun during playtesting, and what doesn't. Rust might be great for writing low-level code / engines, but it will constantly get in your way where you need to respond quickly.
- pjmlp 2y ago
  It is from the same author, they link it on the readme.
  - rollcat 2y ago
    Silly me, thanks!
- capitainenemo 2y ago
  Interesting because there was a rust keynote by kyren arguing the exact same thing for why games were a poor fit for OOP/C++. Arguing for data oriented which rust does well. ... or C I suppose. It might be that rust ecosystem this dev was dealing with was itself draining with continually shifting APIs, but that's not the same as the language itself. https://kyren.github.io/2018/09/14/rustconf-talk.html https://kyren.github.io/2018/09/14/rustconf-talk.html
  - consteval 2y ago
    Most C++ games aren't really OOP C++. They're more loosey-goosey maybe you use some OOP stuff sometimes C++. The problem is C is far too low level. And everything you can do in C, you can do in C++. You just also get things like namespaces and RAII. From a game making perspective, there's no rules anywhere saying you have to write good, readable, C++. You can, and often people do, make amalgamations and monstrosities. You can do this very quickly, and if there's little bugs here and there it's no biggie, because you're just making a game. A segmentation fault is really not the end of the world.
jvanderbot 2y ago
Exactly, this is poor SWE. If you need a new feature from a latest rustc or an upstream, and can stomach losing users, then perhaps you mark things #[deprecated] for a release or two (which should be months, not days). AND don't bundle bugfixes with API breaks if it can be avoided. Otherwise, just don't bother! This is hype-driven development at its worst.
wormlord 2y ago
I sat down one weekend to try and make a demo in Bevy. The ECS system was cool, it's almost like querying a database. However every tutorial I found, even the most recent ones, were already outdated. They had just moved from 0.14 to 0.15 which broke a ton of things. I opted to mess around in Godot instead.
ogoffart 2y ago
Some crates are better than other. For Slint (Another GUI toolkit in Rust), we try to keep our API as stable as possible for as long as possible. We use other crates behind the scene such as winit and co., but we don't expose them in our public API, and we take care of the burden to update them.

by ndiddy 2y ago

desdenova 2y ago

The rust ecosystem is young, most of those libraries haven't even reached 1.0. Basing any serious project on 0.x libraries is always subject to this issue.

littlestymaar 2y ago
I'm always puzzled with people saying that things move too quickly and that they fail to keep up, in any language. Why do you guys even try to keep up in the first place? Unless there's a bug in a dependency you're using, if version 0.4 works, you don't have to use 0.5 or 0.6. Or maybe there's a new feature that you need in the newer version, then you can afford to spend time doing the migration but in this case you should also be happy the the pace of development is fast because that's how the feature ended up landing in the first place. For most use-cases, it's fine to stay on out of date libraries for years, and that's what the Linux distros do all the time (mostly patching crippling bugs and security vulnerabilities).
- mysterydip 2y ago
  90% agree. The scenario that I've seen that messes with this is when you include lib x which has dependency on version 0.5 of y, but your code depends on version 0.4 of y.
  - tstenner 2y ago
    cargo handles this just fine, unless you get lib y objects through the lib x api
aeurielesn 2y ago
I believe a post from one or two weeks ago showed it seems more of a systematic Rust ecosystem problem.
- CaptainOfCoit 2y ago
  What, exactly, is the problem? That libraries/projects remain below 1.0 for too long? Because lots of breaking changes before a 1.0.0 release is to be expected for anything following semver (which as far as I know, most if not all of the Rust ecosystem uses).
q3k 2y ago
> Basing any serious project on 0.x libraries is always subject to this issue. So I guess I'll hold off on having random numbers in Rust then [1]. [1] - https://docs.rs/rand/latest/rand/ https://docs.rs/rand/latest/rand/
- swfsql 2y ago
  It's already at 0.8, just another 20% and..!
mcpar-land 2y ago
On the flip side of this, when libraries in rust do reach 1.0, they often are just done. The serialization/deserialization library serde which has become the de-facto standard has been on 1.0.xxx for the past seven years. https://crates.io/crates/serde/versions https://crates.io/crates/serde/versions I think this speaks to rust's strengths in that if you know your spec, you can write a rock-solid version of it - and its weakness, where if you don't know your spec you'll be making breaking changes a lot.

rapsey 2y ago

Things move quickly because there is so much development being put into these base libraries. Which is of course a blessing and a curse.

lewispollard 2y ago

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.

viraptor 2y ago

wgpu only got the first non-0 release this July and started 4-ish years ago. They didn't even have a chance of taking 10 years. I'm sure SDL wasn't very API stable in 1998.

seba_dos1 2y ago
4 years after starting SDL was already deep into 1.2, which is the API that's still supported today via sdl12-compat (and the original codebase as well, which is still maintained even though it's deprecated).

rollcat 2y ago

I cannot find the article right now, but it was a wonderful piece on why a language like Rust is by design incompatible with the whole idea/process of making games. (I hope it rings a bell for someone who can find it.) It went something like this: you start with a nice little tidy spec for basic arithmetic; how "a + b" must be the same as "b + a", etc. Then the designer comes back to you and asks for the ability to make numbers blue. You're like wtf but ok, when you add a blue "a" to a non-blue "b", the result becomes blue; you must remove half of your tests (because they no longer even apply) and rewrite the other half to match the spec, and a week of work later the result somehow still makes some mathematical sense. Then the designer comes back to you with the request to make even numbers shoot sparks on death, and to remove all fives... And it's just how it goes. Games need to be iterated on quickly and efficiently, with a tight feedback loop on what ends up being fun during playtesting, and what doesn't. Rust might be great for writing low-level code / engines, but it will constantly get in your way where you need to respond quickly.

pjmlp 2y ago
It is from the same author, they link it on the readme.
- rollcat 2y ago
  Silly me, thanks!
capitainenemo 2y ago
Interesting because there was a rust keynote by kyren arguing the exact same thing for why games were a poor fit for OOP/C++. Arguing for data oriented which rust does well. ... or C I suppose. It might be that rust ecosystem this dev was dealing with was itself draining with continually shifting APIs, but that's not the same as the language itself. https://kyren.github.io/2018/09/14/rustconf-talk.html https://kyren.github.io/2018/09/14/rustconf-talk.html
- consteval 2y ago
  Most C++ games aren't really OOP C++. They're more loosey-goosey maybe you use some OOP stuff sometimes C++. The problem is C is far too low level. And everything you can do in C, you can do in C++. You just also get things like namespaces and RAII. From a game making perspective, there's no rules anywhere saying you have to write good, readable, C++. You can, and often people do, make amalgamations and monstrosities. You can do this very quickly, and if there's little bugs here and there it's no biggie, because you're just making a game. A segmentation fault is really not the end of the world.

jvanderbot 2y ago

Exactly, this is poor SWE. If you need a new feature from a latest rustc or an upstream, and can stomach losing users, then perhaps you mark things #[deprecated] for a release or two (which should be months, not days). AND don't bundle bugfixes with API breaks if it can be avoided. Otherwise, just don't bother! This is hype-driven development at its worst.

wormlord 2y ago

I sat down one weekend to try and make a demo in Bevy. The ECS system was cool, it's almost like querying a database. However every tutorial I found, even the most recent ones, were already outdated. They had just moved from 0.14 to 0.15 which broke a ton of things. I opted to mess around in Godot instead.

ogoffart 2y ago

Some crates are better than other. For Slint (Another GUI toolkit in Rust), we try to keep our API as stable as possible for as long as possible. We use other crates behind the scene such as winit and co., but we don't expose them in our public API, and we take care of the burden to update them.