16 ms·

Progress toward a GCC-based Rust compiler

350 points by askl 3y ago

vlovich123 3y ago
The claims in the article feel kinda weak as to the motivation. > Cohen's EuroRust talk highlighted that one of the major reasons gccrs is being developed is to be able to take advantage of GCC's security plugins. There is a wide range of existing GCC plugins that can aid in debugging, static analysis, or hardening; these work on the GCC intermediate representation > One more reason for gccrs to exist is Rust for Linux, the initiative to add Rust support to the Linux kernel. Cohen said the Linux kernel is a key motivator for the project because there are a lot of kernel people who would prefer the kernel to be compiled only by the GNU toolchain. That explains why you’d want GCC as the backend but not why you need a duplicate front end. I think it’s a bad idea to have multiple front ends and Rust should learn from the mistakes of C++ which even with a standards body has to deal with a mess of switches, differing levels of language support for each compiler making cross-platform development harder, platform-specific language bugs etc etc. > A lot of care is being put into gccrs not becoming a "superset" of Rust, as Cohen put it. The project wants to make sure that it does not create a special "GNU Rust" language, but is trying instead to replicate the output of rustc — bugs, quirks, and all. Both the Rust and GCC test suites are being used to accomplish this. In other words, I’d love gccrs folks to explain why their approach is a better one than rustc_codegen_gcc considering the latter is able to achieve this with far less effort and risk.
- gkbrk 3y ago
  > Rust should learn from the mistakes of C++ Rust should learn from the mistakes of C++ and C, which are one of the longest lasting, biggest impact, widely deployed languages of all time? It's confusing when people think language standards are bad, and instead of saying this code is C99 or C++11, they like saying "this code works with the Rustc binary / source code with the SHA256 hash e49d560cd008344edf745b8052ef714b07595808898c835f17f962a10012f964".
  - pornel 3y ago
    C and C++ are widely used despite their language, compiler, and build system fragmentation. Each platform/compiler combo needs ifdefs and workarounds that have been done for so long they’re considered a normal thing (or people say MSVC and others don’t count, and C is just GCC+POSIX). There’s value in multiple implementations ensuring code isn’t bug-compatible, but at the same time in C and C++ there’s plenty of unnecessary differences and unspecified details due to historical reasons, and the narrow scope of their specs.
    - gkbrk 3y ago
      Yes, that's how the story goes. Languages with specs are widely deployed despite being fragmented and bad, not because people find value in multiple implementations. Must be a coincidence that C, C++, Javascript and C# and Java all fall under this umbrella.
      - legobmw99 3y ago
        Java and C# seem to have actually gotten the idea of multiple implementations correct, in the sense that I have never needed to worry about the specific runtime being used as long as I get my language version correct. I have basically never seen a C/C++ program of more than a few hundred lines that doesn’t include something like #ifdef WIN32 …
        bluGill 3y ago
        Is there more than one Java implementation that is usable? All I can find are obsolete products that never got very far.
        gkbrk 3y ago
        Here are a few Java implementations that I've used recently. - My Android phone - OpenJDK on my laptop - leJOS for a university robotics course to run on Lego robots - Smart cards, I have a couple in my wallet Perhaps I'd call the Lego robot stuff obsolete, certainly not the Android userspace or smart cards though.
- bryanlarsen 3y ago
  > Rust should learn from the mistakes of C++ They are. You quoted them doing it, the care taken not to become a superset. The problem with C/C++ stemmed from compiler vendors competing with each other to be "better" than their peers. Multiple front ends of an implementation of a language usually shakes out a bunch of bugs and misimplementations. That's the primary benefit of having multiple front ends IMO.
  - delfinom 3y ago
    >The problem with C/C++ stemmed from compiler vendors competing with each other to be "better" than their peers. Yea but this is Linux and OSS. NIHisms are fucking rampant everywhere. I give it a year before gccrs announces a new "gnurs" mode with language extensions.
    - saghm 3y ago
      I'd be surprised about this mostly because I can't imagine anyone using gcc-specific Rust extensions. Not only does rustc have an extraordinary amount of traction by being basically the only choice up until this point, Rust doesn't really have the reputation of moving slowly to adopt new features; if anything, there's been as much skepticism about new features added over the years as excitement. I can honestly imagine more people adopting a Rust implementation with a commitment _not_ to add new features that are added to rustc than one that adds its own separate features. Even as someone who probably will never use gccrs, I think having more than one implementation of Rust is a good thing for the language (for all the usual reasons that get cited). In the long term, I'd love for Rust to eventually to be able to specify its semantics in a way that isn't tied to rustc, which is a moving target and gets murky when you consider implementation-specific bugs.
      - nequo 3y ago
        > Rust doesn't really have the reputation of moving slowly to adopt new features There are some exceptions to this. Although there are possibly good reasons for such features moving slowly, a competing compiler could popularize them before they are stabilized in rustc. One example is generators[1] but there's a longer list in The Unstable Book.[2] [1] https://github.com/rust-lang/rust/issues/43122 https://github.com/rust-lang/rust/issues/43122 [2] https://doc.rust-lang.org/stable/unstable-book/language-features/generators.html https://doc.rust-lang.org/stable/unstable-book/language-feat...
- neuromanser 3y ago
  > I think it’s a bad idea to have multiple front ends and Rust should learn from the mistakes of C++ which even with a standards body has to deal with a mess of switches I do not disagree, yet at the same time, having the same set of switches across different languages is nice, too.
- ndiddy 3y ago
  Having another Rust implementation allows for an "audit" to help validate the Rust spec and get rid of any unspecified behavior. It would also give users options. If I hit a compiler bug in MSVC, I can file a report, switch to GCC and keep working on my project until the bug is fixed. With Rust, that's not currently possible.
  - VBprogrammer 3y ago
    I don't have a lot of experience in C or C++ but I wonder if this ever works in practice for a non-trivial codebase? I'd be really surprised if, without diligently committing to maintaining compatibility with the two compilers, it was easy to up sticks and move between them.
    - cozzyd 3y ago
      It's pretty easy to move between gcc/clang/icc for most codebases. Though there are some useful features still that are gcc only. (And probably some that are clang only, though I pretty much only use gcc...)
    - logicchains 3y ago
      >I'd be really surprised if, without diligently committing to maintaining compatibility with the two compilers, it was easy to up sticks and move between them Many places deliberately compile with multiple compilers as part of the build/test pipeline, to benefit from more compiler warnings, diagnostics etc.
    - jupp0r 3y ago
      There are lots of libraries that need to compile on a variety of platforms (ie different versions of LLVM for Android and MacOS, MSVC for Windows and GCC for some embedded targets not well supported by LLVM).
    - ska 3y ago
      It works but you have to keep it at least "semi-active". Some shops have CI services setup to cross compile etc. already. Mainly I've seen this not as a tool to maintain a "backup" but as a way to shake out bugs and keep non-portable stuff from creeping into the codebase. You could probably do most of it with conservative linting and some in-house knowledge of portability issues, non-standard compiler extensions, etc. It's typically a lot easier to do this for different compiler, same target, than different targets.
