How Rust Finally Got a Specification - Thanks to a Consultancy's Open-Source Donation (rustfoundation.org) 16
As Rust approaches its 10th anniversary, "there is an important piece of documentation missing that many other languages provide," notes the Rust Foundation.
While there's documentation and tutorials — there's no official language specification: In December 2022, an RFC was submitted to encourage the Rust Project to begin working on a specification. After much discussion, the RFC was approved in July 2023, and work began.
Initially, the Rust Project specification team (t-spec) were interested in creating the document from scratch using the Rust Reference as a guiding marker. However, the team knew there was already an external Rust specification that was being used successfully for compiler qualification purposes — the FLS.
Thank Berlin-based Ferrous Systems, a Rust-based consultancy who assembled that description "some years ago," according to a post on the Rust blog: They've since been faithfully maintaining and updating this document for new versions of Rust, and they've successfully used it to qualify toolchains based on Rust for use in safety-critical industries. [The Rust Foundation notes it part of the consultancy's "Ferrocene" Rust compiler/toolchain.] Seeing this success, others have also begun to rely on the FLS for their own qualification efforts when building with Rust.
The Rust Foundation explains: The FLS provides a structured and detailed reference for Rust's syntax, semantics, and behavior, serving as a foundation for verification, compliance, and standardization efforts. Since Rust did not have an official language specification back then, nor a plan to write one, the FLS represented a major step toward describing Rust in a way that aligns with industry requirements, particularly in high-assurance domains.
And the Rust Project is "passionate about shipping high quality tools that enable people to build reliable software at scale," adds the Rust blog. So... It's in that light that we're pleased to announce that we'll be adopting the FLS into the Rust Project as part of our ongoing specification efforts. This adoption is being made possible by the gracious donation of the FLS by Ferrous Systems. We're grateful to them for the work they've done in assembling the FLS, in making it fit for qualification purposes, in promoting its use and the use of Rust generally in safety-critical industries, and now, for working with us to take the next step and to bring the FLS into the Project.
With this adoption, we look forward to better integrating the FLS with the processes of the Project and to providing ongoing and increased assurances to all those who use Rust in safety-critical industries and, in particular, to those who use the FLS as part of their qualification efforts.
More from the Rust Foundation: The t-spec team wanted to avoid potential confusion from having two highly visible Rust specifications in the industry and so decided it would be worthwhile to try to integrate the FLS with the Rust Reference to create the official Rust Project specification. They approached Ferrous Systems, which agreed to contribute its FLS to the Rust Project and allow the Rust Project to take over its development and management... This generous donation will provide a clearer path to delivering an official Rust specification. It will also empower the Rust Project to oversee its ongoing evolution, providing confidence to companies and individuals already relying on the FLS, and marking a major milestone for the Rust ecosystem.
"I really appreciate Ferrous taking this step to provide their specification to the Rust Project," said Joel Marcey, Director of Technology at the Rust Foundation and member of the t-spec team. "They have already done a massive amount of legwork...." This effort will provide others who require a Rust specification with an official, authoritative reference for their work with the Rust programming language... This is an exciting outcome. A heartfelt thank you to the Ferrous Systems team for their invaluable contribution!
Marcey said the move allows the team "to supercharge our progress in the delivery of an official Rust specification."
And the co-founder of Ferrous Systems, Felix Gilcher, also sounded excited. "We originally created the Ferrocene Language Specification to provide a structured and reliable description of Rust for the certification of the Ferrocene compiler. As an open source-first company, contributing the FLS to the Rust Project is a logical step toward fostering the development of a unified, community-driven specification that benefits all Rust users."
While there's documentation and tutorials — there's no official language specification: In December 2022, an RFC was submitted to encourage the Rust Project to begin working on a specification. After much discussion, the RFC was approved in July 2023, and work began.
Initially, the Rust Project specification team (t-spec) were interested in creating the document from scratch using the Rust Reference as a guiding marker. However, the team knew there was already an external Rust specification that was being used successfully for compiler qualification purposes — the FLS.
Thank Berlin-based Ferrous Systems, a Rust-based consultancy who assembled that description "some years ago," according to a post on the Rust blog: They've since been faithfully maintaining and updating this document for new versions of Rust, and they've successfully used it to qualify toolchains based on Rust for use in safety-critical industries. [The Rust Foundation notes it part of the consultancy's "Ferrocene" Rust compiler/toolchain.] Seeing this success, others have also begun to rely on the FLS for their own qualification efforts when building with Rust.
The Rust Foundation explains: The FLS provides a structured and detailed reference for Rust's syntax, semantics, and behavior, serving as a foundation for verification, compliance, and standardization efforts. Since Rust did not have an official language specification back then, nor a plan to write one, the FLS represented a major step toward describing Rust in a way that aligns with industry requirements, particularly in high-assurance domains.
And the Rust Project is "passionate about shipping high quality tools that enable people to build reliable software at scale," adds the Rust blog. So... It's in that light that we're pleased to announce that we'll be adopting the FLS into the Rust Project as part of our ongoing specification efforts. This adoption is being made possible by the gracious donation of the FLS by Ferrous Systems. We're grateful to them for the work they've done in assembling the FLS, in making it fit for qualification purposes, in promoting its use and the use of Rust generally in safety-critical industries, and now, for working with us to take the next step and to bring the FLS into the Project.
With this adoption, we look forward to better integrating the FLS with the processes of the Project and to providing ongoing and increased assurances to all those who use Rust in safety-critical industries and, in particular, to those who use the FLS as part of their qualification efforts.
More from the Rust Foundation: The t-spec team wanted to avoid potential confusion from having two highly visible Rust specifications in the industry and so decided it would be worthwhile to try to integrate the FLS with the Rust Reference to create the official Rust Project specification. They approached Ferrous Systems, which agreed to contribute its FLS to the Rust Project and allow the Rust Project to take over its development and management... This generous donation will provide a clearer path to delivering an official Rust specification. It will also empower the Rust Project to oversee its ongoing evolution, providing confidence to companies and individuals already relying on the FLS, and marking a major milestone for the Rust ecosystem.
"I really appreciate Ferrous taking this step to provide their specification to the Rust Project," said Joel Marcey, Director of Technology at the Rust Foundation and member of the t-spec team. "They have already done a massive amount of legwork...." This effort will provide others who require a Rust specification with an official, authoritative reference for their work with the Rust programming language... This is an exciting outcome. A heartfelt thank you to the Ferrous Systems team for their invaluable contribution!
Marcey said the move allows the team "to supercharge our progress in the delivery of an official Rust specification."
And the co-founder of Ferrous Systems, Felix Gilcher, also sounded excited. "We originally created the Ferrocene Language Specification to provide a structured and reliable description of Rust for the certification of the Ferrocene compiler. As an open source-first company, contributing the FLS to the Rust Project is a logical step toward fostering the development of a unified, community-driven specification that benefits all Rust users."
Now stick to it. (Score:2)
Now if only people that are publishing Rust code would stick to publishing code based on Rust's formal specifications then we might be able to get some reproducible builds.
Re: (Score:2)
Can you provide some examples of some non-reproducible builds?
Bootstrapping (Score:5, Interesting)
Most people install Rust through the "rustup" installer tool, which downloads rustc in executable form from a server controlled by the Rust project. This risks a supply chain attack as described in "Reflections on Trusting Trust" by Ken Thompson and as prototyped eight years ago in "Reflections on Rusting Trust" by Manish Goregaokar [github.io].
As I understand it, rustc is written in Rust and regularly uses language features that were recently made stable. This means each version of rustc can be compiled only by the same minor version of rustc or the previous minor version. This means that to fully bootstrap rustc from source code, you need to start with the last version of rustc supported by another compiler (usually mrustc [github.com]), and build the world once for each version. Until recently (December 2024, commit fe0a90e), the newest version of rustc supported by mrustc was 1.54, compared to current stable 1.85, requiring someone to build the world 32 times to make rustc itself reproducible. In December, support for rustc 1.74 was added.
For comparison, C and C++ are specified by an international standard that has multiple independent implementations. Because the compiler is written in a more stable standard language, it's easier for an integrator to skip versions. One can reproducibly bootstrap GCC [bootstrappable.org] from a simpler compiler: use TinyCC to build GCC 2.95, use GCC 2.95 to build GCC 4.7, and use GCC 4.7 to build something much more recent.
Re: (Score:2)
Most people install Rust through the "rustup" installer tool, which downloads rustc in executable form from a server controlled by the Rust project. This risks a supply chain attack as described in "Reflections on Trusting Trust" by Ken Thompson and as prototyped eight years ago in "Reflections on Rusting Trust" by Manish Goregaokar [github.io].
What does this have to do with making builds reproducible?
As I understand it, rustc is written in Rust and regularly uses language features that were recently made stable. This means each version of rustc can be compiled only by the same minor version of rustc or the previous minor version. This means that to fully bootstrap rustc from source code, you need to start with the last version of rustc supported by another compiler (usually mrustc [github.com]), and build the world once for each version. Until recently (December 2024, commit fe0a90e), the newest version of rustc supported by mrustc was 1.54, compared to current stable 1.85, requiring someone to build the world 32 times to make rustc itself reproducible. In December, support for rustc 1.74 was added.
This is called bootstrapping, it's not unique to rust. What came first, the chicken, or the egg?
For comparison, C and C++ are specified by an international standard that has multiple independent implementations. Because the compiler is written in a more stable standard language, it's easier for an integrator to skip versions. One can reproducibly bootstrap GCC [bootstrappable.org] from a simpler compiler: use TinyCC to build GCC 2.95, use GCC 2.95 to build GCC 4.7, and use GCC 4.7 to build something much more recent.
A standard isn't an inherent requirement to have multiple implementations. It can define an implementation and (hopefully) answer definitively whether an implementation isn't compliant, but that doesn't guarantee that they'll all be mutually compatible. Code compiled via g++ doesn't necessarily compile in clang++ or vc++ or vice versa, and even if it does,
Re: (Score:3)
Most people install Rust through the "rustup" installer tool, which downloads rustc in executable form from a server controlled by the Rust project. This risks a supply chain attack
What does this have to do with making builds reproducible?
If a supply chain attack on compiler distribution begins or ends between one build of a program and the next, it is likely that the executable is not reproduced. I fail to imagine a situation in which someone would want to deliberately reproduce a production executable with whatever backdoors were present in copies of the compiler downloaded on a given date, other than a forensic investigation of that particular backdoor.
This is called bootstrapping, it's not unique to rust.
You are correct that Rust is not the only language with few implementations. However, R
Re: (Score:2)
If a supply chain attack on compiler distribution begins or ends between one build of a program and the next, it is likely that the executable is not reproduced. I fail to imagine a situation in which someone would want to deliberately reproduce a production executable with whatever backdoors were present in copies of the compiler downloaded on a given date, other than a forensic investigation of that particular backdoor.
In the case of a supply chain attack, this would impact on the binaries on rustup for example. But this is not the only way to bootstrap rust.
There are other versions of the binary available, which would make rolling back to a previous version entirely possible. Either way this has nothing to do with reproducible builds in so far as I understand the term -- that the same source code will produce the same byte-identical, binary when built.
As for the lack of multiple implementations making bootstrapping harde
Spec encourages an LTS version of rustc (Score:2)
Maybe what I'm really getting at is that having a specification will make it easier to have a long-term-supported version of rustc. This way, each stable version of the compiler is written in the specified language, and the most recent LTS version can compile code in the specified language. This would allow skipping forward from one LTS to the next without having to build each intermediate stable rustc.
Re: (Score:2)
Heidegger wrote: "Existence in the greatest distance from the other- the distance that allows nothing to dissolve - but rather presents the 'thou' in the transparent, but 'incomprehensible' revelation of the 'just there'. That" is clearly what Heidegger was talking about undefined behavior. Or predestined, if that's it.
Obviously.
Now do the committee (Score:3)
Formal spec, now add the committee, and we truly have the next C++.
Never Snake (Score:3)
Re: Never Snake (Score:1)
Also spaces for indentation. One and only true char for indentation is tab.
Re: (Score:2, Insightful)
I started in C decades ago using snake case. Moving to camel case was a positive for me. Who the fuck are they to try to impose code style on the author?
Upon searching online for how to disable it, one invariably falls upon forums where we are told how imposing guidelines upon external authors is good... uhhh, for them?
I can understand enforcing guidelines within the Rust pro
Sigh. (Score:2)
Re: (Score:2)
Sigh. Since eons, there is CamelCase and mountainCase. What on earth is snake case?
it_has_thin_bits_and_bulges
Rust: Trying Too Hard for Linux Kernal (Score:2)