Perhaps Rust should just take existing references and put them in a “Rust Standard.pdf” document with a note that anything not here is implementation-defined. It doesn’t have to be 100% comprehensive. C barely says what happens when you add two ints, and ISO OOXML got away with things like “render like word95” without further elaboration.
Yeah, this point about Rust not having a “specification” is getting tiresome. Very few languages have actual formal specifications with operational semantics that govern how they should work. SML is the only generally useful one I can think of.
From the article:
While we do have a reference that explains what features are stable and many of the guarantees of the language, it is not a complete specification.
What does the author feel is missing? There are no concrete examples, just a general statement.
I like pcwaltons approach here, which is basically just to rename the reference to “The Rust Specification” and then get people to shut up.
The memory model is missing. That’s a problem actively being worked on, but it’s probably the part of the language that is worst defined, because it isn’t even implementation defined.
I think it’s also incomplete in C though (see work on PNVI), so that’s fun.
I don’t agree with pcwalton fully here, particularly having looked at the reference from the perspective of someone in need of a specification (for Rust in safety critical). The reference is lacking both in content and in an important feature: traceability - it is hard to differentiate features in it that can be traced as requirements. Yes, the specification that we ended up writing is based on the Reference - it’s a great document to start with. https://spec.ferrocene.dev/general.html#general
By and large, too much of this discussion is controlled a) by a poor understanding that specifications can be a useful communication document and don’t need to be boring to read and b) seeing specification efforts through the experience of the C/C++ standardisation methodologies.
Top South Africa’s Top No Deposit Casinos. If you want to find some of the best online casinos that South Africa has to offer, where you can take advantage of a juicy no deposit bonus code, then you’re in the right place.
Secondly, there’s a variety of efforts to define similar formal semantics for Rust, just like CompCert exists for C. I think that’s beside the point: Those efforts are not what define the language, they are ex post efforts to make sense of whatever defines the language. In the case of JavaScript this is the defining specification.
I agree, but please we need to stop with the whole obsession with PDF documents for tech documentation. They’re just old-school and awkward to read on different devices. We invented hypertext documents for a reason, let’s use them! No one is printing off specifications and reading them on a couch by the fire anymore.
I feel like organisations/people choose PDFs to give their writing some kind of feeling of superiority, like how all the crypto scams projects release a wHiTePaPeR which is most of the time just a documentation web page printed into a PDF file.
They’re just old-school and awkward to read on different devices.
As someone who is looking at hardware documentation, ABI documentation, and various other standards a lot of the time, I still prefer PDFs because I don’t get variety in presentation. Figures look correct, things are generally aligned properly, and they are easier to share across internal networks. If I’m going to get a standards document, I don’t want it to be dependent on network access, nor do I want it to be a bundle of different files. Documentation in PDF form is almost always a single file. This makes search across the entire document simple. Also, if you do need to print parts of them (yes, it happens), the output will almost certainly match the display.
Hyperlinking in a PDF has worked for a long time, and any viewer I’ve used in the past 20 years supports such navigation.
PDFs are awkward to read on some devices, but they are still used because they are predictable and are more permanent. It has nothing to do with “a feeling of superiority” and more to do with online documentation constantly shifting.
If I’m going to get a standards document, I don’t want it to be dependent on network access, nor do I want it to be a bundle of different files.
EPUB is almost always a better choice than PDF these days. Yes, presentation can vary, but that’s a legitimate trade-off. PDFs often aren’t readable on anything where the screen won’t fit a letter-sized page in portrait orientation; with an EPUB you get readability on any device, in a single file, without network access being required. I admit that you lose things from PDF (predictable layout; screen layout being identical to print layout), but I think the trade-offs are usually worth it.
It’s alway a pain for me to read EPUBs on desktop. I never got around to finding a client or setup which I either like or “just works” and has sensible defaults. Where as decent, built-in PDFs clients are often right there. (A part of may be I have never been motivated to dive down the rabbit hole when I can just lean on my mobile clients)
For desktop, the easiest thing is to install a browser extension for EPUBs. On Linux and similar, Foliate is the best “just works” reader. I don’t know about MacOS and Windows.
Kindle on iPad was great for PDF until they gimped some point after Apr. 2021. Now you don’t get ToC or even the ability to zoom out (no reading progress too? I don’t remember)
Actually the people that read entire specifications are exactly the kind of people that print them off and read them on a couch by the fire. I certainly do (well, except for the fire - that’s not recommended for improving air quality in a densely populated city!).
(Though I still agree with your point, adding a legible print view to a hypertext document is much easier than the inverse)
It doesn’t define how the sign bit is stored. It doesn’t define how it overflows. It doesn’t dictate a specific size, only a range of sizes with details left up to the vendors. The Rust language specifies all of these things more precisely.
The C spec has a lot to say, but leaves a lot of things vague and vendor specific. In C you aren’t even supposed to expect bytes to have 8 bits.
But that’s not a lack of detail in the spec, it’s an explicit decision not to specify certain things in order support a wider range of hardware without affecting performance (for example). I don’t think it means the C standards are less deserving of being called standards or specifications than the Rust reference, do you?
One might also ask why Rust decided to call it a reference and not a spec or standard.
I’m not saying it’s not a standard, just that it barely defines what int addition is. Rust has a tendency to go for perfectionism, but that’s not necessary. Rust could also make an explicit decision to leave large “implementation-specific” gaps and still call it a spec. Or go the MS OOXML route and get ISO rubber-stamp that whatever the existing implementation does is the standard.
I’m not saying it’s not a standard, just that it barely defines what int addition is.
Then I don’t see the relevance. Are you saying the Rust reference gets points towards being considered a standard, because it specifies things that are deliberately unspecified in another language that has a standard?
Rust could also make an explicit decision to leave large “implementation-specific” gaps and still call it a spec.
People would make fun of it if the only reason for the implementation-specific gaps was laziness in documentation.
Perhaps this would be a good time to rethink the idea of the Standard Document (standards). The purposes of standards include providing a classification system, sets the settled questions, clarifies how future changes are made, and encourages thoughtful arguments. This leads to some interesting alternatives to the traditional Standard Document.
Standards Documents (standards) do not provide interoperability. Tests provide interoperability. Standards provide the framework and classification system for the tests. For example, a test to verify that converting to lowercase works in obscure Unicode situations might be named “test_section_9-15-b_for_obscure_unicode”. When the test suite encompasses the entire standard, interoperability. The classification system gets used by the tests, in discussions, and as shorthand for variants.
Standards draw the lines that cannot be clawed back. In Rust, ‘into()’ is severely over-loaded in meaning but cannot be clawed back; it’s part of the core language and would break too much code. Ask Bjarne Stroustrup about why exceptions and templates froze their evolution and he will point to the ISO application. People consistently banish JavaScript’s notorious == operator for its Byzantine casting rules, but it is still in the language. Once enshrined in the standard, the only changes can come from the processes in the standard.
The process of changing the standard affects the long term viability of the language. From the JavaScript extreme, where original JavaScript will usually run, to the Microsoft C# extreme, where migrating to the latest version is a bad business practice, the choices are difficult. There are whole systems of deprecation, semantic versioning, and practical considerations. For example, Python’s breaking transition to Python 3.0 would not allow a code base to run in both 3.0 and 2.6 simultaneously. Users avoided upgrading in droves. A more thoughtful upgrade path would have helped.
The thoughts, discussions, and arguments matter. For the previous example, if Unicode lowercase conversion adds memory or performance overhead, the language needs to decide between perfection and practicality. The pithy “Zen of Python” was written to summarize how tradeoffs had been decided and provides a twenty line list of prioritized design principles that are referenced constantly in Python feature discussions. Usually, starting a discussion about standards marks a time for these arguments about design principles to be made.
There are other ideas for Standards Documents that might make better use of these arguments. For example, the Jewish holy book of Torah contains the original holy text surrounded by competing arguments. Those seeking to understand or change an interpretation have a view into the crucible of observations and insights that made the decision. Imagine a standards document that selected advocates to present why and why not Rust should strive to have perfect Unicode lowercase conversion. Alternately, imagine a standards document that simply defined the vocabulary and organization of language discussions. The goal of the document to have more productive discussions.
One does not need to slavishly follow standards documents of the past.
While for many users, a specification would just be “nice to have”, there are also Rust users for whom such a specification is absolutely necessary to be able to use Rust for the field they work in. For example, safety critical Rust software for automotive or aerospace applications usually needs to pass certification, a process designed to gain confidence in the exact behavior of software through, among other things, specification and testing.
The demand for Rust evolution still outweighs the cost of Rust evolution, so it is (by logic) unlikely for a standard to emerge at this point in time.
As Rust grows (and it does seem to be growing well), the cost of evolution will increase dramatically as a natural consequence of being used by many people, and it stands to reason that stability and predictability will (at least for point in time versions) show a higher demand than language evolution. Whether that results in a standardization process is unpredictable, but it does seem likely that we will see a more concrete specification process emerge.
I agree with the post - a specification is much more important than a standard (though the two would most likely be related).
I can’t think of anything more important to have than a language specification. I’m pro specification of applications as well, but if you’re going to specify anything it should be a foundational tool like a language. If you can’t know anything precise about a language, then that infects all applications and tools in that ecosystem. It sets a very poor foundation to build on.
I think it’s the opposite. Specification wouldn’t change anything.
Rust cares about compatibility with the ecosystem. If the specification disagreed with what the crates rely on, the crates would win almost every time.
For safe subset of Rust you don’t even need to know the spec. If it compiles, it’s correct.
What I’m noticing in the description of the RFC process, and which other RFC process like the attempted one in Nix also suffer from, is that there is no clear explanation of how an RFC is rejected. There is a baseline assumption that most proposed changes will eventually be good enough to be accepted.
I think it would help these processes if it were made clear exactly how changes are to be rejected, and that this is included whenever the process is described.
(Obviously slightly off-topic but wanted to get that thought out there.)
RFCs do get closed or postponed, and the process for that is the same as acceptance: someone from the team proposes to do this, and there’s a vote on the decision.
It almost seems that Rust doesn’t want the competition from other compilers, like intel and or nvidia. If Rust would actually become popular outside the blogosphere, commercial compilers are bound to appear.
If you knew that much about them, you’d know that mrustc is working perfectly fine to bootstrap rustc 1.54.0 for systems that aren’t supported. That means it is a rust compiler, otherwise it couldn’t bootstrap the (rust written) rustc. The borrow-rules are irrelevant for that. So all you’re doing is being rude.
GCC-RS is in the works and is also pretty much endorsed by everyone - you’re bashing something that went from 0 to halfway there in a tiny fraction of the time rustc exists. The only thing rustc wants to avoid is the difference you have between clang, gcc and msvc - despite a supposedly standard.
If you knew that much about them, you’d know that mrustc is working perfectly fine to bootstrap rustc 1.54.0 for systems that aren’t supported. That means it is a rust compiler, otherwise it couldn’t bootstrap the (rust written) rustc. The borrow-rules are irrelevant for that. So all you’re doing is being rude.
hmm… why would it need to bootstrap rustc if it’s a rust compiler in its own right?
If someone wanted to create a commercial compiler, they’d be more likely to fork the (permissively licensed) reference implementation and add some secret-sauce optimisations on top. They wouldn’t worry too much about a spec because they’d be using the same front end as the reference implementation. A spec is useful for understanding whether a particular output of the reference compiler is the result of an implementation bug or a language design choice.
It almost seems that Rust doesn’t want the competition from other compilers, like intel and or nvidia.
Who is this “Rust” you are talking about? The core team? They have done nothing I’m aware of to deter or discourage alternate implementations.
As /u/kornel mentions, there is already mrustc, GCC Rust and even things like cranelift that can eventually become full alternate implementations.
If Rust would actually become popular outside the blogosphere, …
Real people are using it for real projects, and seeing real benefits. If you don’t like it, that’s fine. But as it turns out, a lot of people like tools that help them write correct and reliable code.
… commercial compilers are bound to appear.
Eh, maybe. A valid criticism of Rust is that it is itself complex, and the toolchain implementation is big and complicated. It would be a lot of work to create an entire implementation from scratch, and you wouldn’t see benefit for years. If the Rust core team displays bad governance, is slow and / or recalcitrant to accept outside contributions or other issues, I could see a stronger push for a commercial offering. But I think you would have a hard time arguing that is the case right now.
Perhaps Rust should just take existing references and put them in a “Rust Standard.pdf” document with a note that anything not here is implementation-defined. It doesn’t have to be 100% comprehensive. C barely says what happens when you add two
ints, and ISO OOXML got away with things like “render like word95” without further elaboration.Yeah, this point about Rust not having a “specification” is getting tiresome. Very few languages have actual formal specifications with operational semantics that govern how they should work. SML is the only generally useful one I can think of.
From the article:
What does the author feel is missing? There are no concrete examples, just a general statement.
I like pcwaltons approach here, which is basically just to rename the reference to “The Rust Specification” and then get people to shut up.
A lot of things are missing completely, as far as I understand:
Thank you, those are indeed missing.
The memory model is missing. That’s a problem actively being worked on, but it’s probably the part of the language that is worst defined, because it isn’t even implementation defined.
I think it’s also incomplete in C though (see work on PNVI), so that’s fun.
I don’t agree with pcwalton fully here, particularly having looked at the reference from the perspective of someone in need of a specification (for Rust in safety critical). The reference is lacking both in content and in an important feature: traceability - it is hard to differentiate features in it that can be traced as requirements. Yes, the specification that we ended up writing is based on the Reference - it’s a great document to start with. https://spec.ferrocene.dev/general.html#general
By and large, too much of this discussion is controlled a) by a poor understanding that specifications can be a useful communication document and don’t need to be boring to read and b) seeing specification efforts through the experience of the C/C++ standardisation methodologies.
Formal operational semantics of JavaScript, tested against test262 test suite, also exists: https://jscert.org/
First of all, wtf?
Secondly, there’s a variety of efforts to define similar formal semantics for Rust, just like CompCert exists for C. I think that’s beside the point: Those efforts are not what define the language, they are ex post efforts to make sense of whatever defines the language. In the case of JavaScript this is the defining specification.
I agree, but please we need to stop with the whole obsession with PDF documents for tech documentation. They’re just old-school and awkward to read on different devices. We invented hypertext documents for a reason, let’s use them! No one is printing off specifications and reading them on a couch by the fire anymore.
I feel like organisations/people choose PDFs to give their writing some kind of feeling of superiority, like how all the crypto
scamsprojects release a wHiTePaPeR which is most of the time just a documentation web page printed into a PDF file.As someone who is looking at hardware documentation, ABI documentation, and various other standards a lot of the time, I still prefer PDFs because I don’t get variety in presentation. Figures look correct, things are generally aligned properly, and they are easier to share across internal networks. If I’m going to get a standards document, I don’t want it to be dependent on network access, nor do I want it to be a bundle of different files. Documentation in PDF form is almost always a single file. This makes search across the entire document simple. Also, if you do need to print parts of them (yes, it happens), the output will almost certainly match the display.
Hyperlinking in a PDF has worked for a long time, and any viewer I’ve used in the past 20 years supports such navigation.
PDFs are awkward to read on some devices, but they are still used because they are predictable and are more permanent. It has nothing to do with “a feeling of superiority” and more to do with online documentation constantly shifting.
EPUB is almost always a better choice than PDF these days. Yes, presentation can vary, but that’s a legitimate trade-off. PDFs often aren’t readable on anything where the screen won’t fit a letter-sized page in portrait orientation; with an EPUB you get readability on any device, in a single file, without network access being required. I admit that you lose things from PDF (predictable layout; screen layout being identical to print layout), but I think the trade-offs are usually worth it.
It’s alway a pain for me to read EPUBs on desktop. I never got around to finding a client or setup which I either like or “just works” and has sensible defaults. Where as decent, built-in PDFs clients are often right there. (A part of may be I have never been motivated to dive down the rabbit hole when I can just lean on my mobile clients)
I feel the same about PDF on mobile, though.
For desktop, the easiest thing is to install a browser extension for EPUBs. On Linux and similar, Foliate is the best “just works” reader. I don’t know about MacOS and Windows.
Kindle on iPad was great for PDF until they gimped some point after Apr. 2021. Now you don’t get ToC or even the ability to zoom out (no reading progress too? I don’t remember)
In some cases, it can be beneficial if a document is annoying to read on phones.
Seconded. I’ve tried a few different ones and the display has been hideous. And for some reason navigation was a mess.
HTML can totally be put in a single offline-usable file. And looking different on different screen is a good thing.
Actually the people that read entire specifications are exactly the kind of people that print them off and read them on a couch by the fire. I certainly do (well, except for the fire - that’s not recommended for improving air quality in a densely populated city!).
(Though I still agree with your point, adding a legible print view to a hypertext document is much easier than the inverse)
Are you saying that the various C standards and specifications are less detailed and comprehensive than the Rust reference?
It doesn’t define how the sign bit is stored. It doesn’t define how it overflows. It doesn’t dictate a specific size, only a range of sizes with details left up to the vendors. The Rust language specifies all of these things more precisely.
The C spec has a lot to say, but leaves a lot of things vague and vendor specific. In C you aren’t even supposed to expect bytes to have 8 bits.
But that’s not a lack of detail in the spec, it’s an explicit decision not to specify certain things in order support a wider range of hardware without affecting performance (for example). I don’t think it means the C standards are less deserving of being called standards or specifications than the Rust reference, do you?
One might also ask why Rust decided to call it a reference and not a spec or standard.
I’m not saying it’s not a standard, just that it barely defines what
intaddition is. Rust has a tendency to go for perfectionism, but that’s not necessary. Rust could also make an explicit decision to leave large “implementation-specific” gaps and still call it a spec. Or go the MS OOXML route and get ISO rubber-stamp that whatever the existing implementation does is the standard.Then I don’t see the relevance. Are you saying the Rust reference gets points towards being considered a standard, because it specifies things that are deliberately unspecified in another language that has a standard?
People would make fun of it if the only reason for the implementation-specific gaps was laziness in documentation.
Perhaps this would be a good time to rethink the idea of the Standard Document (standards). The purposes of standards include providing a classification system, sets the settled questions, clarifies how future changes are made, and encourages thoughtful arguments. This leads to some interesting alternatives to the traditional Standard Document.
Standards Documents (standards) do not provide interoperability. Tests provide interoperability. Standards provide the framework and classification system for the tests. For example, a test to verify that converting to lowercase works in obscure Unicode situations might be named “test_section_9-15-b_for_obscure_unicode”. When the test suite encompasses the entire standard, interoperability. The classification system gets used by the tests, in discussions, and as shorthand for variants.
Standards draw the lines that cannot be clawed back. In Rust, ‘into()’ is severely over-loaded in meaning but cannot be clawed back; it’s part of the core language and would break too much code. Ask Bjarne Stroustrup about why exceptions and templates froze their evolution and he will point to the ISO application. People consistently banish JavaScript’s notorious
==operator for its Byzantine casting rules, but it is still in the language. Once enshrined in the standard, the only changes can come from the processes in the standard.The process of changing the standard affects the long term viability of the language. From the JavaScript extreme, where original JavaScript will usually run, to the Microsoft C# extreme, where migrating to the latest version is a bad business practice, the choices are difficult. There are whole systems of deprecation, semantic versioning, and practical considerations. For example, Python’s breaking transition to Python 3.0 would not allow a code base to run in both 3.0 and 2.6 simultaneously. Users avoided upgrading in droves. A more thoughtful upgrade path would have helped.
The thoughts, discussions, and arguments matter. For the previous example, if Unicode lowercase conversion adds memory or performance overhead, the language needs to decide between perfection and practicality. The pithy “Zen of Python” was written to summarize how tradeoffs had been decided and provides a twenty line list of prioritized design principles that are referenced constantly in Python feature discussions. Usually, starting a discussion about standards marks a time for these arguments about design principles to be made.
There are other ideas for Standards Documents that might make better use of these arguments. For example, the Jewish holy book of Torah contains the original holy text surrounded by competing arguments. Those seeking to understand or change an interpretation have a view into the crucible of observations and insights that made the decision. Imagine a standards document that selected advocates to present why and why not Rust should strive to have perfect Unicode lowercase conversion. Alternately, imagine a standards document that simply defined the vocabulary and organization of language discussions. The goal of the document to have more productive discussions.
One does not need to slavishly follow standards documents of the past.
[Comment removed by author]
This is addressed in the post:
The demand for Rust evolution still outweighs the cost of Rust evolution, so it is (by logic) unlikely for a standard to emerge at this point in time.
As Rust grows (and it does seem to be growing well), the cost of evolution will increase dramatically as a natural consequence of being used by many people, and it stands to reason that stability and predictability will (at least for point in time versions) show a higher demand than language evolution. Whether that results in a standardization process is unpredictable, but it does seem likely that we will see a more concrete specification process emerge.
I agree with the post - a specification is much more important than a standard (though the two would most likely be related).
I can’t think of anything more important to have than a language specification. I’m pro specification of applications as well, but if you’re going to specify anything it should be a foundational tool like a language. If you can’t know anything precise about a language, then that infects all applications and tools in that ecosystem. It sets a very poor foundation to build on.
I think it’s the opposite. Specification wouldn’t change anything.
Rust cares about compatibility with the ecosystem. If the specification disagreed with what the crates rely on, the crates would win almost every time.
For safe subset of Rust you don’t even need to know the spec. If it compiles, it’s correct.
What I’m noticing in the description of the RFC process, and which other RFC process like the attempted one in Nix also suffer from, is that there is no clear explanation of how an RFC is rejected. There is a baseline assumption that most proposed changes will eventually be good enough to be accepted.
I think it would help these processes if it were made clear exactly how changes are to be rejected, and that this is included whenever the process is described.
(Obviously slightly off-topic but wanted to get that thought out there.)
RFCs do get closed or postponed, and the process for that is the same as acceptance: someone from the team proposes to do this, and there’s a vote on the decision.
An RFC/issue to get cargo to use the XDG base dirs spec dragged on for what seemed like years, and went nowhere. So it’s a worthwhile thought.
It almost seems that Rust doesn’t want the competition from other compilers, like intel and or nvidia. If Rust would actually become popular outside the blogosphere, commercial compilers are bound to appear.
That’s a baseless assumption. There’s mrustc and gcc-rs already, and existence of other compilers would benefit the language.
They exist but they don’t work and I bet you know this, not sure why you decided to write this bullshit.
If you knew that much about them, you’d know that mrustc is working perfectly fine to bootstrap rustc 1.54.0 for systems that aren’t supported. That means it is a rust compiler, otherwise it couldn’t bootstrap the (rust written) rustc. The borrow-rules are irrelevant for that. So all you’re doing is being rude.
GCC-RS is in the works and is also pretty much endorsed by everyone - you’re bashing something that went from 0 to halfway there in a tiny fraction of the time rustc exists. The only thing rustc wants to avoid is the difference you have between clang, gcc and msvc - despite a supposedly standard.
hmm… why would it need to bootstrap rustc if it’s a rust compiler in its own right?
You don’t “need” to, but for various reasons some people want to.
Rust Evangelism Strikeforce
If someone wanted to create a commercial compiler, they’d be more likely to fork the (permissively licensed) reference implementation and add some secret-sauce optimisations on top. They wouldn’t worry too much about a spec because they’d be using the same front end as the reference implementation. A spec is useful for understanding whether a particular output of the reference compiler is the result of an implementation bug or a language design choice.
Who is this “Rust” you are talking about? The core team? They have done nothing I’m aware of to deter or discourage alternate implementations.
As /u/kornel mentions, there is already mrustc, GCC Rust and even things like cranelift that can eventually become full alternate implementations.
Real people are using it for real projects, and seeing real benefits. If you don’t like it, that’s fine. But as it turns out, a lot of people like tools that help them write correct and reliable code.
Eh, maybe. A valid criticism of Rust is that it is itself complex, and the toolchain implementation is big and complicated. It would be a lot of work to create an entire implementation from scratch, and you wouldn’t see benefit for years. If the Rust core team displays bad governance, is slow and / or recalcitrant to accept outside contributions or other issues, I could see a stronger push for a commercial offering. But I think you would have a hard time arguing that is the case right now.