Certainly quite a bit of rustc could be cannibalized? Surely the parsing, type, and borrow checking stage or perhaps all the way to the m.i.r. could have been shared.
I don’t know what you’re referring to, exactly. I’m pretty sure you’re talking about the post linked above but I don’t remember reading that in it. It’s possible I missed it!
Gotcha, thanks. I wonder about the details here; you could imagine that as either a temporary step until things are further along, or possibly a thing only introduced later in the bootstrap process after you’ve built a stage1 compiler, which you could use to build this without an external rustc.
Philosophically, I think the view is that two independent implementations will give the language more long term stability by helping it avoid the trap of a single implementation, with its bugs, being the definitive version of the language.
On the practical level, rustc is written in rust and self-hosting, so reusing code from it in gcc would mean that you needed a rust compiler as well as a c compiler to compile gcc.
I am not a licensing lawyer, but the license for rustc (and its standard library, and a great many infrastructural crates in the ecosystem) is dual MIT + Apache 2, which was explicitly chosen so that it would be compatible with both GPL v2 and GPL v3.
It is a problem when trying to bring code from an existing codebase that has no such copyright assignment clauses. Bringing the rustc frontend code into gcc would be unlikely because getting a copyright release to GNU from everyone that contributed to rustc would be unlikely.
Do you know whether the GCC Ada, Fortran, Go, D and Java frontends also assign full copyright to the FSF? Are the copyright of all dependencies likewise assigned to them?
You can always take GNU licensed code and build what you want as long as you comply with the license, but to be part of the GCC release that copyright assignment requirement exists.
> On the practical level, rustc is written in rust and self-hosting, so reusing code from it in gcc would mean that you needed a rust compiler as well as a c compiler to compile gcc.
I see, they want a full Rust implementation written in C++ rather than in Rust?
There is a different project that grafts the existing rustc frontend to the gcc backend: rustc_codegen_gcc. The existence of both projects is currently very contentious, as there are concerns about duplicated effort and possible fragmentation of the community. Some of the goals, like the ability to target more architectures, are equally supported by both projects, but for other goals (mostly more organizational and less technical, to my ears) they're pretty different.
I always thought Rust and other PLs generate LLVM IR and leave the optimizations to LLVM while GCC has something more complex to deal with, doesnt it make things much complicated ?
Others claim mrustc is the second, but has anyone actually tried to use it? the readme does not inspire too much confidence, and looks to (currently) be a C transpiler:
"mrustc's primary goal is bootstrapping rustc, and as such it tends to assume that the code it's compiling is valid (and any errors in the generated code are mrustc bugs). Code generation is done by emitting a high-level assembly (currently very ugly C, but LLVM/cretone/GIMPLE/... could work) and getting an external tool (i.e. gcc) to do the heavy-lifting of optimising and machine code generation."
At least it can be used to bootstrap the actual rust compiler. It's a bit crazy to me how popular this language appears to be, but doesn't have a proper second compiler yet.
It is impressive work but I still think that using libgccjit as a backend is the right way forward since once it has been integrated it should be much less work to maintain.
I thought it was pretty interesting, though based on the reddit comments (https://reddit.com/r/rust/comments/noby1t/the_simpler_altern...) the main concern seems to be if a second Rust is implemented without a spec, it could lead to subtle incompatibilities?
It is also very antagonistic. It's not an evenhanded exploration of the tradeoffs of two approaches, it's pretty much just talking trash. Disappointing.
I disagree that it's "just talking trash". Sure, I agree the tone of the article is overly harsh on the gcc-rs project, but it does raise some solid points that, for the stated goals of the project, the approach appear suboptimal.
Every time gcc-rs comes up, the discussion always devolves to a "but there's rustc_codegen_gcc, why bother rewriting the language in C++", and I have yet to see a compelling argument why GCC-RS is indeed a superior solution, despite the many downsides.
I think the answer is that it isn't necessarily a better solution, but the people with the necessary knowledge to make a gcc frontend or backend happen tend to be more familiar with C++, and so GCC-rs is actually the path of least resistance?
As I said below, one example of a significant advantage is not needing any sort of Rust compiler. It’s not one to me but it is to some.
I am not saying that the project is above criticism, or that there are no downsides to its approach, but this article isn’t interested in dispassionate engineering analysis.
Yep, the author was very clear from the beginning that he didn't like the idea of gcc-rs and wasn't really willing to compare both approaches on the same level.
I personally think that's a good thing that multiple approaches to the problem exist and in the end, the better one will hopefully be adopted by the community.
The Rust people don't believe in specs. (I guess the reasoning is that if you ignore the problem is just goes away?)
Anyways, their loss, not mine.
Until Rust gets a real standard it will forever be a toy language. For many (most?) people in the systems programming sphere (including me) the lack of a standard is the #1 impediment to using Rust.
The Rust people firmly believe in specs and are working on one (most of the activity is currently in Ferrocene). On the other hand, they fully appreciate that writing a good spec is very hard and takes time, while a bad spec can do lots of damage to the ecosystem.
The head of that “shady GmbH” is on the Core team, and is one of the Core Team’s board representatives for the Foundation.
Regardless, it is a misunderstanding of Rust’s governance to suggest that the Foundation would lead a standardization effort; the Language Team, part of the Project, not the Foundation, is in charge of the definition of the language.
The Foundation is a recent development. The efforts by Ferrous to make Rust more suitable for safety-critical work predate the creation of the Foundation by quite some time; there was quite a bit of work done under the "sealed Rust" banner before that was rebranded as Ferrocene.
Good specs don't emerge from thin air (though I suspect that many bad specs emerge through spontaneous generation), and the people who work on them deserve to be funded. While I'm not claiming the process the Rust community has is perfect, it is explicitly designed to be sustainable, and I think it's right to be proud of the collaboration between different companies, large and small, and also academia; Ralf Jung's work in particular is foundational and he well earned his recent PhD for it.
No offense, but your explanation reads like something a politician would produce when trying to explain why that airport missed deadlines while over budget and all that remains in abundance is a bunch of shell companies.
I've been expecting some kind of announcement from the lang team saying something about how the third party Ferrocene / sealed Rust project fits in with the official project and its documentation.
Do you know if there's been one that I've missed?
Some of the work involved in producing a specification will involve making decisions about corner cases which aren't currently nailed down. What I'm wondering is whether the Ferrocene people are going to be effectively authorised to make those decisions.
There is, to my mind, a significant difference between a blog post from the lang team and a blog post from Ferrous systems which thanks the lang team for their feedback.
The decision to implement an entirely new frontend is interesting, although regardless of that our experience with D is that having access to the GCC backend/s is very good for the language.
I just hope they would add someway to hide warnings from dependent libraries during compilation. It's a really annoying part of rust compilation when developing prototypes.
59 comments
[ 5.5 ms ] story [ 117 ms ] threadCertainly quite a bit of rustc could be cannibalized? Surely the parsing, type, and borrow checking stage or perhaps all the way to the m.i.r. could have been shared.
There is another project pursuing that approach. Both are valid strategies with different pros and cons.
On the practical level, rustc is written in rust and self-hosting, so reusing code from it in gcc would mean that you needed a rust compiler as well as a c compiler to compile gcc.
Also, rustc and gcc have incompatible licenses.
I see, they want a full Rust implementation written in C++ rather than in Rust?
The official compiler has an LLVM backend. GNU also wants to provide rust, and is adding a rust front to their gcc compiler.
These monthly reports document the progress until the gcc compiler reaches feature parity with the LLVM-based compiler
* Compiler docs: https://rustc-dev-guide.rust-lang.org/mir/optimizations.html
* Working Group: https://rust-lang.github.io/compiler-team/working-groups/mir...
* Example of one such optimization, "constant propagation" https://blog.rust-lang.org/inside-rust/2019/12/02/const-prop...
GCC has an IR called GIMPLE that’s fine.
What is the second rust compiler?
[0](https://github.com/thepowersgang/mrustc/)
"mrustc's primary goal is bootstrapping rustc, and as such it tends to assume that the code it's compiling is valid (and any errors in the generated code are mrustc bugs). Code generation is done by emitting a high-level assembly (currently very ugly C, but LLVM/cretone/GIMPLE/... could work) and getting an external tool (i.e. gcc) to do the heavy-lifting of optimising and machine code generation."
At least it can be used to bootstrap the actual rust compiler. It's a bit crazy to me how popular this language appears to be, but doesn't have a proper second compiler yet.
https://github.com/antoyo/rustc_codegen_gcc
I thought it was pretty interesting, though based on the reddit comments (https://reddit.com/r/rust/comments/noby1t/the_simpler_altern...) the main concern seems to be if a second Rust is implemented without a spec, it could lead to subtle incompatibilities?
Every time gcc-rs comes up, the discussion always devolves to a "but there's rustc_codegen_gcc, why bother rewriting the language in C++", and I have yet to see a compelling argument why GCC-RS is indeed a superior solution, despite the many downsides.
I think the answer is that it isn't necessarily a better solution, but the people with the necessary knowledge to make a gcc frontend or backend happen tend to be more familiar with C++, and so GCC-rs is actually the path of least resistance?
I am not saying that the project is above criticism, or that there are no downsides to its approach, but this article isn’t interested in dispassionate engineering analysis.
I personally think that's a good thing that multiple approaches to the problem exist and in the end, the better one will hopefully be adopted by the community.
Or both. I mean, is there anything wrong with having multiple implementations of a language?
They may each be better for different reasons.
Anyways, their loss, not mine.
Until Rust gets a real standard it will forever be a toy language. For many (most?) people in the systems programming sphere (including me) the lack of a standard is the #1 impediment to using Rust.
But looking at https://foundation.rust-lang.org/ I see a content-devoid site that holds nothing but passive-aggressive demands for money.
That's about as far away from "firmly believing" as possible given the circumstance.
Regardless, it is a misunderstanding of Rust’s governance to suggest that the Foundation would lead a standardization effort; the Language Team, part of the Project, not the Foundation, is in charge of the definition of the language.
Good specs don't emerge from thin air (though I suspect that many bad specs emerge through spontaneous generation), and the people who work on them deserve to be funded. While I'm not claiming the process the Rust community has is perfect, it is explicitly designed to be sustainable, and I think it's right to be proud of the collaboration between different companies, large and small, and also academia; Ralf Jung's work in particular is foundational and he well earned his recent PhD for it.
It's a relatively new project, and will take time to catch up to existing languages in many areas.
Neither C or C++ started with a standard.
Do you know if there's been one that I've missed?
Some of the work involved in producing a specification will involve making decisions about corner cases which aren't currently nailed down. What I'm wondering is whether the Ferrocene people are going to be effectively authorised to make those decisions.
https://ferrous-systems.com/blog/sealed-rust-the-pitch/#fund...
And clashes with the entire development of the Rust language so far.
https://github.com/rust-lang/rust/issues/33014