- rhdunn 3y ago
  So by that definition you would only want one web browser as there are currently multiple HTML+CSS+JavaScript "front ends". In which case, you end up with a Chrome monopoly where Google gets to decide what the web looks like!
  - mtrower 3y ago
    A goodly number of people appear to want just that. I don’t agree, mind you, but someone reading your comment with this mindset will probably be reinforced rather than swayed.
  - gpm 3y ago
    A monopoly where a party with conflicting interests to the users being the sole arbiter is obviously problematic. A monopoly which is run by a group of individuals that do not have obvious conflicts of interest, and work for different organizations to mitigate the chance of non-obvious conflicts of interest, is far more interesting. Rust has the latter. It's not plausible that that will that a similar entity will take over the HTML/CSS/JS space, because of the amount of money competing with users interests in the space due to things like advertising, the desire to invade users privacy, etc. Still, if somehow we could magic up this monopolizing organization without conflicts of interest that would be far superior to the current state of affairs...
    - edelsohn 3y ago
      The Rust community is not perfect. Neither is the LLVM community nor the GCC community, not any Open Source community. Consider the recent drama / growing pains that has occurred within the Rust community. Everyone has biases and conflicts of interest. Anyone who doesn't recognize the benefit of alternatives will learn the hard way. The Rust community rationalization that they don't need / want alternatives for "reason" is self-serving and all about control. I don't care if someone is the BDFL, they aren't right 100% of the time and not always doing things for altruistic reasons. The Rust community has imbued the leadership with some godlike omniscience and altruism because it makes them feel good, not because it's sound policy.
- bayindirh 3y ago
  The main motivation is having a GPL licensed, independently developed complete Rust compiler which is not dependent on LLVM.
  - cozzyd 3y ago
    Yes this is important. Otherwise in the future you'll see proprietary rust distributions for various devices or with specific features
    - GrumpySloth 3y ago
      C++ and Java, which have many implementations, also have proprietary distributions, see Apple’s fork of Clang, Microsoft’s MSVC, Azul VM, Jamaica VM, ... And some of them are pretty nice. Life is good.
      - bayindirh 3y ago
        When you don’t have a GPL implementation, the only good implementation might be closed source fork of the LLVM version, effectively forking Rust into Rust and Rustium. Will life be good then?
        sunshowers 3y ago
        This seems like an astoundingly remote possibility.
        bayindirh 3y ago
        Given the companies backing LLVM and the surrounding ecosystem, I think it’s an astounding possibility. Companies love permissive licenses for a reason.
    - swsieber 3y ago
      You'll still see those though? A fully GPL implementation doesn't prevent the current implementation from being used in a proprietary rust distribution... unless of course the GPL implementation were to fork from the current implementation... which is the main thing people against the GPL implementation are worried about
- mhh__ 3y ago
  There are arguments for and against but for colour: D in GCC uses a shared frontend, which means it's not hard to maintain the frontend aspects — but that also means the frontend is a monoculture which is not very healthy at the moment. If someone will pay you to do it I would do a new frontend — it's surprisingly little work to get something you can bootstrap with.
  - p0nce 3y ago
    Having maintained both C++ and D for different compilers, it's way easier to do it in D since the front-end features are the same (modulo builtins) and the stdlib is 99% the same.
- edelsohn 3y ago
  Based on that logic, why did the LLVM community develop Clang, Clang++, libc++, etc. instead of continuing with DragonEgg? There already were GCC, G++, libstdc++ , as well as EDG C++ front-end. GCC, Clang, MSVC, and other compilers complement each other, serve different purposes, and serve different markets. They also ensure that the language is robust and conforms to a specification, not whatever quirks a single implementation happens to provide. And multiple implementations avoids the dangers of relying on a single implementation, which could have future problems with security, governance, etc. The GNU Toolchain Project, the LLVM Project, the Rust project all have experienced issues and it's good to not rely on a single point of failure. Redundancy and anti-fragility is your friend.
  - vlovich123 3y ago
    LLVM saw growth for a number of reasons, but nothing to do because it was actually beneficial for the C++ ecosystem: * A C++ codebase. At the time GCC was written in C which slowed development (it’s now a C++ codebase adopting the lessons LLVM provided) * It had a friendlier license than GCC which switched to GPLv3 and thus Google & Apple moved their compiler teams to work on LLVM over time. * Libc++ is a combination of friendlier license + avoiding the hot garbage that was (maybe still is?) libstdc++ (e.g. there were incompatible design decisions in libstdc++ that inhibited implementing the C++ spec like SSO). There were also build time improvements if I recall correctly. * LLVM provided a fresher architecture which made it more convenient as a research platform (indeed most compiler academics target LLVM rather than GCC for new research ideas). Basically, the reason LLVM was invested in instead of DragonEgg was a mixture of license & the GCC community being quite difficult to work with causing huge amounts of investments by industry and academia into LLVM. Once those projects took off, even after GCC fixed their community issues they still had the license problem and the LLVM community was strongly independent. Compilers don’t typically generate security issues so that’s not a problem. There are questions of governance but due to the permissive license that Rust uses governance problems can be rectified by forking without building a new compiler from the ground up (e.g. what happened with NodeJS until the governance issues were resolved and the fork reabsorbed). It’s funny you mention the different C++ compilers consider that Clang is well on its way of becoming the dominant compiler. It’s already targeting to be a full drop-in replacement for MSVC and it’s fully capable of replacing GCC on Linux unless you’re on a rarer platform where GCC has a bit richer history in the embedded space). I think over the long term GCC is likely to die and it’s entirely possible that MSVC will abandon their in-house and instead use clang (same as they did abandoning IE & adopting Blink). It will be interesting to see if ICC starts porting their optimizations to LLVM and making them freely available - I can’t imagine ICC licenses really bring in enough money to justify things.
