I'm currently struggling with instability in the Rust 3D graphics stack.
All this stuff has been around for about five years now, and was mostly working five years ago.
The APIs should have settled down long ago. Despite this, there are frequent "refactorings" which cause breaking changes to APIs. (I'm tempted to term this "refuckering".)
Some of this API churn is just renaming types or enum values for consistency, or adding new parameters to functions. Some changes are major, such as turning an event loop inside out. Code using the API must be fixed to compensate.
Because of all the breaking changes, the related crates (Wgpu, the interface to Vulkan, etc., Winit, the interface to the operating system's window manager, and Egui, which handles 2D dialog boxes and menus) must advance in lockstep. There's not much coordination between the various development groups on this. Wgpu and Winit both think they're in charge. and others should adapt to them. Egui tries to cope. Users of the stack suffer in silence.
When there's a bug, there's no going back to an older version. The refuckering prevents that. Changes due to API breaks are embedded in code that uses these APIs.
I'm currently chasing what ought to be a simple bug in egui, and I've been stuck for over a month.
The unit tests won't run for some target platforms that used to work, and bug reports are ignored while new
features are being added. (Users keep demanding more features in Egui, and Egui is growing towards web browser layout complexity.)
Most users are giving up. In the last year, three 3D rendering libraries and two major 3D game projects have been abandoned. There's are about two first-rate 3D games in Rust, Tiny Glade and Hydrofoil Generation, and both avoid this graphics stack.
The "Stability by Design" article is helpful in that it makes it clear what's gone wrong in Rust 3D land.
raspasov · 1h ago
Sorry to hear that.
Is it fair to assume that every individual library/API can somewhat easily create a brand-new-world with every release (because it won't compile until the types are "re-aligned") yet they don't bother to check if the new release works with any other library/API?
I think the problem is partially cultural with a specific ecosystem but also fundamental. It takes a lot of type craft, care and creativity to design future-proof function/method signatures that are "open" to extension without breakage.
potetm · 5h ago
That sounds like a complete tirefire tbh. The exact thing that I'm hoping to convince people to stop doing.
I'm glad the article was helpful though!
Animats · 5h ago
All the players think they're doing the right thing.
Each group is doing a reasonably good job based on their own criteria.
But their collective actions create a mess.
munificent · 1h ago
It's true that if you always add new functions to your library instead of changing existing ones then users can upgrade without breaking. There is real value in that.
But woe unto the user who first starts using your library after a decade of that "evolution" and they are faced with a dozen functions that all have similar but increasingly long names and do very similar things with subtle but likely important differences. (I guess a culture of "the longest function name is probably the newest and the one you want" will emerge eventually.)
Personally, I like when a library's API represents the best way the author knows to tackle a given problem today without also containing an accumulated pile of how they thought the problem should have been tackled years ago before they knew better.
If I want the old solutions, that's what versioning is for. I'll use the old version.
christophilus · 40m ago
Agreed. Create a new library if there’s truly a better way. That does seem to be what happens in Clojure from what I’ve seen.
RandomWorker · 2h ago
As a recent Clojure convert of 3 years or so, I love reading how amazing Clojure is. As a solo Dec there is simply no alternative. It’s so nice to return to a project 2 or 3 years ago and everything is still running and humming along smoothly as it did when I started the project.
I previously worked in PHP, Perl-cgi, Java, and Python- webtools mostly based on MySQL and other SQL database flavours.
I worked in a Clojure only shop for a while and they taught me the ways after that you don’t go back. Everything can quickly click into place, it’s daunting to start the learning curve is very unsteep, takes long to get anywhere, but as a curiosity it was fun, then I started to hate how everything else was done now I’m sold my soul to the Clojure devil.
juancn · 5h ago
The premise feel weird to me, I read the graphs much more as evidence of how scared the devs are to make changes rather than how "stable" the libraries are.
You add the code, and rather than change it if needed, you just leave it there and add more code.
You could argue too that Scala is much safer so changes to the code are not scary and it's easier to be stable even under code changes.
olivierduval · 3h ago
Actually, you can't neither read that or the opposite from the graphs: it doesn't if the new code is for new functionalities or if it's to replace (without deleting) some old code.
But you're right: that would be a particularily useful information
alexjurkiewicz · 2h ago
I think code retention charts will look similar for any major library in any language. Projects accrete code.
You could instead consider:
* How many major version releases / rewrites happen in this language? (This might be a sign of ecosystem instability.)
* How much new code is replacing old code? (This might imply the language needs more bugfixes.)
potetm · 2h ago
Not sure what you mean. The Scala example looks nothing like the Clojure examples.
The retention charts show you how much new code is replacing old code, and you can see the releases/rewrites as the code gets replaced.
simultsop · 6h ago
TLDR.
The outcome is the same, statically typed or dynamically. In both cases one need to perform refactoring in case of breaking changes.
ashishb · 5h ago
> The outcome is the same, statically typed or dynamically. In both cases one need to perform refactoring in case of breaking changes.
Maybe that's a bad example, as your build can fail because of a breaking change in a dependency regardless of whether you use a statically typed language.
Also your statement is only partially correct. Breaking changes in dependencies end up in production only if you don't have tests. And I know this is news to many people using static types but in many Ruby shops for example there are test coverages in excess of 90% and at the very least I never approve a PR without happy path tests.
ashishb · 1h ago
> Breaking changes in dependencies end up in production only if you don't have tests.
That's true.
However, you have now replaced the work of a compiler with testing.
All this stuff has been around for about five years now, and was mostly working five years ago. The APIs should have settled down long ago. Despite this, there are frequent "refactorings" which cause breaking changes to APIs. (I'm tempted to term this "refuckering".)
Some of this API churn is just renaming types or enum values for consistency, or adding new parameters to functions. Some changes are major, such as turning an event loop inside out. Code using the API must be fixed to compensate.
Because of all the breaking changes, the related crates (Wgpu, the interface to Vulkan, etc., Winit, the interface to the operating system's window manager, and Egui, which handles 2D dialog boxes and menus) must advance in lockstep. There's not much coordination between the various development groups on this. Wgpu and Winit both think they're in charge. and others should adapt to them. Egui tries to cope. Users of the stack suffer in silence.
When there's a bug, there's no going back to an older version. The refuckering prevents that. Changes due to API breaks are embedded in code that uses these APIs.
I'm currently chasing what ought to be a simple bug in egui, and I've been stuck for over a month. The unit tests won't run for some target platforms that used to work, and bug reports are ignored while new features are being added. (Users keep demanding more features in Egui, and Egui is growing towards web browser layout complexity.)
Most users are giving up. In the last year, three 3D rendering libraries and two major 3D game projects have been abandoned. There's are about two first-rate 3D games in Rust, Tiny Glade and Hydrofoil Generation, and both avoid this graphics stack.
The "Stability by Design" article is helpful in that it makes it clear what's gone wrong in Rust 3D land.
Is it fair to assume that every individual library/API can somewhat easily create a brand-new-world with every release (because it won't compile until the types are "re-aligned") yet they don't bother to check if the new release works with any other library/API?
I think the problem is partially cultural with a specific ecosystem but also fundamental. It takes a lot of type craft, care and creativity to design future-proof function/method signatures that are "open" to extension without breakage.
I'm glad the article was helpful though!
But woe unto the user who first starts using your library after a decade of that "evolution" and they are faced with a dozen functions that all have similar but increasingly long names and do very similar things with subtle but likely important differences. (I guess a culture of "the longest function name is probably the newest and the one you want" will emerge eventually.)
Personally, I like when a library's API represents the best way the author knows to tackle a given problem today without also containing an accumulated pile of how they thought the problem should have been tackled years ago before they knew better.
If I want the old solutions, that's what versioning is for. I'll use the old version.
I previously worked in PHP, Perl-cgi, Java, and Python- webtools mostly based on MySQL and other SQL database flavours.
I worked in a Clojure only shop for a while and they taught me the ways after that you don’t go back. Everything can quickly click into place, it’s daunting to start the learning curve is very unsteep, takes long to get anywhere, but as a curiosity it was fun, then I started to hate how everything else was done now I’m sold my soul to the Clojure devil.
You add the code, and rather than change it if needed, you just leave it there and add more code.
You could argue too that Scala is much safer so changes to the code are not scary and it's easier to be stable even under code changes.
But you're right: that would be a particularily useful information
You could instead consider:
* How many major version releases / rewrites happen in this language? (This might be a sign of ecosystem instability.)
* How much new code is replacing old code? (This might imply the language needs more bugfixes.)
The retention charts show you how much new code is replacing old code, and you can see the releases/rewrites as the code gets replaced.
The outcome is the same, statically typed or dynamically. In both cases one need to perform refactoring in case of breaking changes.
No. In statically typed languages, failures are usually caught in CI. In dynamically typed languages, they end up in production - https://github.com/pypa/setuptools/issues/4519
Also your statement is only partially correct. Breaking changes in dependencies end up in production only if you don't have tests. And I know this is news to many people using static types but in many Ruby shops for example there are test coverages in excess of 90% and at the very least I never approve a PR without happy path tests.
That's true. However, you have now replaced the work of a compiler with testing.