It's actually quite relevant to the matter of specifications, though perhaps indirectly.
This chapter describes rather well the different ways to bootstrap a compiler, so how to make it compile itself when it's written in its own source language and there's not other compiler for that language yet[1].
If you start with a very simple version of the compiler for a language X (let's call this version "a"), written in a simple version V1 of language X, and if you're using a simple compiler or interpreter for X version V1 (let's call it "b") written in another available language, you'll get a first executable for a given platform. You can then use that executable to make "a" compile itself for that platform. You've just bootstrapped your compiler. For that to be successful, you must be sure that "a" and "b" agree on the language X in its version V1.
That's a first example. From what I read, the bootstrapping step was done in OCaml for Rust. Arguably, it must be done only for that early version V1 of the language, which will be as simple as possible because you also have to write the compiler in another language for it.
Instead, if you adopt the strategy Writh used for Pascal, using an intermediate "language" P, you must ensure that this intermediate language will be coherently compiled or interpreted on all platforms. It's very likely other people wrote their own P interpreter or compiler for new platfoms, so the P specifications had to precise enough. I don't think this technique is used these days because there are backends like LLVM for most platforms[2], but interpreting / compiling bytecode follows the same idea; e.g. for Java, Python or C# (or any .NET language).
the whole book is available from P.D. Terry's homepage, where you can find a clearer description of T-diagrams in chapter 2, if it's necessary. ↩︎
for which the Intermediate Representation input, or IR, must be interpreted exactly the same way for all platforms, so it must have a good spec, too. ↩︎
Can you please not respond to every "should I write X" with "no, because AI"? It contributes nothing to the conversation. All it does is lead to more off-topic discussions about the capabilities of LLMs in software development, which we don't need more of. You're not answering the question, you're ignoring it.
A year ago, I supported your opinion People said to me - how do you write Rust without Clippy? Please, stop saying nonsense, I replied. Computers never can be clever than a man. Finally, I tried Clippy. Oh boy, it pointed to hundred imperfections in my code. Now I'm rewriting my code using AI, it becomes smaller and smarter. I can't write code even closer to the quality given by AI. Maybe programming isn't my job? You can be right here.
I'm not saying your viewpoint is invalid or not allowed here; there have been plenty of discussions about the merits or demerits of AI-driven development. What I don't believe is valid is dismissing questions with "just throw AI at it". The fact that they're asking the question at all shows that they clearly don't value that answer.
Except bear in mind that when a person asks a question about X because they want to know or understand something about it then giving an answer that suggests not doing X, instead get someone or something else to do, it is not appropriate or helpful.
in my opinion rust not having a standard doesn't matter for writing a compiler, or any other non-safety-critical projection,
it may matter for using your language and compiler in safety-critical systems (but that's a problem for later, when your project becomes successful, not the start of your project),
what matters is that rust has good documentation, and how easy/difficult it is to make mistakes (and rust has a tendency to catch mistakes at compile time that other languages either turn into undefined behaviour or catch at runtime)
also rust has algebraic datatypes, i do not know how i would represent a AST without them, and a lot of languages lack algebraic data types.
Certain certifications require it. You only need to concern yourself with this if you work on safety- and mission-critical systems (automotive, aerospace, medical, etc.)
If that's the case you still have the option to use the Ferrocene toolchain - which is based on a subset of Rust 2021 edition and has a specification. This spec was actually donated to the Rust project and will eventually become the Rust language specification. For more background info:
however using a certified compiler/language is not enough, your code also needs to be certified, and that's very difficult to achieve (and unlikely to be worth it).
It can matter in safety critical systems because of the concept of a "qualified compiler" (like Ferrocene is for Rust). Ferrocene worked round this by writing their own specification for Rust, which they've generously donated to the Rust Foundation, and which fills the needs of a qualified compiler.
A qualified compiler, in turn, is one where a safety auditor can look at the language specification, the rules from the compiler vendor, your source code and your hardware, and either state definitively that your system meets a given safety standard, or point to the reasons why your system does not meet that standard.
It's not absolutely required when working on safety critical systems, because you can choose to do your safety audits on the binary output from the compiler, not the source, but it's generally much easier (and hence cheaper) to audit your source code to confirm that you comply with a safety standard than to audit binaries for compliance.
And note that all of this is part of a wider process your company has to go through; you've also got to be able to show, to an auditable standard, that you have sufficient change control, code review, high-quality testing etc to actually meet the safety standard.
Says who? And why would this be the case? This has nothing to do with language specification.
"customers", why not "users" ? I don't know, felt like a weird wording.
Because it's a company...selling solutions to their customers? What's weird about that? It's not exclusive to Rust, pretty much all safety-critical software works like this: even C/C++ compiler toolchains need certifications and this costs a lot of money. This was traditionally always a very closed field with a few specialized vendors.
for normal "cybersecurity" its fine, and better than c/c++,
what they mean is it isn't good enough for planes, cares, pace makers, critical infrastructure, etc.
i am not sure about this, but normal c++ also isn't "good enough", it also needs special compilers and/or coding practices.
That's the ideal, but in practice it seems largely to be a way for commercial entities (mostly compiler vendors) to protect themselves (in both good and bad ways) - hence the extreme membership costs for most committees.
Thats a whole other thread, though, the relevant part for this thread is just that standards come after the fact of multiple commercial vendors in practice, regardless of if they may theoretically be most valuable as the contract between the developer and the compiler.
Sure. And any LLM can find more imperfections in my code, too. That's not the point. The point was this:
That's nonsense. LLMs (and clippy) are great at noticing small inefficiencies. LLMs can also work with short descriptions to write short pieces of code — but if it couldn't test them, immediately, then by the time tests can be run on a few thousands lines of code it becomes hoplessly lost. Human can write an interpreter and compiler without having bazillion tests (Woz wrote BASIC and hand-assembled it to to machine code, Hejlsberg wrote Turbo Pascal for the cassete-based operation system in a similar fashion) — and that's somerthing AI couldn't do yet and wouldn't be able to do any time soon.
The only more-or-less honest guy in that crazyness, Demis Hassiabis expects that it would take 5-10 more years before that point… but that's 5-10 years of research! And AI is not getting 5-10 years of research! AI have to deliver trillions of dollars of revenue in next 2-3 years and if research takes 5-10 years and investment bubble needs 2-3, then that means investment bubble would, inevitably, collapse and research would be restarted later… my 10-20 years estimate is optimistic, it may even take 30-40 years, easily!
And you portray these future development, where these “scientific breakthroughs” have happened not just inevitable but as if they have already happened! But that's precisely why they are not happening any time soon: “fake it till you make it” crowd promised precisely these things, and when they were unable to deliver they started raising stakes, instead of admitting their lies. Today, for AI bubble to not detonate, LLMs have to replace all the software industry, half of the lawmakers and support teams, etc… and tomorrow it would need even more things that are not even remotely ready to be delivered!
The AI discussion was already put to bed as off topic and derailing. Do not summon the Mods so carelessly, as they are wroth, and filled with cruel vengeance.
I was just watching a presentation about the history of Sqlite. Seems they have 250 thousand lines of code in Sqlite and over 600 thousand lines of tests.
That hints at the idea that if you want to specify to an LLM how to build a compiler (Sqlite is a kind of compiler) and achieve that level of quality you are going to be doing a lot of work creating that spec and/or tests. So much so that we might wonder if using the LLM to generate the code from it is really worth the bother. and expense.
What's the big deal with standards? C was created from language that had no standard, languages were created using C before it had any kind of standard. Meanwhile we have ISO standards for things like Pascal and BASIC that are dead and nobody cares about. Also I'm sure you will find the likes of GCC and LLVM are written using non-standard exceptions to C and C++, as well as implementing non-standard features.
I think standards should reflect best industry practice, or at least industry practice, rather than try and dictate what should be. So I would say that if one wants an ISO standard for Rust, or some such, that should come after we have more than one Rust compiler, as a way that such developments are kept in sync and compatible.
My worst nightmare for Rust would be ending up with something like the C++ standards committee. Look what a mess they have made over the decades.