Playing devil's advocate, limiting Linux at first to GCC only allowed it to heavily use GCC extensions (inline assembly, statement expressions, and many others), which wouldn't be the case if it had to be portable to different compilers. The other compilers which could build Linux (ICC, sparse, now clang - compiling the Linux kernel with compilers other than GCC is not a new thing) had to implement many of these useful GCC extensions (for instance, clang is compatible with GCC 4.2.1), which made these compilers better.
I suppose there's something to be said for it pushing state-of-the-art and compiler teachers, but it does so in a gcc-centric way and I'm not quite as enthusiastic about that.
For the Linux kernel? Absolutely. Rust is way too unstable right now for such an important piece of software. Give it 20 years and a standard, then we can talk.
Based on what? The relevant folks and decision makers are already talking, so it doesn’t sound like they think there’s a need to wait 20 years to at least start the conversation.
Writing some optional, non-essential piece != rewriting a piece that will require taking rust as a dependency for the rest of time.
The kernel folks just did a lot of work to remove the strict dependency on GCC. To think any of the big players [Red Hat et al] want to turn around and make their shining star dependent on a language that's been 1.0 for less than 5 years is just not realistic.
Without a language specification for Rust, any compiler that isn't the reference implementation, by definition, cannot be correct. Put another way, how is a compiler writer supposed to know what is and is not a bug in the reference implementation?
Not for anything important, no. For a fun side project, 1 compiler is fine. For a business that depends on a build chain, it's sensible to at least have a plan for switching. For a major OS kernel, even 2 compilers is too low for my comfort.
Honestly, that would give me pause if I were targeting iOS. It helps that if you're targeting iOS you already live and die at Apple's whim, so maybe that's a sunk cost; on the other hand, that's the kind of thing that would make me nervous about living in Apple's walled garden in general.
Playing devil's advocate, limiting Linux at first to GCC only allowed it to heavily use GCC extensions (inline assembly, statement expressions, and many others), which wouldn't be the case if it had to be portable to different compilers. The other compilers which could build Linux (ICC, sparse, now clang - compiling the Linux kernel with compilers other than GCC is not a new thing) had to implement many of these useful GCC extensions (for instance, clang is compatible with GCC 4.2.1), which made these compilers better.
I suppose there's something to be said for it pushing state-of-the-art and compiler teachers, but it does so in a gcc-centric way and I'm not quite as enthusiastic about that.
It sounds like you're saying that you should never use any programming language until it's supported by at least 2 compilers. Is that accurate?
For the Linux kernel? Absolutely. Rust is way too unstable right now for such an important piece of software. Give it 20 years and a standard, then we can talk.
Based on what? The relevant folks and decision makers are already talking, so it doesn’t sound like they think there’s a need to wait 20 years to at least start the conversation.
Writing some optional, non-essential piece != rewriting a piece that will require taking rust as a dependency for the rest of time.
The kernel folks just did a lot of work to remove the strict dependency on GCC. To think any of the big players [Red Hat et al] want to turn around and make their shining star dependent on a language that's been 1.0 for less than 5 years is just not realistic.
Without a language specification for Rust, any compiler that isn't the reference implementation, by definition, cannot be correct. Put another way, how is a compiler writer supposed to know what is and is not a bug in the reference implementation?
Most languages do not have a specification, and it works out fine.
Rust's is in-progress. There are some things that are well-specified, and there are some things that are still up in the air.
Right, which is why it's a poor choice for the kernel at this time.
Not for anything important, no. For a fun side project, 1 compiler is fine. For a business that depends on a build chain, it's sensible to at least have a plan for switching. For a major OS kernel, even 2 compilers is too low for my comfort.
Should businesses who exclusively build iOS apps still be using Objective-C then, since Swift only has one compiler?
Honestly, that would give me pause if I were targeting iOS. It helps that if you're targeting iOS you already live and die at Apple's whim, so maybe that's a sunk cost; on the other hand, that's the kind of thing that would make me nervous about living in Apple's walled garden in general.