- matheusmoreira 3y ago
  > The project wants to make sure that it does not create a special "GNU Rust" language That's disappointing. GNU's extensions to the C language are extremely valuable features. I'd like to see what sort of contributions they would make.
  - awestroke 3y ago
    Hah
  - Kwpolska 3y ago
    They may be valuable C features, but Rust isn't designed by committee, and if it's missing some useful feature, you could probably convince the Rust team to include it, without having to invent GCC-specific extensions.
- cbmuser 3y ago
  I don’t understand why this question is kept being asked. Is Rust holy in some sense that’s it’s not allowed to rewrite the frontend? It’s still a PITA to bootstrap Rust on a new architecture and there is also no working Rust compiler for architectures not supported by LLVM. I know that there is codegen_rust_gcc but that one has the same bootstrap problems as the original Rust compiler and also requires architecture support to be landed in various Rust part which Rust maintainers have beem hesitant about (been there, done that). So, I am absolutely glad that there will be an out of the box usable Rust compiler in the near future which will finally allow me to build rustified libraries again on architectures such as alpha without much pain.
  - fl0ki 3y ago
    With GCC itself being written in C++, what is better about GCC's own bootstrap story except that it's been part of operating system distributions for longer? I am not aware of anyone using clang or MSVC to bootstrap GCC on Linux distributions for example, they use GCC's own lineage traceable back to C. It has the same bootstrap problem, and it isn't a problem in practice because vendors distribute binary toolchains. Even BSD and Gentoo start out with an initial set of binaries before rebuilding the world. The architecture support angle is a better one for why a GCC backend is helpful, but that will also be addressed by rustc_codegen_gcc so it isn't a relevant argument here. And by the looks of it, that will be a usable solution much sooner than gccrs, and it will remain usable with a much lower long-term resource commitment. This is an argument more in favor of rustc_codegen_gcc than gccrs. The strongest argument I can see about bootstrapping issues here is that Rust moves much faster and Rust's own compiler code requires a relatively recent Rust version, so in the extremely specific circumstance where binaries are not available and cross compilation is also not possible, bootstrapping will take more steps than it would for a gccrs frontend limited by C++'s slower rate of evolution. I don't see this being anywhere near as much of a problem as gccrs trying to catch up to & keep pace with Rust's frontend evolution. The former we can solve with the same build farms and cross compiles we need anyway, the latter requires continuous ongoing human effort with all of the disadvantages of C++.
rayiner 3y ago
I’m surprised at the negative reaction to GCC-RS. If a language doesn’t have multiple implementations, it’s a pretty sad excuse for a language.
- sylware 3y ago
  The problem is on the long run: syntax stability, avoiding feature creeps with extensions/attributes, like we actually have with C (c++ is beyond saving due to its absurd and grotesque complexity). Without that, you won't have real-life alternatives.
  - ajross 3y ago
    > avoiding feature creeps with extensions/attributes, That seems like a purely semantic argument? Rust is adding features extremely rapidly! You're just saying it's "development" if it's done by one entity but "creep" if it's done by someone else?
- PoignardAzur 3y ago
  > I’m surprised at the negative reaction to GCC-RS. If a language doesn’t have multiple implementations, it’s a pretty sad excuse for a language. That used to be the common wisdom (especially because of C/C++), but it's a lot more debated these days. The consensus in the Rust community is that the current situation (one canonical-by-definition compiler, lots of documentation, a minimal spec for safety-critical industries, and specs for some modular sub-parts) get most of the advantages of multiple implementations without the drawbacks.
  - not2b 3y ago
    I think that the people who are debating it are missing some things. It often happens that only when a second implementation is attempted, unspecified holes in the documentation are exposed and standards are tightened up. Any differences in the two compilers will either mean that there's a bug in the new implementation (most likely), a bug or unclear issue in the documentation, or a bug in the mature implementation (it happens). And no, the official compiler isn't canonical by definition. If it were, it would mean it has no bugs, and if there's a crash or a wrong result that's what the language is supposed to do.
sylware 3y ago
[flagged]
- arp242 3y ago
  Rust already uses C++ in LLVM so nothing changes there. This must be the umpteenth rant on C++ I've seen from you. This does not contribute anything. Please stop.
  - flooow 3y ago
    The underlying point is correct though. Rust developers cannot be expected to maintain a C++ implementation of their language. Half of them learned Rust to get away from C++, the other half never knew C++ in the first place.
    - gpm 3y ago
      For what it's worth, rust developers are already maintaining an independent C++ implementation of the language: https://github.com/thepowersgang/mrustc https://github.com/thepowersgang/mrustc
      - sylware 3y ago
        [flagged]
        ColonelPhantom 3y ago
        Well, rustc is the canonical Rust compiler. mrustc mostly just exists to aid in bootstrapping and really not much else.
        sylware 3y ago
        I make the difference between canonical and bootstrapping. When I said canonical, I meant the reference one which will actually be used to compile "normal" rust code. I guess this reference canonical rust compiler has the decency to be fully written using rust itself, am I wrong? (I was told it is, then if it is not, I was lied to)
charcircuit 3y ago
>the Linux kernel is a key motivator for the project because there are a lot of kernel people who would prefer the kernel to be compiled only by the GNU toolchain. Linux can already be compiled with clang if you want an all LLVM based toolchain. The duplicate effort of developing and maintaining this does not sound worth it to have GNU "purity."
- mtrower 3y ago
  I think you may be misunderstanding here. They aren’t trying to keep the kennel GNU exclusive —— they merely want the option for a pre GNU toolchain.
  - charcircuit 3y ago
    What is a pre GNU toolchain?
    - ColonelPhantom 3y ago
      They presumably mean "pure GNU toolchain", not "pre".
- edelsohn 3y ago
  It's not about purity, it's about options. The ClangBuiltLinux community advocated that Linux should not be dependent upon a single compiler. But when Rust came along, suddenly many of the same people suddently decided that a single compiler was okay.
  - rightbyte 3y ago
    I always understood it as that they want control over "best practice". A GNU compiler could add convenient feutures that the hardcore Rust users don't want other Rust users to be able to have. Like ideological purity.
