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.
I'm glad the article was helpful though!
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
simultsop•3h ago
The outcome is the same, statically typed or dynamically. In both cases one need to perform refactoring in case of breaking changes.
ashishb•2h ago
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
phoronixrly•33m ago
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.