You are comparing one of the easier languages to write a compiler for (C) with one of the hardest (Rust), and that's not due to UB but due to other facets of the languages. I could make up a new language that's equivalent to C in every way except replace all UB with defined behavior and it wouldn't make the naive compiler any different.
Additionally, writing a compiler for a language should really be a thing that happens only a handful of times while executing the code happens trillions of times so I hope we don't sacrifice safety to save compiler authors some work.
I wonder how you will define use after free
Who out there is seriously using a compiler churned out in a weekend? The fact that you can do it doesn't mean anybody seriously would use that.
We're also not really creating architectures anymore. There's RISC-V, and Rust already supports that.
Someone at a chip manufacturer writing something for a brand new chipset, for example. It takes a long time to get stuff shoved into GCC. It's only in recent history has life settled on one or two "big" compilers. There are still plenty of other places where you will find bespoke compilers. Perhaps not commonly, but they do exist (especially in embedded).
( I am not being facetious )
What do you mean, "still cannot self-host?"
You say that like it's a critical failure of the Rust project that they need and are attempting to address rather than a trivia item. Rust is perfectly happy relying on LLVM just like (checks notes) half the other languages in existence.
Libraries like LLVM are precisely what the comment you quote is talking about.
I'm not even sure that's true, anyway, with the cranelift backend. Someone can chime in on whether it's good enough for bootstrapping.
This article about Zig achieving self-hosted status in 2022[0] points out that they gained many advantages at the cost of a lot of time and effort through this process. Incidentally, they decided to self-host while also supporting LLVM because of deficiencies in LLVM (mainly speed and target limitations). This flexibility includes a separate "C" backend to compile Zig to C in order to target for example game consoles that require a specific C compiler be used.
> You say that like it's a critical goal of the Rust project rather than a trivia item.
In my opinion, you are overly minimizing the potential benefits to Rust and the Rust community for Rust to be self-hosted.
Of course, practically, right now it doesn't matter because most people are more than happy to use the already working system.
But it still feels like a trivia item. C compilers written in C exist, but almost nobody actually uses them. They use GCC, Clang, and MSVC, written in C++. Everybody knows that it's possible to self-host C, so the benefit of actually doing so in practice is minimal.
It's obviously possible to write a Rust compiler in Rust end-to-end. Acting like it's a second tier language because actively doing so not a top focus of the community is gatekeep-y and ridiculous.
Here's where I think you are quite a bit off target, personally.
I certainly was not and I don't believe the GP you originally responded to was saying that "Rust is a second tier language due to [lack of self-hosted compiler]", so hopefully we can set that statement aside and ignore it now.
Let's instead focus on your first statement, which is directly related to what GP and I were arguing:
> It's obviously possible to write a Rust compiler in Rust end-to-end.
It is certainly possible but actually doing so is completely non-obvious because the grammar for Rust is much more complicated than C, and Rust has no formal language specification (let alone an international standard).
While Python does not have an international standard, it does have a formal language specification, which is what allows for things like PyPy to exist.
Meanwhile, to truly understand Rust, one must be an expert in C and learn the `rustc` code base.
It seems like, practically, knowing C and being able to write compilers in C is quite useful if you want to make an impact in Rust or maybe try your hand at making some future Rust replacement (hopefully with a language specification that others can follow).
The Rust compiler frontend is written in Rust. It doesn't matter how non-trivial writing a Rust frontend is if you can restrict the problem domain to writing a new backend for the existing compiler frontend.
And you can. As it stands there is the LLVM backend that everyone is familiar with, the GCC backend which is nearing completion, and the Cranelift backend which is written in Rust.
Zig is similar. Yes, they are going to replace LLVM by default, but they're not getting rid of their LLVM backend entirely. The main difference between Rust and Zig here is a matter of defaults, where Rust defaults to using LLVM while Zig will default to their self-hosted compiler.
> Meanwhile, to truly understand Rust, one must be an expert in C and learn the `rustc` code base.
Are you under the impression that the "rustc" codebase is written in C/C++? It is not... It uses LLVM, yes, but it's written in Rust.
> I certainly was not and I don't believe the GP you originally responded to was saying that "Rust is a second tier language due to [lack of self-hosted compiler]", so hopefully we can set that statement aside and ignore it now.
The discussion started with the statement that Rust will never replace unsafe languages without the ability to self-host, and then continued with the statement that "Self Hosting your own compiler traditionally was the "end-game" of making a compile-able language. It's a sort of proof of fitness that the language can literally stand on its own."
I don't think that was a completely unfair reading of these statements. The implication is that Rust is "not a fit language" because it "cannot stand on its own" and therefore "will never replace unsafe languages".
I didn't intend this. The primary gripe I had was the grammar being complicated (and to be fair...not really available in an easy way). That means the places we are most likely see such bare metal shenanigans may not adopt it because they can't draft a XYZ Co. Compiler. This is a semi-common pattern with chip manufacturers.
The conversation diverged after that. Self-hosting is simply a signal that a language is "strong enough to stand on its own". That doesn't mean non-self hosted languages are bad. It just means you still need something else to bootstrap it. In the land of bare metal stuff like this matters.
But C's grammar is so weird that it requires the lexer hack in order to parse (https://en.wikipedia.org/wiki/Lexer_hack). Rust's grammar is simple by comparison. Yes, Rust has more syntax than C, but the syntax that it has is more regular.
In the article I linked, they did not say they were replacing LLVM by default, but they did say it would become the default for DEBUG builds due to the faster speed of compilation, to be clear.
> > Meanwhile, to truly understand Rust, one must be an expert in C and learn the `rustc` code base.
> Are you under the impression that the "rustc" codebase is written in C/C++? It is not... It uses LLVM, yes, but it's written in Rust.
I am not under that impression, but I can see how my phrasing leads to that conclusion.
After reviewing Rust's Bootstrap on Github[0] I can now more precisely state that one's understanding of low-level Rust will be enhanced by knowing C/C++ (for the LLVM portions) as well as Python (for the Rust does not exist on this system downloading of the stage0 binary Cargo and Rust compilers from somewhere else).
> Cranelift backend which is written in Rust
When this happens, it seems like it'll be possible to get the LLVM bits out of the bootstrap process and lead to a fully self-hosted Rust.
So while you may not personally value that, it seems like some people in the Rust community do.
[0] https://github.com/rust-lang/rust/tree/master/src/bootstrap
What do you mean by "when this happens"? GP's point is that this has already happened: the Cranelift backend is feature-complete from the perspective of the language [0], except for inline assembly and unwinding on panic. It was merged into the upstream compiler in 2020 [1], and a compiler built with only the Cranelift backend is perfectly capable of building another compiler. LLVM hasn't been a necessary component of the Rust compiler for quite some time.
Perhaps there's something we're both missing here.
It wasn't my only response because
1) I couldn't remember if it had any significant limitations and couldn't be bothered to check
2) I still objected to the premise
> Acting like it's a second tier language because actively doing so not a top focus of the community is gatekeep-y and ridiculous.
It is probably one of the major reasons we won't see a Rust compiler shipped with an operating system for a very long time. That doesn't make it second tier. However, Rust fans seem to want to stick their head in the sand when their baby is criticized. I am a Rust (language) fan myself. I am just willing to criticize the language. I do not understand why the Rust community has such a volatile response to honest, valid, criticism.
Even most linux distros don't ship with GCC out of the box... much less MacOS and Windows with their respective compilers.
If your standard is "Gentoo and FreeBSD will never ship it out of the box" then I'm going to 100% stand by my statement that this is weird and gatekeep-y.
Especially when the Windows kernel and userspace system libraries both have Rust in them.
https://www.bleepingcomputer.com/news/microsoft/new-windows-...
https://www.thurrott.com/windows/282471/microsoft-is-rewriti...
I can't figure out what this constraint means.
My Windows laptop doesn't seem to have provided a C compiler, so, maybe that's a problem for Windows?
Huh, well I guess I can buy or download a third party compiler, that's easy enough, but then, I can do that for Rust too, so, doesn't seem like a difference.
Meanwhile on this Fedora machine, the Rust compiler came with the OS. So, is this not an operating system? Maybe the stuff it comes with isn't "shipped with" it somehow? And so there's no C compiler "shipped with" this operating system either, although GCC was installed too ? I just don't know what to make of such a criticism.
I think C being a (relatively) very simple is indeed a feature it has - however not so much because you can make a compiler for it easily (not that it isn't a pro, but it isn't that important in practice) but because it means it is easier to learn and easier to write tools for.
Where "most" of course means < 0.1%.
I see you have not met most graduates of Computer Science programs.
> for any given piece of hardware you're more likely to find a random C compiler
This might have been true 10 or 20 years ago, but these days, C has grown so complex that the random C compiler is likely gcc or LLVM with not much else.
> you can churn out a C compiler quickly for almost anything given a spec of the hardware.
Who is doing this? There aren't a lot of new ISAs coming out now, and when they do come out, they usually put effort into porting either LLVM or gcc.
Probably not. Compiler design (lexical+syntactical analysis and code generation) aren't covered by most basic CS bachelor's programs.
Theoretically, a CompSci graduate should be able to reference the necessary materials, ingest the theory and make a basic multipass, non-optimizing C compiler. But I would still be skeptical of a good chunk of recent (as in, lack of experience; not year of graduation) graduates; and would assume that it would take >4 days ("two weekends").
We covered the main chapters but not the advanced topics. If you look at the TOC (https://www.cs.princeton.edu/~appel/modern/toc.html) you can get an idea of the necessary steps:
- Lexing
- Parsing
- Symbol table generation
- Type checking
- IR
- Some static analyses (e.g. liveness)
- Some optimizations (e.g. constant folding)
- Assembly generation
- Register allocation
Me and my 1 group-mate had a working compiler at the end. It took a whole semester, sure I was taking other classes and doing other things, but it certainly took more than 2 weekends worth of work (maybe if you count raw hours, 96 in total...).
The reason is the same though: ISA authors know how to write backends for GCC, which is what they've done for 30 years when they want to get people to use their chip.
I see no world where so-called "unsafe" languages would not be used. Most graduates of Computer Science programs can, perhaps with some trouble, implement a half decent C compiler in a weekend or two. This is not a footnote. This fact alone means that for any given piece of hardware you're more likely to find a random C compiler you can use than anything else. Rust, being the most likely contender to replace it, still cannot self-host and the grammar is exponentially more complicated than C. It is more like C + <whatever> will co-exist peacefully than something like C being replaced (even ignoring the millions of lines of code that already exist). Not for performance reasons but more that you can churn out a C compiler quickly for almost anything given a spec of the hardware.
On topic, I find a desk reference for this is very useful. The CERT C standard is pretty good to thumb through even if you don't adhere to every suggestion.