[Animats]

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.

[potetm]

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]

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.

[lelanthran]

I think this is just the nature of Rust - everything needs to be specified upfront by the developer. Other languages are much more flexible in this regard.

It's also why we see so few original projects in Rust (compared to Go, etc), and so many rewrite-in-Rust projects: A rewrite of `ls` or `grep` is a project that has an engraved-in-stone requirement.

Creating an entire new project requires more flexibility as the requirements are only fully specified once some user feedback is in.

It would not be wise to choose Rust for something of an exploratory nature; anything original is going to be painful as large-scale refactors (which are a necessity in an original project) are going to be particularly painful.

[ogoffart]

Just wanted to mention that Slint has had a stable API for over two years now. (We released Slint 1.0 more than two years ago and have kept things backward compatible since) So stable GUI APIs in Rust are possible. If you're looking for something solid to build on, Slint might be worth a look.

[mwcampbell]

As a contributor to the Rust GUI ecosystem [1], I've been affected (somewhat) by that churn and have also contributed to it. The best defense I can give for doing what might be considered refuckering is that when my library eventually hits 1.0, I want to meet the same standard of stability as Rust itself, and when that point comes, as @munificent said [2], I want my library to represent my best understanding of how to design an API for what I'm doing, with no legacy baggage. Hopefully I don't piss off current users between now and 1.0.

[1]: https://accesskit.dev/

[2]: https://news.ycombinator.com/item?id=43933068

[exac]

Would you consider https://0ver.org/ instead?

[jrvieira]

How would 0ver contribute to anything positive here?

[codeflo]

This is an issue that plagues modern open-source libraries in general, but the ones you mention, Winit and Wgpu, are particularly awful examples of this disease. Winit turning the event loop inside out might have had a reason on some platform, though I don't see why the old API couldn't have been supported anymore. Both projects frequently shuffle around their data structures with no rhyme or reason. Everything built on top of them breaks all the time, for tiny perceived gains in naming consistency. I think your suggested term "refuckering" is indeed a nice way to put it.

[guappa]

That's an issue on projects managed by inexperienced people. The license has little to do with this.

However I find that inexperienced people tend to coalesce around some languages rather than others.

[raspasov]

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.

[0x1ceb00da]

This is what you get if you start by making a library. First step should be making a program and once you have a fully functional, real world application, you should consider abstracting parts of it into a library.

[raspasov]

I think most good libraries (regardless of language) are born out of a process like you described.

When I made the comment above, I assume a library has already passed that filter.

[Animats]

There are multiple combos. Egui can run on top of Wgpu or the simpler Eframe. Wgpu can be used with various 2D UIs on top. Winit is used by many non-3D programs. Getting all the combos right is tough.

[simultsop]

In a world where everything means everything, fighting ambiguity is not an easy task. Hence the refactoring.

> When there's a bug, there's no going back to an older version.

This practice is developed by the industry for a reason. It would be really silly to hear people running AI in Windows XP.

> Most users are giving up.

Rust is pretty new, users shouldn't rush to switch a stack because of hype. It takes time for languages to mature, even more for the ecosystem.

[pier25]

This refuckering reminds me a lot of the JS ecosystem...

[BasilInc]

I like the term refuctoring for this