thesuperbigfrog 3y ago
Rust needs a language standard: https://blog.m-ou.se/rust-standard/ https://blog.m-ou.se/rust-standard/ https://rust-lang.github.io/rfcs/3355-rust-spec.html https://rust-lang.github.io/rfcs/3355-rust-spec.html https://github.com/rust-lang/rfcs/pull/3355 https://github.com/rust-lang/rfcs/pull/3355 There are many organizations and industries that will not adopt Rust until it has a standard. C, C++, C#, and even JavaScript (ECMAScript) have language standards. Why shouldn't Rust have one too? C: https://www.iso.org/standard/74528.html https://www.iso.org/standard/74528.html C++: https://isocpp.org/std/the-standard https://isocpp.org/std/the-standard C#: https://learn.microsoft.com/en-us/dotnet/csharp/language-reference/language-specification/introduction https://learn.microsoft.com/en-us/dotnet/csharp/language-ref... JavaScript / ECMAScript: https://ecma-international.org/publications-and-standards/standards/ecma-262/ https://ecma-international.org/publications-and-standards/st...
- ajross 3y ago
  Yeah. The culture crash here is shocking dissonant. The people you'd normally expect to be the biggest voices for documentation robustness are... ... suddenly finding themselves in the "Actually, language standards are bad" camp, all because of a tribal opposition to the FSF? Write the standard. Then argue that gccrust doesn't do it right. Don't refuse to document the language just to hamstring a competitor. Also, please start with the borrow checker semantics. I don't think I've ever met anyone who could explain exactly what the rules are regarding what it can/can't prove.
  - estebank 3y ago
    There's been active work on a Rust specification for a while now. It'll happen. https://blog.rust-lang.org/inside-rust/2023/11/15/spec-vision.html https://blog.rust-lang.org/inside-rust/2023/11/15/spec-visio...
  - Rusky 3y ago
    What culture crash? The Rust project has a language reference, is working on expanding it into a more formal spec, and there are efforts like Ferrocene's to qualify the existing compiler for use in safety critical environments. The argument is not that language standards are bad, it's that a C++-like ISO standard is unnecessary (when the quality documentation can exist in another form) and C++-like implementation fragmentation is bad. (Have you read the NLL RFC? The Polonius work?)
johnklos 3y ago
So we'll finally see Rust support for all the architectures that gcc supports that LLVM doesn't, like Alpha, SuperH and VAX, for starters. That'll be nice!
- segfaultbuserr 3y ago
  Can't wait to see some PDP-11 machine code from Rust (the last time I checked, freestanding C compiling still worked on GCC).
- Asraelite 3y ago
  I would assume it also means additional configuration options for already-supported architectures. For example, I recently discovered that with RISC-V, GCC supports the RV32E target but LLVM doesn't.
  - monocasa 3y ago
    Are you sure about that? I was pretty sure that llvm has supported RV32E for years now. https://reviews.llvm.org/D70401?id=395048 https://reviews.llvm.org/D70401?id=395048
    - Asraelite 3y ago
      Oh, last time I checked clang didn't support it. In any case, there are a lot of other compiler flags that are exclusive to gcc.
- crotchfire 3y ago
  And mips64, which rustc recently dumped support for after their attempt to extort funding/resources from Loongson failed: https://github.com/rust-lang/compiler-team/issues/648 https://github.com/rust-lang/compiler-team/issues/648 This is the biggest problem with the LLVM mentality: they use architecture support as a means to extract support (i.e. salaried dev positions) from hardware companies. GNU may have annoyingly-higher standards for merging changes, but once it's in there and supported they will keep it for the long haul. It's like buying vs renting. It takes a lot more dev hours to get support into GCC, but once it's there, it stays there.
