I think you're both asking the same question from different angles. If I understand correctly, and I could be misremembering but Zig is supposed to be compatible with C++ not just C, which is something that is not necessarily straight forward in other C / C++ competing languages. I hear even D has some issues with mangling and what not.
In all honesty, I prefer the syntax of D over all the others, it feels the most like Java or C# but with a lot of modern benefits. D is trying to do too much though it feels like and I would love for the next D standard library to support OOTB similar to what Go supports, especially a very minimalist web server, I think all modern programming languages should be capable of spinning up web servers out of the box. This is one small detail Go got right in my opinion.
Here's an article from the Chromium team on challenges they faced with trying to integrate Rust (or at least evaluating it) note the entry was last updated in 2020:
D nim and a few others offer nicer syntax over what's normally C for sure. Yea it doesn't surprise me that an established product had trouble incorporating rust, but at the same time, there's a reason why they went through with it right? Memory safety, no data races, etc. Like there is a motivating reason for using it. Meanwhile lots of other products have found ways of integrating Rust and some of them are risk averse products.
I like that the web server in Go's standard library comes as a library, so you can embed a web server into your application, even if it otherwise isn't web-related at all, just to allow for some introspection and/or control.
(To be fair, I think Python and Ruby have HTTP servers in their standard libraries as well, at least minimalist ones.)
I see where you are coming from, zig is easier to learn, but zig doesn't offer what rust does with respect to safety. That feature is so hard for me to ignore. I respect it though, some people want to be up and running with a new technology in a day or whatever, rust doesn't give you that unless you are very seasoned.
Honestly many applications don't need the level of safety that rust provides (for small single threaded cli apps or cloud lambdas, just allocate into an arena and throw everything away when the program quits, no UAF or DF because you're never freeing)
At the other extreme, if you're writing an operating system or a language VM, you probably want contextual allocators (like an allocator that takes a runtime argument like "which green thread I'm allocating on") which rust makes extremely difficult.
If you really need memory and resource safety I think the best answer is to be patient. Zig is very easy to parse and I imagine it will be the case that static analysis build tools will come about which can do what you want out of rust.... Being decoupled from the compiler chain you would be able to run fast but guard your prs to main/dev/release (as you see fit) with static analysis tools that will protect you with the safety you seek in an isomorphic fashion to "how rust does it". There's no reason why someone couldn't write it now, but with a lot of things (like ZIR/AIR) being highly unstable -- and these are what you're likely to want to statically analyze for such a tool -- for ones sanity I don't recommend building out a tool like that now.
I actually disagree with that and think it encourages bad practices in people who don't know better. The rise of fuzz testing on these old c applications following this kind of mentality is a constant source of cves . Why expose users to problems, if it's easy not too?
Also it's not like that safety costs much of anything. You really can get comfortable writing rust, especially "easy rust" like a single thread cli app. It really is easy, even convenient.
Either zig is a different tool to rust, in which case I get it. Or people should be waiting for zig to be mature, meanwhile rust has been stable for half a decade, and at this point "just works". I'm not going to sit through an addendum static analyzer and all the bugs that come with making one for a few years. Other people whose appetite for risk is higher will though, and I wish them the best. I've seen efforts in other languages, my conclusion is that it's much better to have it built in...
In all honesty, I prefer the syntax of D over all the others, it feels the most like Java or C# but with a lot of modern benefits. D is trying to do too much though it feels like and I would love for the next D standard library to support OOTB similar to what Go supports, especially a very minimalist web server, I think all modern programming languages should be capable of spinning up web servers out of the box. This is one small detail Go got right in my opinion.
Here's an article from the Chromium team on challenges they faced with trying to integrate Rust (or at least evaluating it) note the entry was last updated in 2020:
https://www.chromium.org/Home/chromium-security/memory-safet...