To some extent. Rust, due to relying on LLVM, is limited by its available targets; and so cannot enjoy the full access that C/C++ can. The same is true for Zig, however, since it does not compile to C.
The author is not under any such impression. The key point is that Zig can cross-compile C/C++ code, while Rust can't. If you have a Rust project that depends on C code, you will have to put in some work if you want to compile it for a different target.
That's a pretty big difference in practice. The point about the Python package example is not to say that Zig can get on platforms where Rust can't, but rather that the C infrastructure that we all use is not that easy to replace and every time you touch something, regardless of how decrepit and broken it might have been, you will irritate and break someone else's use case, which can be a necessary evil sometimes but not always.
This is a point I made in the section of the blog post dedicated to explaining the limits or rewriting code.
> since it does not compile to C.
Give it some time, it will.
> If you have a Rust project that depends on C code, you will have to put in some work if you want to compile it for a different target.
Rust is built on LLVM, and so its toolchain can also cross-compile C/C++ code. There are crates for that[0], and projects inspired by that idea[1].
> Give it some time, it will.
Given enough time mountains become valleys. Zig doesn't compile to C now; and won't be mature and field-tested for a decade or more.
"This crate calls out to the most relevant compiler for a platform, for example using cl on MSVC."
But why do I care? I don't use rustc directly, the build system of choice does. And very few of the major build systems have an issue handling multiple languages.
Cargo (rust's build system) supports build scripts and the community has already created C/C++ compiler hooks such as https://github.com/alexcrichton/cc-rs
rustup and cargo also provide easy cross-compilation support, too.
I quoted from cc’s readme above.
I haven't had this experience with any other language. When a package manager lands, you won't even have to install any SDKs by hand anymore.
So if you can't use Rust because it doesn't have the broad compiler support that C does, you almost certainly can't use Zig either for the exact same reason. And then the article touts Zig using their own in-house linker, which seems inevitable to have less platform support than LLVM will? Zig isn't wrong for doing that, but you can't claim that's a benefit at the same time the problem with Rust is it's lack of fringe system support... :/
ZLD can link for M1 while LLVM can't yet. And Zig can also use lld alongside it to increase the platform coverage.
> but you can't claim that's a benefit at the same time the problem with Rust is it's lack of fringe system support... :/
I find it hard to believe that a dispassionate reader could misinterpret to this degree the goal of a sentence written in a chapter dedicated entirely to showcase the limits of rewriting code in another language, be it RIIR or RIIZ.
See my reply to the parent comment for the intended meaning of that example.
As much as I lean on thinking Zig will achieve it first it seems unfair to make claims about things that haven't been done in a language that hasn't even been finalized as reasons it's better than a stable language in the same boat at the moment.