gumby 3y ago
> A lot of care is being put into gccrs not becoming a "superset" of Rust, as Cohen put it. The project wants to make sure that it does not create a special "GNU Rust" language, but is trying instead to replicate the output of rustc — bugs, quirks, and all. In my experience, the part in italics is a significant mistake. Rust does not have a specification; there is a reference but it is explicitly not normative. A language udocumented except for a single reference implementation (as is tpday's fashion) have a long term weakness. What is the motivation for slavishly trying to maintain compatibility with the bugs and accidental quirks of another implementation? To guarantee that existing code will work in both implementations, which sounds sensible. And it is a sensible goal, but it does so at enormous cost by enforcing it in the wrong place. The problem is that sometimes decisions are wrong, and sometimes bugs are written. But when you promise that all implementations will be bug compatible as part of compatibility you are also signing up to fossilize these bugs whether you want to or not. A good example of someone who embraced this (to their credit!) is Microsoft: they spend a lot of person-power making sure that old programs continue to run while trying to fix security and reliability bugs. Rust need not and should not sign up for this burden so early in its lifespan. They should learn from history. If they want the language to evolve they should embrace QA and QC. Famously "you cannot test quality into a product". You need QA: architecture, design, design and code reviews, etc to ensure that things will work properly and when not, that "failure heads in the appropriate direction". Then later in the development cycle QC (test cases) tries to see if you missed. This doesn't just apply to product development -- it applies to language development especially. The strong standards (e.g. ComonLisp, C++, FORTRAN) embraced this belief. The weak, de facto ones (Most notably Python, but plenty of others) can still become popular, but change is difficult. Look at how long the Python 2->3 transition took, and how few python implementations there are.
- nicoburns 3y ago
  If they find a big then presumably they’ll report it upstream and both implementations can be changed.
  - gumby 3y ago
    The point is that fixing that bug may break existing, running code that depends on it.
mkesper 3y ago
Thanks for posting the lwn.net link, reminded me of renewing my subscription!
- sophacles 3y ago
  It's a good subscription to have. I've gotten far more value from my LWN subscription than I spent, and recommend everyone that does lowish level work get one.
dj_gitmo 3y ago
> Cohen listed a few things that gccrs is already useful for. According to him, the Sega Dreamcast homebrew community uses gccrs to create new games for the Dreamcast gaming console, and GCC plugins can already be used to perform static analysis on unsafe Rust code. The Dreamcast community's interest stems from the fact that rustc's LLVM backend does not support the Hitachi SH-4 architecture of the console, whereas GCC does; even in its incomplete state, gccrs is helpful for this embedded use case. This is delightful.
- habitue 3y ago
  This is a little misleading. You don't need to have a gcc frontend for this, just a gcc backend
_8j50 3y ago
Late in the thread but this may not be a good thing. I already can't use rustc or golang from distros because they can't keep up with the latest versions of these languages that are being released evey few months. I have a system now where much to my shock I am getting rid of gcc because it is not needed but keeping upstream golang and rust for updating existing software, which is by the way a nightmare when I updated golang few months back for a CVE and had like four places where the go based apps stored their own go environment.

350 points by askl 3y ago

The claims in the article feel kinda weak as to the motivation. > Cohen's EuroRust talk highlighted that one of the major reasons gccrs is being developed is to be able to take advantage of GCC's security plugins. There is a wide range of existing GCC plugins that can aid in debugging, static analysis, or hardening; these work on the GCC intermediate representation > One more reason for gccrs to exist is Rust for Linux, the initiative to add Rust support to the Linux kernel. Cohen said the Linux kernel is a key motivator for the project because there are a lot of kernel people who would prefer the kernel to be compiled only by the GNU toolchain. That explains why you’d want GCC as the backend but not why you need a duplicate front end. I think it’s a bad idea to have multiple front ends and Rust should learn from the mistakes of C++ which even with a standards body has to deal with a mess of switches, differing levels of language support for each compiler making cross-platform development harder, platform-specific language bugs etc etc. > A lot of care is being put into gccrs not becoming a "superset" of Rust, as Cohen put it. The project wants to make sure that it does not create a special "GNU Rust" language, but is trying instead to replicate the output of rustc — bugs, quirks, and all. Both the Rust and GCC test suites are being used to accomplish this. In other words, I’d love gccrs folks to explain why their approach is a better one than rustc_codegen_gcc considering the latter is able to achieve this with far less effort and risk.

gkbrk 3y ago
> Rust should learn from the mistakes of C++ Rust should learn from the mistakes of C++ and C, which are one of the longest lasting, biggest impact, widely deployed languages of all time? It's confusing when people think language standards are bad, and instead of saying this code is C99 or C++11, they like saying "this code works with the Rustc binary / source code with the SHA256 hash e49d560cd008344edf745b8052ef714b07595808898c835f17f962a10012f964".
- pornel 3y ago
  C and C++ are widely used despite their language, compiler, and build system fragmentation. Each platform/compiler combo needs ifdefs and workarounds that have been done for so long they’re considered a normal thing (or people say MSVC and others don’t count, and C is just GCC+POSIX). There’s value in multiple implementations ensuring code isn’t bug-compatible, but at the same time in C and C++ there’s plenty of unnecessary differences and unspecified details due to historical reasons, and the narrow scope of their specs.
  - gkbrk 3y ago
    Yes, that's how the story goes. Languages with specs are widely deployed despite being fragmented and bad, not because people find value in multiple implementations. Must be a coincidence that C, C++, Javascript and C# and Java all fall under this umbrella.
    - legobmw99 3y ago
      Java and C# seem to have actually gotten the idea of multiple implementations correct, in the sense that I have never needed to worry about the specific runtime being used as long as I get my language version correct. I have basically never seen a C/C++ program of more than a few hundred lines that doesn’t include something like #ifdef WIN32 …
      - bluGill 3y ago
        Is there more than one Java implementation that is usable? All I can find are obsolete products that never got very far.
        gkbrk 3y ago
        Here are a few Java implementations that I've used recently. - My Android phone - OpenJDK on my laptop - leJOS for a university robotics course to run on Lego robots - Smart cards, I have a couple in my wallet Perhaps I'd call the Lego robot stuff obsolete, certainly not the Android userspace or smart cards though.
bryanlarsen 3y ago
> Rust should learn from the mistakes of C++ They are. You quoted them doing it, the care taken not to become a superset. The problem with C/C++ stemmed from compiler vendors competing with each other to be "better" than their peers. Multiple front ends of an implementation of a language usually shakes out a bunch of bugs and misimplementations. That's the primary benefit of having multiple front ends IMO.
- delfinom 3y ago
  >The problem with C/C++ stemmed from compiler vendors competing with each other to be "better" than their peers. Yea but this is Linux and OSS. NIHisms are fucking rampant everywhere. I give it a year before gccrs announces a new "gnurs" mode with language extensions.
  - saghm 3y ago
    I'd be surprised about this mostly because I can't imagine anyone using gcc-specific Rust extensions. Not only does rustc have an extraordinary amount of traction by being basically the only choice up until this point, Rust doesn't really have the reputation of moving slowly to adopt new features; if anything, there's been as much skepticism about new features added over the years as excitement. I can honestly imagine more people adopting a Rust implementation with a commitment _not_ to add new features that are added to rustc than one that adds its own separate features. Even as someone who probably will never use gccrs, I think having more than one implementation of Rust is a good thing for the language (for all the usual reasons that get cited). In the long term, I'd love for Rust to eventually to be able to specify its semantics in a way that isn't tied to rustc, which is a moving target and gets murky when you consider implementation-specific bugs.
    - nequo 3y ago
      > Rust doesn't really have the reputation of moving slowly to adopt new features There are some exceptions to this. Although there are possibly good reasons for such features moving slowly, a competing compiler could popularize them before they are stabilized in rustc. One example is generators[1] but there's a longer list in The Unstable Book.[2] [1] https://github.com/rust-lang/rust/issues/43122 https://github.com/rust-lang/rust/issues/43122 [2] https://doc.rust-lang.org/stable/unstable-book/language-features/generators.html https://doc.rust-lang.org/stable/unstable-book/language-feat...
neuromanser 3y ago
> I think it’s a bad idea to have multiple front ends and Rust should learn from the mistakes of C++ which even with a standards body has to deal with a mess of switches I do not disagree, yet at the same time, having the same set of switches across different languages is nice, too.
ndiddy 3y ago
Having another Rust implementation allows for an "audit" to help validate the Rust spec and get rid of any unspecified behavior. It would also give users options. If I hit a compiler bug in MSVC, I can file a report, switch to GCC and keep working on my project until the bug is fixed. With Rust, that's not currently possible.
- VBprogrammer 3y ago
  I don't have a lot of experience in C or C++ but I wonder if this ever works in practice for a non-trivial codebase? I'd be really surprised if, without diligently committing to maintaining compatibility with the two compilers, it was easy to up sticks and move between them.
  - cozzyd 3y ago
    It's pretty easy to move between gcc/clang/icc for most codebases. Though there are some useful features still that are gcc only. (And probably some that are clang only, though I pretty much only use gcc...)
  - logicchains 3y ago
    >I'd be really surprised if, without diligently committing to maintaining compatibility with the two compilers, it was easy to up sticks and move between them Many places deliberately compile with multiple compilers as part of the build/test pipeline, to benefit from more compiler warnings, diagnostics etc.
  - jupp0r 3y ago
    There are lots of libraries that need to compile on a variety of platforms (ie different versions of LLVM for Android and MacOS, MSVC for Windows and GCC for some embedded targets not well supported by LLVM).
  - ska 3y ago
    It works but you have to keep it at least "semi-active". Some shops have CI services setup to cross compile etc. already. Mainly I've seen this not as a tool to maintain a "backup" but as a way to shake out bugs and keep non-portable stuff from creeping into the codebase. You could probably do most of it with conservative linting and some in-house knowledge of portability issues, non-standard compiler extensions, etc. It's typically a lot easier to do this for different compiler, same target, than different targets.
rhdunn 3y ago
So by that definition you would only want one web browser as there are currently multiple HTML+CSS+JavaScript "front ends". In which case, you end up with a Chrome monopoly where Google gets to decide what the web looks like!
- mtrower 3y ago
  A goodly number of people appear to want just that. I don’t agree, mind you, but someone reading your comment with this mindset will probably be reinforced rather than swayed.
- gpm 3y ago
  A monopoly where a party with conflicting interests to the users being the sole arbiter is obviously problematic. A monopoly which is run by a group of individuals that do not have obvious conflicts of interest, and work for different organizations to mitigate the chance of non-obvious conflicts of interest, is far more interesting. Rust has the latter. It's not plausible that that will that a similar entity will take over the HTML/CSS/JS space, because of the amount of money competing with users interests in the space due to things like advertising, the desire to invade users privacy, etc. Still, if somehow we could magic up this monopolizing organization without conflicts of interest that would be far superior to the current state of affairs...
  - edelsohn 3y ago
    The Rust community is not perfect. Neither is the LLVM community nor the GCC community, not any Open Source community. Consider the recent drama / growing pains that has occurred within the Rust community. Everyone has biases and conflicts of interest. Anyone who doesn't recognize the benefit of alternatives will learn the hard way. The Rust community rationalization that they don't need / want alternatives for "reason" is self-serving and all about control. I don't care if someone is the BDFL, they aren't right 100% of the time and not always doing things for altruistic reasons. The Rust community has imbued the leadership with some godlike omniscience and altruism because it makes them feel good, not because it's sound policy.
bayindirh 3y ago
The main motivation is having a GPL licensed, independently developed complete Rust compiler which is not dependent on LLVM.
- cozzyd 3y ago
  Yes this is important. Otherwise in the future you'll see proprietary rust distributions for various devices or with specific features
  - GrumpySloth 3y ago
    C++ and Java, which have many implementations, also have proprietary distributions, see Apple’s fork of Clang, Microsoft’s MSVC, Azul VM, Jamaica VM, ... And some of them are pretty nice. Life is good.
    - bayindirh 3y ago
      When you don’t have a GPL implementation, the only good implementation might be closed source fork of the LLVM version, effectively forking Rust into Rust and Rustium. Will life be good then?
      - sunshowers 3y ago
        This seems like an astoundingly remote possibility.
        bayindirh 3y ago
        Given the companies backing LLVM and the surrounding ecosystem, I think it’s an astounding possibility. Companies love permissive licenses for a reason.
  - swsieber 3y ago
    You'll still see those though? A fully GPL implementation doesn't prevent the current implementation from being used in a proprietary rust distribution... unless of course the GPL implementation were to fork from the current implementation... which is the main thing people against the GPL implementation are worried about
mhh__ 3y ago
There are arguments for and against but for colour: D in GCC uses a shared frontend, which means it's not hard to maintain the frontend aspects — but that also means the frontend is a monoculture which is not very healthy at the moment. If someone will pay you to do it I would do a new frontend — it's surprisingly little work to get something you can bootstrap with.
- p0nce 3y ago
  Having maintained both C++ and D for different compilers, it's way easier to do it in D since the front-end features are the same (modulo builtins) and the stdlib is 99% the same.
edelsohn 3y ago
Based on that logic, why did the LLVM community develop Clang, Clang++, libc++, etc. instead of continuing with DragonEgg? There already were GCC, G++, libstdc++ , as well as EDG C++ front-end. GCC, Clang, MSVC, and other compilers complement each other, serve different purposes, and serve different markets. They also ensure that the language is robust and conforms to a specification, not whatever quirks a single implementation happens to provide. And multiple implementations avoids the dangers of relying on a single implementation, which could have future problems with security, governance, etc. The GNU Toolchain Project, the LLVM Project, the Rust project all have experienced issues and it's good to not rely on a single point of failure. Redundancy and anti-fragility is your friend.
- vlovich123 3y ago
  LLVM saw growth for a number of reasons, but nothing to do because it was actually beneficial for the C++ ecosystem: * A C++ codebase. At the time GCC was written in C which slowed development (it’s now a C++ codebase adopting the lessons LLVM provided) * It had a friendlier license than GCC which switched to GPLv3 and thus Google & Apple moved their compiler teams to work on LLVM over time. * Libc++ is a combination of friendlier license + avoiding the hot garbage that was (maybe still is?) libstdc++ (e.g. there were incompatible design decisions in libstdc++ that inhibited implementing the C++ spec like SSO). There were also build time improvements if I recall correctly. * LLVM provided a fresher architecture which made it more convenient as a research platform (indeed most compiler academics target LLVM rather than GCC for new research ideas). Basically, the reason LLVM was invested in instead of DragonEgg was a mixture of license & the GCC community being quite difficult to work with causing huge amounts of investments by industry and academia into LLVM. Once those projects took off, even after GCC fixed their community issues they still had the license problem and the LLVM community was strongly independent. Compilers don’t typically generate security issues so that’s not a problem. There are questions of governance but due to the permissive license that Rust uses governance problems can be rectified by forking without building a new compiler from the ground up (e.g. what happened with NodeJS until the governance issues were resolved and the fork reabsorbed). It’s funny you mention the different C++ compilers consider that Clang is well on its way of becoming the dominant compiler. It’s already targeting to be a full drop-in replacement for MSVC and it’s fully capable of replacing GCC on Linux unless you’re on a rarer platform where GCC has a bit richer history in the embedded space). I think over the long term GCC is likely to die and it’s entirely possible that MSVC will abandon their in-house and instead use clang (same as they did abandoning IE & adopting Blink). It will be interesting to see if ICC starts porting their optimizations to LLVM and making them freely available - I can’t imagine ICC licenses really bring in enough money to justify things.
