4 ms·

One of the main GCC rs devs wrote, I quote (https://news.ycombinator.com/item?id=28366445 https://news.ycombinator.com/item?id=28366445): > And if you disagree

One of the main GCC rs devs wrote, I quote (https://news.ycombinator.com/item?id=28366445 https://news.ycombinator.com/item?id=28366445): > 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.

steveklabnik 5y ago
Is that person a gcc-rs dev? I didn't think that was true. 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.
- volta83 5y ago
  I thought that mrustc was a different more portable way of solving the bootstrapping problem, since it compiles Rust to C.
  - steveklabnik 5y ago
    It is different, and is a great project. At the end of the day, with that strategy, you still end up with two compilers, not one single compiler, and some folks are attached to "we use this single compiler to build our entire base system." You also have to then continue the bootstrap chain to get up to current rustc, and I think folks hope that this project will track upstream more closely. 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-Questions https://github.com/Rust-GCC/gccrs/wiki/Frequently-Asked-Ques...
simion314 5y ago
>I've been looking for arguments in favor of gccrs, but was not able to find any. 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.
- volta83 5y ago
  > GCC can be faster in some cases 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.
  - simion314 5y ago
    My bad, thanks for clarifying my confusion
philberty 5y ago
Hello this is Philip the author of these reports and lead for the GCC Rust project. I feel its only fair to point out that the comment you link to the author is not a "main dev for gccrs". I wrote part of the reasons for why I am working on gccrs here: https://news.ycombinator.com/item?id=28368924 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/ https://linuxplumbersconf.org/event/11/contributions/911/
southerntofu 5y ago
>> 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 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.

steveklabnik 5y ago

Is that person a gcc-rs dev? I didn't think that was true. 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.

volta83 5y ago
I thought that mrustc was a different more portable way of solving the bootstrapping problem, since it compiles Rust to C.
- steveklabnik 5y ago
  It is different, and is a great project. At the end of the day, with that strategy, you still end up with two compilers, not one single compiler, and some folks are attached to "we use this single compiler to build our entire base system." You also have to then continue the bootstrap chain to get up to current rustc, and I think folks hope that this project will track upstream more closely. 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-Questions https://github.com/Rust-GCC/gccrs/wiki/Frequently-Asked-Ques...

simion314 5y ago

>I've been looking for arguments in favor of gccrs, but was not able to find any. 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.

volta83 5y ago
> GCC can be faster in some cases 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.
- simion314 5y ago
  My bad, thanks for clarifying my confusion

philberty 5y ago

Hello this is Philip the author of these reports and lead for the GCC Rust project. I feel its only fair to point out that the comment you link to the author is not a "main dev for gccrs". I wrote part of the reasons for why I am working on gccrs here: https://news.ycombinator.com/item?id=28368924 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/ https://linuxplumbersconf.org/event/11/contributions/911/

southerntofu 5y ago

>> 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 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.