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