matheusmoreira 3y ago
> The project wants to make sure that it does not create a special "GNU Rust" language That's disappointing. GNU's extensions to the C language are extremely valuable features. I'd like to see what sort of contributions they would make.
- awestroke 3y ago
  Hah
- Kwpolska 3y ago
  They may be valuable C features, but Rust isn't designed by committee, and if it's missing some useful feature, you could probably convince the Rust team to include it, without having to invent GCC-specific extensions.
cbmuser 3y ago
I don’t understand why this question is kept being asked. Is Rust holy in some sense that’s it’s not allowed to rewrite the frontend? It’s still a PITA to bootstrap Rust on a new architecture and there is also no working Rust compiler for architectures not supported by LLVM. I know that there is codegen_rust_gcc but that one has the same bootstrap problems as the original Rust compiler and also requires architecture support to be landed in various Rust part which Rust maintainers have beem hesitant about (been there, done that). So, I am absolutely glad that there will be an out of the box usable Rust compiler in the near future which will finally allow me to build rustified libraries again on architectures such as alpha without much pain.
- fl0ki 3y ago
  With GCC itself being written in C++, what is better about GCC's own bootstrap story except that it's been part of operating system distributions for longer? I am not aware of anyone using clang or MSVC to bootstrap GCC on Linux distributions for example, they use GCC's own lineage traceable back to C. It has the same bootstrap problem, and it isn't a problem in practice because vendors distribute binary toolchains. Even BSD and Gentoo start out with an initial set of binaries before rebuilding the world. The architecture support angle is a better one for why a GCC backend is helpful, but that will also be addressed by rustc_codegen_gcc so it isn't a relevant argument here. And by the looks of it, that will be a usable solution much sooner than gccrs, and it will remain usable with a much lower long-term resource commitment. This is an argument more in favor of rustc_codegen_gcc than gccrs. The strongest argument I can see about bootstrapping issues here is that Rust moves much faster and Rust's own compiler code requires a relatively recent Rust version, so in the extremely specific circumstance where binaries are not available and cross compilation is also not possible, bootstrapping will take more steps than it would for a gccrs frontend limited by C++'s slower rate of evolution. I don't see this being anywhere near as much of a problem as gccrs trying to catch up to & keep pace with Rust's frontend evolution. The former we can solve with the same build farms and cross compiles we need anyway, the latter requires continuous ongoing human effort with all of the disadvantages of C++.

