As someone new to the dev party who has never built anything more lower level than a win32 exe, may I ask why that's insane?

Adding 1000 npm dependencies, I see. Adding 1 rustc one? Doesn't SEEM terrible.

We only just got to a point where 2 C compilers could build Linux; adding rustc brings us back to a monoculture.

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?

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.

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.

You could argue not having memory safety when there are tools to do so is insane.

Memory safety is not an absolute good which overrides all other things, like performance, portability, compilation, process, compile time etc.

It is a problem that is well understood and the kernel developers have a lot of experience and tools for dealing with it.

Would it be worth solving well? Definitely, but it has costs and tradeoffs.

I wouldn't be too worried about it. The kernel people aren't going to take a dependency on something that isn't standardized and doesn't have a spec.

Don't be so sure. Rust lobbying is strong and kernel maintainers don't take a tough stance against things like they used to.