To provide a second opinion, you can just open a rustc bug.
In fact, the Rust bug repository has thousands of opinions about thousands of things.
In fact, the Rust bug repository has thousands of opinions about thousands of things.
If that's what you want to do, that's great. If you experiment with new stuff, and it pans out, Rust itself might benefit from that.
Since your goal is implementing something that differs from "Rust", calling it "Rust", is misleading at best, I think is unethical, and given the intent, probably illegal in most of the world since "Rust" is a registered trademark... (IANAL but if you were implementing a frontend for Rust, you could maybe use it, but for an intentionally different language, doesn't sound like it)
> implementing something that differs from "Rust" (...) I think is unethical, and given the intent, probably illegal
I don't understand this statement. One of the contributors said earlier in the thread something that sounds opposed to your interpretation:
> For inconsistencies, we have stated in our FAQ that if GCC rust does not behave the same as rustc. Then it is a bug with GCC rust.
Also, "your code is illegal" is not very much an ethics argument in my book. Digital weaponry like mass-surveillance systems are mostly legal, while harmless ThePirateBay/PopcornTime are illegal.
> And if you disagree with the unilateral decisions of the rustc developers? "Go fork it or write your own"? Yeah that's what we're doing.
I think that the main value of implementing a new Rust frontend, is discovering issues in the Rust spec.
They seem to, however, disagree with some Rust specification issues, and creating an incompatible frontend, not with the intent of making the spec better, but rather just doing something different.
They are calling this different thing "Rust", which I believe is a misleading, and unethical thing to do. (Its as if I make my own language, and call it C++). I think this could also be illegal, since Rust is a trademark of the Rust foundation, which if they don't defend, e.g., in cases like these, makes the trademark irrelevant, e.g., allowing corporations to fork Rust, change the language, and still use the Rust name, cause they did not enforce it here. But as mentioned IANAL, my only point is that you probably want to be very careful in most juristictions in the world about using a trademark in this way.
Others seem to also believe that finding issues in the Rust spec is one of the most valuable things for Rust that can come out of this project. But the main devs haven't been able to point at issues they have filled about it in Rust upstream (as opposed to other projects like have implemented rust frontends before, like mrustc, rust-analyzer, rustc_codegen_gcc, etc. which have found many bugs and filled many issues that have been fixed, submitted patches, etc.).
> I've been reading comments in this thread and i wonder what actual arguments you have against gccrs,
I don't have any arguments against gccrs.
I've been looking for arguments in favor of gccrs, but was not able to find any.
Most arguments mentioned here are incorrect, e.g., gcc-rs being necessary to get rustc access to more targets (incorrect since rustc_codegen_gcc is a thing), gcc-rs resulting in Rust spec improvements (incorrect since they aren't filling any bugs / helping in improving the spec), etc.
If you have an argument in favor of gccrs, please go ahead, I am all ears.
One argument in favor of gcc-rs is related to bootstrapping; right now you need both a previous Rust compiler, as well as a C compiler, to compile Rust. With gcc-rs, you need only gcc. I don't personally think that the bootstrapping situation is onerous, but there are some folks who are looking forward to that.
I also don't think that because it compiles to C it automatically supports all of the platforms gcc does, but I haven't personally investigated that because I don't have any of that exotic hardware.
EDIT: oh yeah and the project itself describes this stuff here https://github.com/Rust-GCC/gccrs/wiki/Frequently-Asked-Ques...
GCC can be faster in some cases and despite other claims there are many platforms that only work with GCC, I was offered in the past a job to work on implementing code optimizations for gcc by a company that had such a embeded board platform - so if Rust wants to run everywhere C runs then the community should try to explain the fanboys that gcc is not a bad thing.
How?
The Rust compiler frontend already can use GCC as a backend.
This project - GCC rs - is a different frontend, which also happens to use GCC as a backend.
The number of targets and performance that both can have is the same.
So the argument "GCC can be faster than GCC" is illogical. You are talking about the same thing.
I wrote part of the reasons for why I am working on gccrs here: https://news.ycombinator.com/item?id=28368924
Overall I feel sad that this effort has been perceived as some kind of attack against Rustc and its community by some. This effort of mine dates back to 2014 and then I was able to get quite alot of rust working in a short time but the language changed far too much to keep up as a solo effort. Since late 2018 I restarted the effort and seriously almost started the track to develop the a gcc backend using libgccjit, it is 100% something i have considered and thought through.
I will be giving a talk on this project at LPC if you wish to hear more about my reasons please listen then https://linuxplumbersconf.org/event/11/contributions/911/
I don't interpret that to mean they intend to insert breaking changes (especially since another comment and their FAQ directly contradicted that idea), but rather that they may explore different ways of implementing things, which i think is a great idea.
> But the main devs haven't been able to point at issues they have filled about it in Rust upstream
Maybe they're busy actually working on something and don't have time to look for specific instances? Or maybe a lot of questions/issues have been documented internally are have not been sufficiently reviewed yet to be opened upstream? There's a lot of room for interpretation here, but i see no reason to assume bad faith on their part.
> If you have an argument in favor of gccrs, please go ahead, I am all ears.
It's been rehearsed over and over, but if you want to build an actual standard, having many eyes/implementations is a good thing. Feedback from people trying different implementation approaches is crucial to making a specification robust.