by testdelacc1 | 2025-08-20 05:34:09+00:00
Yeah I think I understand.

My perspective of following the compiler development is that very often much needed features aren’t developed because of outside constraints - lack of a person to push it through, lack of consensus on how to implement it and the codebase not being built in a way that supports the feature at all.

A couple of features spring to mind - partial borrows of strict fields by methods and several “obvious” improvements to the type system. I think everyone wants the first feature but it’s hard to implement in the current borrowchecker codebase. Similarly, many features are blocked on the next gen trait solver because the current one is crusty and difficult to work with. Fortunately, I think they’re relatively close with the latter. I believe rust-analyzer is moving to the new trait solver and perhaps rustc will in the future as well. That will unlock a lot of improvements and importantly, fix many soundness issues in the compiler as well.

I can see where you’re coming from. A spec that you can point to allows a user to report a bug with some authority - your implementation is failing to adhere to the spec you wrote. Therefore this bug should be prioritised. And maybe this will lead to higher quality software.

The other perspective is that I’ve seen a lot of good developers, who have a lot of context on the project, leave the project. The reasons vary, but I gather burn out is a common one. They like their coworkers, they like the impact they’re having, but they don’t like a lot of the problems that come with maintaining a large open source project. Entitled people, drive by commenters, a codebase that has developed in layers over 15 years, slow feedback loops on RFCs. I fear that if we added people demanding fixes because of spec adherence, it would be one more source of burnout. This could slow down development as more people leave.

The folks working on the new trait solver are aware of the issues in the existing trait system. You can see all the soundness issues, many of which are tagged T-types here (https://github.com/rust-lang/rust/issues?q=is%3Aissue+is%3Ao...). They really want to fix these, and they hope the new trait solver makes it easier to get there. The constraints of the implementation appear to be driving which soundness issues get worked on. Issues have been paused with the hope that they will go away or be easy to fix with the new system. All energy goes instead to migrating to the new system.

Would it really help if someone said that hey, according to the project constitution, you’ve committed to fixing spec violations before you do feature work like new trait solver. Maybe, I don’t know. My experience with spec driven development is limited.

But my intuition would be to trust the people who’ve done the development so far. They’ve done a pretty good job of producing a successful, performant language. They’re able to add features much more quickly than most other comparable languages while maintaining a high degree of stability. They’ve supported an ecosystem that has roughly doubled in size every year for 10 years. If they want to do spec driven development, sure. If they don’t, that’s fine with me too.

I want them to choose a development system and a quality bar that they’re happy with. Today it’s RFCs and crater runs. Tomorrow it could be spec and spec. If they’re happy, I’m happy.