Hi, I am writing a compiler in pure Rust, I mentioned it to people
and a lot of them said:
Why did you pick rust? it's non standard, its not good for writing compilers
.. And after googling, turns out they're apparently right! there's no spec for Rust..
I am very curious, why ? Why is there no spec for Rust? Is codebases really enough to be its own "spec" ?
Maybe if reasoning is good, I won't write my own spec for my language either !
Thanks 
A good read on the topic: Do we need a "Rust Standard"? - Mara's Blog
Why does the fact that rust doesn't have a spec make it bad for writing compilers?
In fact, the rust compiler (at least the front-end part) is written in rust.
that's a new one, the similar also flawed argument I've seen before is that Rust not having a standard means you shouldn't be writing additional compilers for Rust since there's no way to decide if you correctly implemented Rust.
IIRC that argument is what this blog post addresses:
AI-written code still tends to be too bug-prone, and bugs in compilers are especially unacceptable.
It would not surprise me if most compilers-in-the-wild are written in Haskell or OCaml. If anything, compiler implementations almost certainly skew toward non-standard languages.
If I were writing a toy compiler, my first instinct would be to reach for a language with first-class sum types and pattern matching. Standardization is much further down the priority list.
Most production compilers are self-hosted, I believe (although not all).
It's not necessary to have any standard or any form of spec to write a compiler, but I think the point is about having several compilers for the same language that agree on the result.
A standard is often not enough; most are unable to precisely define how a compiler should behave in every single detail, and some are embarrassingly too big. Also, standards are decided through committees, which might have advantages, but on the negative side, it implies compromises and politics (which I experienced first-hand), which is a big hindrance to a language's smooth evolution compared to a shared vision.
Rust does have a specification and a process to make it grow (reference document, validation suite, RFC documents, team responsible for the language, ...). I think it's good practice to have a clear specification, even if it doesn't go in to every detail. It's useful to avoid confusion and it's a good support for the users of the language. Extensive validations are vital to ensure the language remains back-compatible when it evolves, too.
I'm not entirely sold on the necessity to have several compilers, either, unless the existing one isn't open-source or is starting to fail.
For now, we don't seem to have any problem on either of those two fronts, so it's fine. And the current model would rather entice me to pick Rust over other choices.
I fully agree for toy projects. But if you make your own language, I think the best approach is to make the compiler in your own language. That way, you require another language's compiler or interpreter only for the bootstrap step, which involves a much smaller code source. It lowers the risk to suffer from compiler incompatibilities from one platform to the next for that initial step, and you're entirely free from that concern after that.
Slightly on a tangent, but I will note that history has shown that standards can turn out to be incomplete, have contradictions and are broken in other ways.
I don't think this is strange at all -- we're humans, and humans make mistakes. With that said, some on the more aggressive side of "a language must have a specification" will try to sell you on the idea that the specification is precisely to avoid such problems.
I would argue it is even worse: most standards are driven by economic and political motives, designed to protect markets and exert influence. They lack technical consistency, as committee members vote on the various components of these standards.
When C became standardized there were already many C compilers - commercial and academic. That is not the case for Rust - Rust has one (dominant) compiler implementation so why standardize? Python is a similar story.
The point of a specification is to provide an arbiter if a language user and a compiler author disagree on the interpretation of a given language construct; both sides of the disagreement have to show how their interpretation aligns with the specification. A complete formal specification (like C aims to have), maintained separately from any compiler, avoids the issue of people thinking in terms of the implementation details of the one and only compiler (e.g. discussing memory semantics in terms of LLVM's freeze and poison, instead of a language-specific model), but even an incomplete specification, like Rust's reference is useful for defining what the language means.
And the reason C, Fortran, COBOL and others have specifications separate to the compilers is that they come from an era where compilers were typically closed source and developed per-system; you needed something so that you could point at the specification and say "your output may be the fewest machine instructions on an IBM 9672, but it's incompatible with the specification" so that someone working primarily on a VAX 6220 using DEC's compiler, but with access to an Iris 4D/20 using SGI's compiler could still produce something that works on your 9672.
Do you think most production compilers start out as self hosting?
I'm not sure what you are asking there. On the face of it is impossible for a compiler to start out as self hosting. How could you compile the sources of your new compiler when there is no executable yet?
On the other hand GCC, a C compiler was originally written in C and no doubt was at first compiled by some other C compiler. As far as I understand the Clang/LLVM compiler is C++ and again must have started out being built by some other C++ compiler.
Seems to me self hosting is something a compiler achieves when it has been developed to the point that it can actually compile itself. Before that it is impossible.
Yeah this thread is convoluted.
The way I understood it..
@ryanavella was pointing out that many compilers are written in non-standard languages, "Haskel, ocmal " (note Haskel does have a standard)
@chrefr stated that most production compilers are self hosted.
I asked if they thought production compilers started out as self hosting.
Summary:
If a compiler is self-hosted then the "rust being non-standard" does not matter. It will only be using rust for the bootstap and after that the "non-standardness" of rust is irrelevant.
I guess I was trying to be succinct. Trying to use very little words to point out that the answer to the original topic/question "Rust being non-standard affects compilers" is "No, it does not matter" without saying "no it does not matter.
Also note: I got the user names @chadsec1 and @chrefr mixed up and thought they were the same poster.
Sorry for the confusion...
Yes. Also, C also has 46 years of public domain existence and multiple existing open-source compilers (including, but not by any means limited to, GCC and CLANG) with all their source code and test suites also open source.
The problems with the "AI will do that faster with better quality" (poster presumably means LLMs and agentic coders built around LLMs since that's what "AI" now means, any other AI is not real AI anymore) are that at their core, LLMs first of all are very good when putting out code that's close to their training set and horrible when working outside the training set -- they can't "reason" by analogy; and second of all, they have no inherent creativity.
OP is talking about implementing a compiler for a new language, the evidence being in this:
Maybe if reasoning is good, I won't write my own spec for my language either !
Making a new language is primarily a creative endeavor. An LLM can slop out something derivative, but it's not going to create something new and different. In 2026 creation of the new and different is still the realm of human endeavor. And despite all the hype there's no sign that it's changing any time soon.