rayiner 3y ago

I’m surprised at the negative reaction to GCC-RS. If a language doesn’t have multiple implementations, it’s a pretty sad excuse for a language.

sylware 3y ago
The problem is on the long run: syntax stability, avoiding feature creeps with extensions/attributes, like we actually have with C (c++ is beyond saving due to its absurd and grotesque complexity). Without that, you won't have real-life alternatives.
- ajross 3y ago
  > avoiding feature creeps with extensions/attributes, That seems like a purely semantic argument? Rust is adding features extremely rapidly! You're just saying it's "development" if it's done by one entity but "creep" if it's done by someone else?
PoignardAzur 3y ago
> I’m surprised at the negative reaction to GCC-RS. If a language doesn’t have multiple implementations, it’s a pretty sad excuse for a language. That used to be the common wisdom (especially because of C/C++), but it's a lot more debated these days. The consensus in the Rust community is that the current situation (one canonical-by-definition compiler, lots of documentation, a minimal spec for safety-critical industries, and specs for some modular sub-parts) get most of the advantages of multiple implementations without the drawbacks.
- not2b 3y ago
  I think that the people who are debating it are missing some things. It often happens that only when a second implementation is attempted, unspecified holes in the documentation are exposed and standards are tightened up. Any differences in the two compilers will either mean that there's a bug in the new implementation (most likely), a bug or unclear issue in the documentation, or a bug in the mature implementation (it happens). And no, the official compiler isn't canonical by definition. If it were, it would mean it has no bugs, and if there's a crash or a wrong result that's what the language is supposed to do.

sylware 3y ago

[flagged]

arp242 3y ago
Rust already uses C++ in LLVM so nothing changes there. This must be the umpteenth rant on C++ I've seen from you. This does not contribute anything. Please stop.
- flooow 3y ago
  The underlying point is correct though. Rust developers cannot be expected to maintain a C++ implementation of their language. Half of them learned Rust to get away from C++, the other half never knew C++ in the first place.
  - gpm 3y ago
    For what it's worth, rust developers are already maintaining an independent C++ implementation of the language: https://github.com/thepowersgang/mrustc https://github.com/thepowersgang/mrustc
    - sylware 3y ago
      [flagged]
      - ColonelPhantom 3y ago
        Well, rustc is the canonical Rust compiler. mrustc mostly just exists to aid in bootstrapping and really not much else.
        sylware 3y ago
        I make the difference between canonical and bootstrapping. When I said canonical, I meant the reference one which will actually be used to compile "normal" rust code. I guess this reference canonical rust compiler has the decency to be fully written using rust itself, am I wrong? (I was told it is, then if it is not, I was lied to)

charcircuit 3y ago

>the Linux kernel is a key motivator for the project because there are a lot of kernel people who would prefer the kernel to be compiled only by the GNU toolchain. Linux can already be compiled with clang if you want an all LLVM based toolchain. The duplicate effort of developing and maintaining this does not sound worth it to have GNU "purity."

mtrower 3y ago
I think you may be misunderstanding here. They aren’t trying to keep the kennel GNU exclusive —— they merely want the option for a pre GNU toolchain.
- charcircuit 3y ago
  What is a pre GNU toolchain?
  - ColonelPhantom 3y ago
    They presumably mean "pure GNU toolchain", not "pre".
edelsohn 3y ago
It's not about purity, it's about options. The ClangBuiltLinux community advocated that Linux should not be dependent upon a single compiler. But when Rust came along, suddenly many of the same people suddently decided that a single compiler was okay.
- rightbyte 3y ago
  I always understood it as that they want control over "best practice". A GNU compiler could add convenient feutures that the hardcore Rust users don't want other Rust users to be able to have. Like ideological purity.

thesuperbigfrog 3y ago

