I have asked this question before, but why write an entirely new frontend, which is an enormous task if you want to reach a similar quality to rustc?
rustc_codegen_gcc¹ adds gcc as a backend to rustc alongside llvm, miri and (wip) cranelift. As a result, it always works with the newest version of rust and is already nearly complete after less work.
FSF wants to support Rust as a first-class language in GCC, which means their own implementation and ability to bootstrap without dependence on other projects.
Having two independent implementations is good for finding code depending on compiler bugs. The development will also highlight where the Rust language is not documented/specified enough yet.
The GCC implementation may end up with a different design, and perhaps faster compile times, or at least we'll know whether Rust is inherently slow to compile, or is that just rustc. Rustc supporting multiple back-ends can't have as close integration with GCC's back-end as GCC's own front-end.
> Having two independent implementations is good for finding code depending on compiler bugs.
I'd go as far as to claim that having multiple independent implementations is a basic requirement for any programming language which has any aspirations of being production-ready.
It would be pretty hard for a second implementation of TypeScript to gain any share of the market since Microsoft refuses to update the TypeScript specification. They point to tsc and say that is the specification. It is completely unprofessional in my opinion.
Counterexample: the fact that there is only a single official go compiler is great advantage IMO since it enables a lot of cool tooling and great new features are introduced quickly in the official implementation.
What leads you to believe that the lack of alternatives leads to enabling "a lot of cool tooling"?
> and great new features are introduced quickly in the official implementation.
That has zero to do with existing only a single implementation, and everything to do with having developers working on unstable releases and a poor job thinking things though by writing stuff down both as proposals and specifications.
If there is a specification that was discussed and thought-through by competent individuals, nothing stops anyone in the world from reading the specs and implementing the same features.
Contrast this with C which has several compilers and plenty of build systems to choose from, often more flexible and advanced than Cargo, but the fragmentation means that C projects are snowflakes, and tooling needs to be configured for each project and compiler combo. For every build system X there's someone who says it sucks and you should be using Y instead.
However, I don't think GCC will cause similar fragmentation problems for Rust, because there are already 100K rustc+Cargo packages in existence, so it has no choice but to follow and be compatible with them.
Cargo is not universal. Many projects use rustc directly with an alternative build system such as bazel, make, or meson as they are in multilingual repos. The fact these projects exist doesn't affect your experience with rust. The fact a gcc tool chain for rust will exist should similarly not affect your experience.
It does. GCCGO is often used for bootstrapping golang, and is sometimes used as a full alternative compiler for architectures that Google refuses to consider supporting.
These days lots of languages are single-team efforts, because producing high-quality production programming languages is an incredibly large amount of (difficult) work. It is really, really difficult, it takes many years, you constantly get shit on by people for everything, and if you're lucky you might get a tiny bit of money after a while. It isn't just coincidental complexity; programmers are actually incredibly demanding users with many needs. And so it isn't easy to find the money and people to perform multiple implementations, outside of very particular cases. Even the ratio of C/C++ programmers to high quality implementations that see significant production use is basically astronomical. And the unfortunate news is that alternative implementations don't often contribute very much to the overall production-language effort if they aren't of high quality or set out to achieve particular goals.
I used to work on the Haskell compiler GHC. Haskell has had many alternative implementations over the years. But they were often nowhere near the level of engineering quality of GHC, and nobody used them for nearly anything, unless they were graduate students exploring surface and language semantics. But many of them just used GHC instead, too. It wasn't for lack of trying either; lots of people wanted the standard for the language to work, I used to be on the standards committee for the language. So they were useful to some extent design space. But there are many, many, many other important concerns for a "production" programming language; robust feature support, good platform support, high quality code output, robust testing regime and code review, good library and API design, high quality debugging support, package management, editor support, all kinds of stuff. These also dovetail together; certain efforts at the semantic level are nice but if they don't have a good story for debugging or something, they might not make the cut.
Really this seems like one of those requirements that's always impossible to satisfy in some sense, a kind of catch-22. If you're one of the 800lb gorilla programming languages (Java, C++, Python), you might have one or two "production" implementations and if you're lucky the ratio of usage is better than 80/20, but they exist and therefore you are a "production-ready" language. Nobody else has the money to staff engineers for multiple alternative languages (OCaml, Elixir, TypeScript, Go) despite them funding billions of dollars worth of software, so they still aren't "professional" and therefore do not qualify. I get it, and it's not for zero merit, but I think it's mostly just a cat-and-mouse game, at the end of the day.
gcc-rs existing of course has many other benefits beyond this; people know GCC so they can now have a free Rust compiler for their CPU ports, etc. This is still good. But really it's still the exception. I do think this is a good effort but I consider this sort of thing one of those basic folklore issues that's actually much more nuanced in practice.
The number of people who use those alternative implementations -- or even the quality of their output with respect to performance or platform support -- don't really matter: the reason to insist on (at least, and as unrelated as possible) two separate implementations of something is to ensure that the behavior of the language isn't merely an accident of incorrect code in the compiler instead of an intentional choice by the language designers, as it shows that two different teams came to the same result (at which point hopefully it is noticed if there are spec issues and those are either corrected in the parent compiler or "bug for bug" duplicated in the child compiler after documenting the issue in the spec). Until you have done this, it is difficult to even claim what the language even is.
That's an antiquated notion from the times when programming language implementations were 99% propriety, so you needed some ability to "shop around".
Any time you hit a fork button on an Open Source programming language's github page, you get your own independent implementation. Hire a contractor and introduce any "extensions" you need.
Because single implementation languages are toys. Any real language will have a multiplicity of implementations for different purposes. GCC has a ton of development resources behind it; processor makers are familiar with it and often turn to it to bring up new processors and ISAs, etc. Having a GCC front end is a big step in Rust becoming more popular as a systems language.
This simply isn't true. Only C/C++ people have ever cared about having multiple implementations and have to cling to the catastrophe that those two standards are because of it.
There's a difference between having multiple implementations, even high quality ones, and caring about it. Python is all about the reference implementation, as much as I wish that people cared about pypy and the JS community has always been openly hostile to SpiderMonkey compatibility and only cares about V8 in my experience. And Java is all about different forks of the same jdk, even if several actually independent different ones used to exist.
I will admit to not being familiar enough with Ruby to say anything about that
The catastrophe was that the C/C++ specification left too many things open for interpretation. Regarding "Only C/C++ people": there is at least one more language (Go) that has two implementations (the gc compiler and a gcc backend).
I didn't say only C/C++ had several implementations, I said that only the C/C++ communities care about their alternate implementations. The python community looks at pypy like a weird novelty and doesn't use it. The JavaScript community is often actively hostile to SpiderMonkey (firefox) and JavaScriptCore (Safari). As far as I've seen, GccGo is mostly ignored.
> This simply isn't true. Only C/C++ people have ever cared about having multiple implementations and have to cling to the catastrophe that those two standards are because of it.
This comment is so blatantly wrong and detached from reality that it makes me wonder if it's just a good old fashioned troll.
You'd be hard-pressed to find any production programming language which does not have multiple independent implementations.
HHVM dropped vanilla-PHP compatibility after PHP7 started coming close to it in performance (which was the top reason anyone used HHVM to serve vanilla-PHP code) - now they’re focussing on Hacklang which, no longer shackled by the need to be bug-compatible with PHP’s awful design decisions, is free to become a better language
Kotlin is a prime example. You have to download the vendor implementation. There's no way to bootstrap. It's horrible from a tooling perspective.
Any single-implementation language inevitably degrades to the point where the implementation becomes the specification. Shortly afterwards, people can only use the language if their tool chain, operating system, etc. closely match the understanding of the language authors. That's a bad situation to be in.
I don't see how the bootstrapping problem is linked to multiple implementations.
> Shortly afterwards, people can only use the language if their tool chain, operating system, etc. closely match the understanding of the language authors.
Perl, well-known for being an iffy language to install and running on a restricted set of OS/architectures.
Multiple implementations brought only trouble and frustration to the masses and endless opportunities for companies to exploit feature lock-ins (borland anyone?) . If anything drives people mad more than anythong are gcc vs clang vs msvc vs this or that issues. Just the whole complex numbers or quad precision issue is the best example from math handling. It is basically very unsuccessful stakeholder management to say the least. One of the main reasons for us to switch to Rust is not having multiple implementations.
I've wondered about this for ages and now know: the people who work on GCCRS wouldn't work on rustc_codegen_gcc for one reason or another (familiarity, culture, personal ideals...?). So GCCRS is not "eating away" at available bandwidth and there's no reason not to let GCCRS developers do their thing, even if rustc_codegen_gcc is a more straightforward way of achieving most goals
It's probably not hugely useful from a "I want to compile this Rust code" point of view but I imagine it will at least help iron out ambiguities and bugs in the various specs people are working on. I think there's at least MiniRust and the Ferrocene Language Specification:
rustc got bootstrapped already, so download it. If you want to run the compiler itself on a new architecture, cross-compile. If you still decide to bootstrap it again, that's something that will only need to be done once. And even in that case, you can use the second implementation that already exists, mrustc.
The same reasons given[1] for "why write clang when gcc works fine", mostly? Multiple implementations of a language force rigor in the specification[2], find edge cases in implementations, and promote healthy competition in performance.
[1] The good reasons, anyway. Please no GPL screaming.
[2] Something that IMHO rust has historically been kinda bad at. Even now there remains no clear specification I can find that explains exactly what behavior the borrow checker will admit vs. reject.
I hope there aint gonna be ecosystem fragmentation
When there are a fews compilers with significant market share then developers are those who lose, lose that handy dev. experience of solid and consistent ecosystem
The gccrs developers have talked at length with Rust developers towards the same aim: they don't want to create fragmentation either. Among other things, the gccrs developers have said in multiple places both public and private:
- They aren't going to fork or extend the language; they'll work with the normal Rust language evolution process.
- They're treating rustc as the reference for correct Rust. This doesn't mean there can't be bugs in either rustc or gccrs, and rustc will deeply appreciate bug reports found through this level of inspection of its behavior, but nonetheless this is a stated goal of the gccrs folks.
- They plan to explicitly provide messaging, potentially even in compiler error messages, to the effect of "if gccrs doesn't compile a crate that does compile on rustc, that's a bug in gccrs, not a bug in that crate; do not report it as a bug in that crate or ask crate developers to work around gccrs limitations".
So, I think the gccrs folks are doing everything they can to avoid fragmentation, short of the project not existing at all.
You can already do that. Some libraries wilfully restrict their MSRV for backwards compatibility or distro compatibility (e.g. Debian stable provides 1.48).
I think this is more of an attempt of making Rust compilable on platforms not supported by LLVM, not an attempt to replace the existing compiler. The GCC frontend, for instance, does not implement the borrow checker, so you should only use it to compile Rust code you know is correct according to the official Rust compiler.
Not too strange. Imagine the reverse: a C compiler written in Rust. There is an awful lot of software in C that I want to use, but I really dislike C itself. If I found some deficiency in C compilers and felt the need to write my own, I certainly would prefer to write it in Rust.
It would be a C implementation for people who don't like C.
It seems like an odd idea to release a Rust compiler without a borrow checker. Isn't there a high risk that it will confuse users into thinking they have the usual Rust guarantees at run-time?
This can be very useful for platforms where rustc is not available due to LLVM not supporting them. Take a project, build it with rustc, and if it builds, you know it passes the borrow checker. It is then safe to build it for your actual target with gcc. This would limit the outcry when some software adds a dependency on Rust, like the python crypto thing of a few years back, or the Linux kernel.
This will still use the official rustc frontend. For what I described above, this is not an issue, it would totally work. However, there are cases where having a pure gcc implementation (frontend + backend) is beneficial.
As others have mentioned, vendors have the standard practice to fork gcc for their hardware, but not necessarily rustc nor libgcc used by rustc_codegen_gcc. This means that rust will be possible on those platforms for free thanks to gcc-rs.
Another point is the bootstrapping of the compiler. rustc has a quite complex bootstrap process that depends on python, while afaik gcc only relies on shell scripts. It is much easier to port gcc than rustc to a new host platform. This is useful when you want to compile code directly on your target and don't want to rely on cross compilation. cross compiling is a tricky thing to do, and while rust fares pretty well there, as soon as it uses native C libraries, it all falls apart (e.g. try cross compiling a project that has dependencies on libss, libpq and the like). In such case, native compilation may be the only viable option. And most of the times, GCC is the first thing to be ported, so you would not need to wait for a rustc port.
I think the expectation for now is that people will develop an app with rustc and then use gcc to compile to targets that aren't yet supported by llvm.
This is eventually going to be a feature-complete compiler, targeting a specific rustc version. I believe the plan is to use polonius [1], presumably as an "optional" feature so they can build a stage 1 without it, use that to build polonius, then build the final compiler with it included.
Lacking a borrow checker is a temporary thing, no point reinventing the wheel. I think the intent is that eventually it'll use the same library as Rust (maybe Polonius, or perhaps plans will change)
Without a borrow checker, at best it can be considered a code generator for pre-certified Rust source code. Possibly useful, but you'd still need to have rustc in the loop.
That could be a feature. I'm making a joke, but it would be tempting sometimes when the program is correct but the borrow checker can't figure that out. The borrow checker and I don't get along all that well, even two years into the relationship.
I disagree. We need competition. I'm not using (even avoiding) LLVM based toolchains, and not touching Rust even with a 100 foot pole because of that.
On the other hand, I acknowledge that LLVM kickstarted GCC development and made it better in thousand ways better, agile and flexible-minded (in terms of developers maintaining it).
Similarly, having two Rust compilers, nudging each other to be better is a great way to make a language more general, widely accepted, resilient and more free & open. Also Rust well be much more stressed and tested as a result.
> I hope it will be used only where necessary
I hope both will be used widely, and make Rust a better language with much better accessibility.
> We need competition. I'm not using (even avoiding) LLVM based toolchains, and not touching Rust even with a 100 foot pole because of that.
I'm interested in this. Could you elaborate on why you are not using Rust? Because there is no competition in the language, or because there is not an alternate compiler, or because you don't like LLVM?
It's mostly a personal choice. Any piece of software I write is opened up, and licensed with GPL.
I don't want my software dependent on a non-GPL toolchain to ensure its long term sustainability. I also try to choose GPL licensed libraries, and include everything required to build my code (incl. external libraries) inside my repository.
In the end I want someone to be able to just clone the repo, and run make, or GCC, or what it needs to be run. So, the code is just dependent on the compiler and its standard libraries when obtained by someone.
Lastly, I find LLVM's supporters and general ecosystem slightly hostile towards GCC, and want to replace it anywhere and everywhere possible. I'm a free software advocate, and I prefer LLVM and GCC just to be interchangeable.
Hence I only use languages which GCC supports exclusively or has GPL compilers/interpreters. Working on HPC makes this easier for me.
In the free software movement, we campaign for the freedom of the users of computing. The values of free software are fundamentally different from the values of open source, which make "better code" the ultimate goal. If GCC were to change from a free compiler into a platform for nonfree compilers, it would no longer serve the goal of freedom very well. Therefore, we had to take care to prevent that.
The Clang and LLVM developers reach different conclusions from ours because they do not share our values and goals. They object to the measures we have taken to defend freedom because they see the inconvenience of them and do not recognize (or don't care about) the need for them. I would guess they describe their work as "open source" and do not talk about freedom. They have been supported by Apple, the company which hates our freedom so much that its app store for the ithings _requires_ all apps to be nonfree. (*)
The nonfree compilers that are now based on LLVM prove that I was right -- that the danger was real. If I had "opened" up GCC code for use in nonfree combinations, that would not have prevented a defeat; rather, it would have caused that defeat to occur very soon.
For GCC to be replaced by another technically superior compiler that defended freedom equally well would cause me some personal regret, but I would rejoice for the community's advance. The existence of LLVM is a terrible setback for our community precisely because it is not copylefted and can be used as the basis for nonfree compilers -- so that all contribution to LLVM directly helps proprietary software as much as it helps us.
The cause of the setback is the existence of a non-copylefted compiler that therefore becomes the base for nonfree compilers. The identity of that compiler -- whether it be LLVM, GCC, or something else -- is a secondary detail. To make GCC available for such use would be throwing in the towel. If that enables GCC to "win", the victory would be hollow, because it would not be a victory for what really matters: users' freedom.
The only code that helps us and not our adversaries is copylefted code. Free software released under a pushover license is available for us to use, but available to our adversaries just as well. If you want your work to give freedom an advantage, use the leverage available to you -- copyleft your code. I invite those working on major add-ons to LLVM to release them under GNU GPL version-3-or-later.
* If a binary is made from published source code, but you can't install your binary of a modified version of that source code, the binary is proprietary even if the source code is free. (See http://www.gnu.org/philosophy/free-sw.html.) A binary in Apple's app store may be made from published free source code, but under Apple's rules and Apple's DRM, the binary can't be free.
> I have no idea why your comment received downvotes.
I have to agree re: the parent. It's a perfectly fine opinion to hold, though it's one I don't share. I asked and he/she told me.
However, republishing an email by Richard Stallman, just like Richard Stallman, might seem a little excessive.
Why? I think it's because although just as it's fine to be an atheist, it always seems weird when someone brings it up at dinner parties. We were discussing the whys and wherefores of a new Rust compiler. I'm not sure any lengthy expressions of our licensing religion or lack thereof is a positive contribution.
The irony of Richard's decision and justification is how misguided it was (and is) on multiple fronts.
First, GCC as a whole has never been technically superior to the commercial competition. The reason why GCC was popular outside the GNU crowd and received as much funded development is that it was the best compiler across a range of popular platforms and had the best price, too.
Second, one of the main drivers behind the creation of clang has been the hostility to making the C/C++ frontend of GCC usable as a standalone tool. Richard explicitly wanted to force everyone to either deal with the GPL and his interpretation of what is derived work, or shell off the bucks for the Edision Design Group. This was a calculated choice as no one would want to invest the time to write another C/C++ frontend, right? He intentionally ignored all other use cases for C/C++ parser as a library (Language server, anyone? Refactoring tools?) and thereby actually hurt the user base on the GNU platform just as well. It can not be understated how disruptive clang was as a set of libraries outside the LLVM/clang compiler.
Third, GCC had as middle and backend compiler always was moderately accessible, but by structure somewhat harder to access for researchers or people wanting on special purpose tools like optimized code generation for computational kernels on matrixes.
GCC was forced to acknowledge the competition by finally getting a plugin interface in the GCC 4.5 days, but at that point, the cat was out of the bag.
I think having a GPL implementation of a language makes it more future proof. I don't want to be able compile some source only with "rustc-v_ancient-company_name-internal_fork-no_you_cant_have_its_source" version.
Programming languages with single compilers tend to be not used in my area of work and research (HPC and Scientific Computing). Hence, I'd rather have multiple compatible, yet independently implemented compilers, per language.
> I don't want to be able compile some source only with "rustc-v_ancient-company_name-internal_fork-no_you_cant_have_its_source" version.
Yeah, it's not like Google (and dozens of others) has/have an internal fork of Linux, which never gets merged back. I'm not certain the GPL butters any parsnips here.
> Hence, I'd rather have multiple compatible, yet independently implemented compilers, per language.
You identified it. The problem is compatibility, and again Linux is a good negative example where ostensibly we have a language spec and multiple compilers, but Linux for years would only compile on one compiler.
Multiple compilers and "competition" doesn't solve compatibility. It makes it more difficult. Although I'm sure there will be benefits, I'm not certain the GPL/GCC will make compatibility any easier. It hasn't so far.
> Yeah, it's not like Google (and dozens of others) has an internal fork of Linux...
Doesn't matter for completely internal stuff. My concern is public code requiring non-public toolchains to compile. I have experienced this enough during the decades. I don't want to fight with this again.
Google doesn't want to touch Linux for their devices anymore, so they're building Fuchsia, but let's not digress...
> Multiple compilers and "competition" doesn't solve compatibility. It makes it more difficult. Although I'm sure there will be benefits, I'm not certain GPL will make compatibility easier. It hasn't so far.
What GPL brings to the table is strict openness, not compatibility. I can share my code and say that "It builds right on this $GPLd_Compiler", and people can get it and build it. This is what I like to bring to the table for anything I release.
I also wonder whether people would be this reactive to this issue if $company announced a closed source compiler with strict rustc compatibility.
> What GPL brings to the table is strict openness, not compatibility.
I kinda wonder where this has been an issue with LLVM re: non-public toolchains, and public code where it wouldn't also be an issue with GCC. FWIW I definitely could see it being an issue in HPC/graphics/ML.
> I also wonder whether people would be this reactive to this issue if $company announced a closed source compiler with strict rustc compatibility.
Call me dense -- I guess I don't understand precisely what you're getting at. I don't think anyone would use a closed source compiler with strict rustc compatibility without a pretty big carrot. I think the issue here is strictly compatibility/divergence. Although I'm personally less of a fan of GCC/GPL/FSF, I think a new compiler is great so long as it doesn't (completely) ruin some of the nice things about a single implementation system, and why rust_codegen_gcc seems much more appealing.
Many Rust people don't want to live in the C/C++ compiler world, because they don't have to. "Oops this code won't build with GCC" is a battle they'd just as soon avoid.
In the past I have downloaded kernel modules & SDKs for Linux, which were partially open (i.e. had binaries, compiled libraries, etc. alongside open parts), and they were intentionally compiled for highly specific environments, tying the modules or SDKs to (archaic) OS releases which are very hard to obtain, or cannot be obtained from anyone except the hardware vendor.
We wanted to use these thing in newer systems, but it was not always possible, and made our lives way harder than it should be. At the end of the day, you buy vendor's hardware and want to couple it with more modern software, but the vendor doesn't want this for some unknown reason. Planned obsolescence, maybe.
Now, consider that a company pulls the same shenanigans, but by moving the magic to the compiler. All source is open, but can't be compiled because, while the code valid, its correct compilation needs a specific compiler behavior, and the vendor who opened the source cannot share the compiler in source form due to "trade secrets". They may require you to send the code in to "make sure that it's fine", or "sign an agreement" to get the compiler, for a fee, maybe.
I don't want to live in this world, or leave anyone accidentally in that state.
> Many Rust people don't want to live in the C/C++ compiler world, because they don't have to. "Oops this code won't build with GCC" is a battle they'd just as soon avoid.
As someone else noted, gccrs people say that "We strive for rustc compatibility. We will not extend or mangle the language, and consider rustc as our test suite." This is a pretty strong commitment to "many implementations, single behavior" promise.
I started my computing journey in a very open and flexible ecosystem, and with every stopgap put as in the name of security, this openness and flexibility eroded step by step. With this pace, programming and development will be confined to corporations which design the hardware and OS running on them, and PCs will be consoles with keyboards.
I don't want to live in such future. This is why FSF/GPL is important, for me.
>This is not what happened with clang vs g++/gcc. Also we have Intel's, Microsoft's and Portland groups compilers side by side for decades.
What? Cpps ecosystem is the most developer hostile ecosystem that Ive ever used
I wouldnt want to write in it even if my salary was multiplied by 1.5
A lot of compilers where all of them have different lang. features implemented, various bugs, quirks, wtfs, various perf. characteristics (e.g intel's generating faster code)
Long as hell compilation times. This is fundamental problem yet still that diversity didnt manage to solve it
Many package managers
And mediocre lang by modern standards on top of that. Minefield++ would fit it better.
>Otherwise compilers and languages divert, and lack of alternatives make everything much more complicated in the long run.
Theres still competition between langs
I bet Rust helped cpp improve more than gcc clang diversity
I also dont fully understand why you treat lang as a standard instead of product
C++ is an old language, and may not be evolved the best way possible, because it set the path, didn't follow a trail opened by another language.
The ecosystem's state is different depending on your perspective and what you are trying to achieve with it. While C++ is touted as a general purpose language, it's overkill for most of today's tasks. I use C++ to write high performance and low level code. It's my favorite language to work with, but I'm not using it blindly for everything.
As a person who worked with C++ a lot, and still developing something (which I'll eventually open source) for almost a decade, I can say that most of the things you say are not completely correct.
> different lang. features implemented, various bugs, quirks, wtfs, various perf. characteristics...
You can opt to not use any of the compiler extensions and have a completely portable code. Said code compiles in GCC, LLVM on macOS and possibly in MSVC, and uses CPU at its highest potential (verified on Linux with perf, in turn verified by timing on macOS). Intel's compiler creates fast code for Intel's processors, but it needs intel's patched libraries, etc. It's not worth it most of the time, and GCC already creates pretty fast code. In my discipline compiler cross-compatibility is king. So Intel's is not that important for our case.
> Long as hell compilation times. This is fundamental problem yet still that diversity didnt manage to solve it.
You can re-compile only the changed parts in any compiler for ages. This shaves a lot of time from compilation and linking times. Again this is neither novel, nor new.
> Many package managers
The idea of packages born with Java for enterprise software and became ubiquitous after that. Languages have their own package managers to prevent this, but it doesn't always work. Having an "official" package manager doesn't prevent from bringing in a "New and Improved (TM)" package manager to the ecosystem. Also, Rust is a young language. C++ is well, 35 years old? It's inevitable that we have better solutions for the issues we have at hand.
> And mediocre lang by modern standards on top of that. Minefield++ would fit it better.
It's a language with unfettered low level access. It's a sharp knife (or fighter jet). Learn how to handle it, and it won't bite. It's never guaranteed to be fluffy like Go, Python or memory-safe (to a point) like Rust by adding hard barriers.
On the other hand, being semi-conscious about what you're doing prevents 99% of the problems in C++. Said code had memory leak once, during initial development, and fixed on the spot (I test my code with Valgrind), and is memory-sane since that day. That code is not something simple. It's a scientific application which makes your cores and memory controller saturate. It takes every bit of performance offered by your system and converts into science.
> Theres still competition between langs
Yes, but that's another matter, which is not subject of this discussion.
> I also dont fully understand why you treat lang as a standard instead of product.
Because a language is a language. Not different from mathematical notation or human language. Compiler is the product, which transpiles that language to another language (incl. machine code) to run on your PC, mouse, microwave or plant based biologic computer. Compiler is the product. Language is just a language. Sets of rules, a standard even (like C++ is an ISO standard).
I’ve come to the conclusion that fragmentation is inevitable as a language gets popular.
People think differently, have different ideas for how to do things, need it to work for their particular use case, etc. Fragmentation and bloat are a result.
I am willing to bet it will happen rust as it gets used more and more. Then the treadmill will start again with a new language.
(Sorry if that’s jaded. I’ve been fighting with python build systems lately. What a nightmare)
As Rust continues to improve and be more widely used and adopted, there will be multiple implementations. As you've stated, it is inevitable as Rust gets popular. (For example, if Rust becomes popular enough to displace niches that C and C++ have occupied, when will Microsoft release a Rust toolchain? When will Intel release a Rust toolchain? And so forth.)
Standards help to better define what a Rust toolchain should do and what it means to be a conforming Rust implementation.
Standards are necessary and help of course. But the real power always lies with the implementations. There is no compliance without enforcement.
For example, C++ has a standard, but compliance is all over the place. Even Fortran has the same problem. The web also had a standards body (W3C) but eventually that was completely ignored and became irrelevant.
>> Standards are necessary and help of course. But the real power always lies with the implementations. There is no compliance without enforcement.
You are correct.
Compliance depends on the implementation developer / maintainer. If the standard exists and is agreed upon, at least users can petition the implementation developer / maintainer and say "Your implementation does not conform to section 3, paragraph 2, line 1 of the standard. The expected behavior is X, but your implementation does Y. Please fix it."
If a standard does not exist, then who is to say what the correct behavior should be?
If there is a standard, but no one follows it, then perhaps the standard needs to be adjusted. (Why is the standard not being followed? Were bad ideas standardized?
Did the standards committee follow after one vendor's implementation to the detriment of other vendors' implementations? etc.)
It's certain that there will be fragmentation. There isn't any gnu project, which hasn't added its own extensions to standards or specs. Few examples: gcc front end for C/C++, bash, grep..
It means that crates.io will have crates which compile only with gcc and its extensions.
What are the practical implications of this? Could cargo call GCC? Or would it be like gcj and allow compiled rust libraries & binaries to be distributed? (at least in theory, gcj didn't work out well)
Lots of rarer or older architectures are not in LLVM e.g. alpha, ia64, HP-PA. The LLVM backends which do exist for such also tend to have been exercised less and thus me more buggy (I think PPC/spe had a fair amount of issues there but it might have gotten better).
You can see something of a summary over on https://builds.Debian.org/status/package.php?p=rustc&suite=s... the BD-Uninstallable entries are unsupported archs, though some of them might be due to rustc or bringup bugs (e.g. m68k is supposedly supported by llvm and rustc).
Then there’s embedded, on the more open side LLVM is slowly gaining ground but there’s also less open ecosystems where customising / forking gcc is pretty standard historically, and there’s not much LLVM can do.
Some of those older architectures are supported by the Linux kernel, which is adopting Rust. Giving GCC the ability to compile Rust code maintains support for those platforms as the percentage of Rust in the kernel grows.
There are also embedded applications, of course; plenty of crappy manufacturers still give you a GCC fork as your only compiler for their dedicated hardware. The ability to get Rust hooked into those compilers can help keep the ecosystem up to date.
Even companies maintaining their own software sometimes take a long time to add support to LLVM. Take for example Espressif's Xtensa fork that is only now starting to get merged (if https://discourse.llvm.org/t/rfc-request-for-upstream-tensil... is to be believed). Many patches are still waiting for review, so it'll be a while until LLVM finally supports Xtensa (and with it microcontrollers such as the ESP32). GCC has had Xtensa support for ages (Github lists xtensa.h going back all the way to 2002) and I doubt Espressif is the only company in this position.
"Just do the work" sounds easy but that work can take years. Getting modern Linux versions to compile may not be enough to drive companies to put in the effort; many may prefer to simply never update their kernels past the current LTS version again.
Adding a frontend to GCC works around this problem quite efficiently. It also makes it easier to port existing code to these platforms; sure, the lack of a borrow checker drops all guarantees Rust has been designed to provide, but if you're not writing any code, you don't need those anyway.
AVR (for example, old Arduino boards) and xtensa (like esp32 developer boards) are the only ones I know of. Most of the desktop OS platforms are supported by both.
Not so, there some obscure hardware platforms with C compilers but which are unsupported by GCC. GCC has no official backend for PIC or Z80, for instance.
Non-standard C-like languages are used in computer graphics and GPU computing (OpenGL, Direct3D, OpenCL), but strictly speaking they don't count as C.
Since there is now OpenJDK, there was no reason to keep working on it, and both GCJ and the associated class libraries didn't follow the evolution in the Java language. In the beginning GCJ became only an ahead-of-time bytecode compiler, with the Java->bytecode translation done using ecj; but ultimately there was no reason to keep it around at all and it was deleted in GCC 7.
It was kept around for a long time after everyone went to OpenJDK, because it was the only project with certain unit tests for GCC code paths, when that was eventually sorted out, it was when they dropped it.
The point of GCCRS over rustc_codegen_gcc is to make Rust easier integrateable into other projects and build systems. If you use Cargo anyways, you're much better off using rustc_codegen_gcc
Probably a dumb question, but I'd really like to know if this somehow affects/improves Rust's support for dynamic linking in any way (i.e., when comiling Rust code with the GCC-based toolchain, instead of with rustc)?
I would naively assume that it doesn't affect it at all. Compiling with GCC doesn't magically make dynamic linking better. The limitation in dynamic linking is an element of language design.
I'd also note that any Rust you compile with GCC probably shouldn't be dynamically linked with Rust code compiled with rustc.
You're basically asking why you'd want object files. They're a container of (usually) relocatable machine code. You can inspect or modify them with nm [1] or objcopy [2]. You can link them with object files generated from other programming languages to mix languages. Maybe you have a custom linker or environment that requires you to convert an ELF or COFF object file to some custom variant. There are lots of reasons.
¹https://github.com/rust-lang/rust/tree/master/compiler/rustc...