HIhitekker·Aug 20, 2025
You're part of the way there. Think less feature development, more architecture & governance.
A language reference is like documentation and a language specification is like a contract. If I uncover behavior in a system that isn’t documented, then I will update the documentation. But if the behavior fails to match the (formal) spec, then the system is at fault for not meeting the expectations of the contract, and the system needs to be corrected. As https://github.com/rust-lang/rfcs/pull/3355#issuecomment-134... states:
> If you built a rocket and that rocket crashes, you wouldn't update the spec of the rocket to say "it is expected to crash after reaching 3000m altitude". But if you made a typo that says the rocket should crash after reaching 3000m altitude and somehow passed review, you wouldn't add a self detonation device into the roc
Read the rest
ket just because of this either.
In contexts like safety critical/offline environments, the consequences of unexpected behavior can be dire and hard to fix in the moment (e.g. airplanes in flight). Liability becomes a real concern, and outside parties need a "contract" to be confident certain expectations or behaviors will be met in perpetuity. The reference doesn't offer that guarantee, and has understood itself to be a best-effort technical reference, despite attempts to increase its authoritativeness into a spec https://github.com/rust-lang/reference/issues/629
My opinion is that the spec is actually more needed for people inside the language than for people outside. Like the contractual element of a language spec fulfills a constitutional, if not judicial role, in the development process. However, I've learned requires a level of integrity that Rust can no longer hope to achieve.