Rust needs a language standard: https://blog.m-ou.se/rust-standard/ https://blog.m-ou.se/rust-standard/ https://rust-lang.github.io/rfcs/3355-rust-spec.html https://rust-lang.github.io/rfcs/3355-rust-spec.html https://github.com/rust-lang/rfcs/pull/3355 https://github.com/rust-lang/rfcs/pull/3355 There are many organizations and industries that will not adopt Rust until it has a standard. C, C++, C#, and even JavaScript (ECMAScript) have language standards. Why shouldn't Rust have one too? C: https://www.iso.org/standard/74528.html https://www.iso.org/standard/74528.html C++: https://isocpp.org/std/the-standard https://isocpp.org/std/the-standard C#: https://learn.microsoft.com/en-us/dotnet/csharp/language-reference/language-specification/introduction https://learn.microsoft.com/en-us/dotnet/csharp/language-ref... JavaScript / ECMAScript: https://ecma-international.org/publications-and-standards/standards/ecma-262/ https://ecma-international.org/publications-and-standards/st...

ajross 3y ago
Yeah. The culture crash here is shocking dissonant. The people you'd normally expect to be the biggest voices for documentation robustness are... ... suddenly finding themselves in the "Actually, language standards are bad" camp, all because of a tribal opposition to the FSF? Write the standard. Then argue that gccrust doesn't do it right. Don't refuse to document the language just to hamstring a competitor. Also, please start with the borrow checker semantics. I don't think I've ever met anyone who could explain exactly what the rules are regarding what it can/can't prove.
- estebank 3y ago
  There's been active work on a Rust specification for a while now. It'll happen. https://blog.rust-lang.org/inside-rust/2023/11/15/spec-vision.html https://blog.rust-lang.org/inside-rust/2023/11/15/spec-visio...
- Rusky 3y ago
  What culture crash? The Rust project has a language reference, is working on expanding it into a more formal spec, and there are efforts like Ferrocene's to qualify the existing compiler for use in safety critical environments. The argument is not that language standards are bad, it's that a C++-like ISO standard is unnecessary (when the quality documentation can exist in another form) and C++-like implementation fragmentation is bad. (Have you read the NLL RFC? The Polonius work?)

johnklos 3y ago

So we'll finally see Rust support for all the architectures that gcc supports that LLVM doesn't, like Alpha, SuperH and VAX, for starters. That'll be nice!

segfaultbuserr 3y ago
Can't wait to see some PDP-11 machine code from Rust (the last time I checked, freestanding C compiling still worked on GCC).
Asraelite 3y ago
I would assume it also means additional configuration options for already-supported architectures. For example, I recently discovered that with RISC-V, GCC supports the RV32E target but LLVM doesn't.
- monocasa 3y ago
  Are you sure about that? I was pretty sure that llvm has supported RV32E for years now. https://reviews.llvm.org/D70401?id=395048 https://reviews.llvm.org/D70401?id=395048
  - Asraelite 3y ago
    Oh, last time I checked clang didn't support it. In any case, there are a lot of other compiler flags that are exclusive to gcc.
crotchfire 3y ago
And mips64, which rustc recently dumped support for after their attempt to extort funding/resources from Loongson failed: https://github.com/rust-lang/compiler-team/issues/648 https://github.com/rust-lang/compiler-team/issues/648 This is the biggest problem with the LLVM mentality: they use architecture support as a means to extract support (i.e. salaried dev positions) from hardware companies. GNU may have annoyingly-higher standards for merging changes, but once it's in there and supported they will keep it for the long haul. It's like buying vs renting. It takes a lot more dev hours to get support into GCC, but once it's there, it stays there.

gumby 3y ago

> A lot of care is being put into gccrs not becoming a "superset" of Rust, as Cohen put it. The project wants to make sure that it does not create a special "GNU Rust" language, but is trying instead to replicate the output of rustc — bugs, quirks, and all. In my experience, the part in italics is a significant mistake. Rust does not have a specification; there is a reference but it is explicitly not normative. A language udocumented except for a single reference implementation (as is tpday's fashion) have a long term weakness. What is the motivation for slavishly trying to maintain compatibility with the bugs and accidental quirks of another implementation? To guarantee that existing code will work in both implementations, which sounds sensible. And it is a sensible goal, but it does so at enormous cost by enforcing it in the wrong place. The problem is that sometimes decisions are wrong, and sometimes bugs are written. But when you promise that all implementations will be bug compatible as part of compatibility you are also signing up to fossilize these bugs whether you want to or not. A good example of someone who embraced this (to their credit!) is Microsoft: they spend a lot of person-power making sure that old programs continue to run while trying to fix security and reliability bugs. Rust need not and should not sign up for this burden so early in its lifespan. They should learn from history. If they want the language to evolve they should embrace QA and QC. Famously "you cannot test quality into a product". You need QA: architecture, design, design and code reviews, etc to ensure that things will work properly and when not, that "failure heads in the appropriate direction". Then later in the development cycle QC (test cases) tries to see if you missed. This doesn't just apply to product development -- it applies to language development especially. The strong standards (e.g. ComonLisp, C++, FORTRAN) embraced this belief. The weak, de facto ones (Most notably Python, but plenty of others) can still become popular, but change is difficult. Look at how long the Python 2->3 transition took, and how few python implementations there are.

nicoburns 3y ago
If they find a big then presumably they’ll report it upstream and both implementations can be changed.
- gumby 3y ago
  The point is that fixing that bug may break existing, running code that depends on it.

mkesper 3y ago

Thanks for posting the lwn.net link, reminded me of renewing my subscription!

sophacles 3y ago
It's a good subscription to have. I've gotten far more value from my LWN subscription than I spent, and recommend everyone that does lowish level work get one.

dj_gitmo 3y ago

> Cohen listed a few things that gccrs is already useful for. According to him, the Sega Dreamcast homebrew community uses gccrs to create new games for the Dreamcast gaming console, and GCC plugins can already be used to perform static analysis on unsafe Rust code. The Dreamcast community's interest stems from the fact that rustc's LLVM backend does not support the Hitachi SH-4 architecture of the console, whereas GCC does; even in its incomplete state, gccrs is helpful for this embedded use case. This is delightful.

habitue 3y ago
This is a little misleading. You don't need to have a gcc frontend for this, just a gcc backend

_8j50 3y ago

Late in the thread but this may not be a good thing. I already can't use rustc or golang from distros because they can't keep up with the latest versions of these languages that are being released evey few months. I have a system now where much to my shock I am getting rid of gcc because it is not needed but keeping upstream golang and rust for updating existing software, which is by the way a nightmare when I updated golang few months back for a CVE and had like four places where the go based apps stored their own go environment.