> This is a false and inflammatory statement

I think it's neither false nor inflammatory, but a neutral, objective observation. I think that if you asked people what languages in more-or-less regular use are about as complex as Rust (or more), they'll give you a very short list (I can think of no more than three: C++, Ada and Scala). That does not make it bad or unsuitable -- in fact, it might well be great for some -- but it does make it less attractive to those who value language simplicity.

> It also doesn't make many of the same safety guarantees as Rust. So there are trade-offs.

Sure, and if a low-level programmer's primary goal is to write software that's free of certain technical bugs that correspond to C's undefined behavior, then a language that can more-or-less guarantee they don't exist (with some caveats) may be the best way to achieve that. But I don't think that is most people's primary goal. Even for those who value correctness in high-assurance domains, the elimination of undefined behavior, which always comes at a cost, is not necessarily the best way of achieving correctness. Zig, too, puts an emphasis on writing safe code, it just goes about it a different way than ensuring certain guarantees, soundly, in the language itself.

Now, let me take this opportunity to also explain why it's uncertain that Rust's approach to correctness is the better one. I saw some report from Microsoft that 70% of their security bugs are due to undefined behavior in C++. Let's assume that all UBs are equally to blame, we'll assume that reducing security bugs is the only thing we care about, and we'll assume that Rust completely eliminates all UB (which isn't necessarily true because of unsafe and because there could be bugs in Rust and/or LLVM, but I'm willing to accept that Rust's approach is the best at eliminating UB). By choosing Rust and developing the software at cost X (it doesn't matter for now whether X is smaller or greater than the cost of developing in C++) we eliminate at 70% of security bugs. Now, there can certainly be a different approach that doesn't eliminate all UB and still reduces security bugs by more than 80%. I'm not saying we know for what that approach is, but what I am saying is that it is not at all certain -- it has neither been justified theoretically nor confirmed empirically -- that soundly eliminating all UB, which comes at some cost, is the best approach of reducing those bugs.

I, for one, believe that Zig's approach -- of language simplicity plus some strong safety features -- is a better approach to correctness than Rust's. I don't know that, I just believe that, but those who believe that Rust's approach to safety is better don't have stronger grounds to stand on.

So Zig does not trade off correctness; it trades of the sound guarantee for lack of UB, which isn't a goal in an of itself. It's a means to achieving some goal, and some may believe it's the best means, but there is so far little evidence to suggest that it is. Yeah, Rust is better than Zig at eliminating UB, but that doesn't mean it's better at correctness. It could well be worse.

> Perhaps, but I absolutely abhor C++ (after years of working with it) and completely love Rust, so :shrug:

Rust is an improvement over C++, but C++ isn't a hit in embedded development, either.

> I do think people keep looking for greener fields unnecessarily.

Why unnecessarily? You don't like C++ but found what you want in Rust; I'm not crazy about C++, either, but Rust doesn't even begin to solve my main problems with C++ (a "better C++" is not what I need), so why is my hope for greener fields less necessary than yours?

I would be happy if people gradually shifted from C++ to Rust -- at least we'll have fewer UBs -- but I don't think it will ultimately make a big change in low-level programming; maybe in some sub-niches of it.

I think Rust's emphasis on sound safety guarantees came at a cost elsewhere, and that cost is too heavy for some. Some like it, some prefer a different approach. I have no problem with people who like Rust, and they shouldn't have a problem with those who don't. Anyway, you asked why some might not see Rust as the answer to their wishes, and I answered.