> "WASM support was just as smooth in Rust as in Zig".<p>There are still way too many Rust dependencies that don't support WebAssembly, and even functions in the standard library that compile but will crash at runtime on WebAssembly. And if a dependency requires C code, `cargo-zigbuild` is required to compile it anyways.<p>My experience with Zig is that pretty much everything compiles out of the box to all the supported targets, and works the same way. This includes code using SIMD.<p>I also like the fact that the code can be optimized for the runtime's feature: adding -mcpu=baseline+simd128 compiles everything for wasm runtimes with support for SIMD, including the C library ("wasi-libc"). This is not specific to the wasm target, but the fact that even the libc is recompiled with the same optimization flags as the rest of the code is neat. You can really optimize the code for speed, size or a specific target.<p>WebAssembly modules compiled from Zig code are also very small and memory efficient, without being forced to use a "[no_std]" mode. That can make a big difference if you have to distribute them, or are billed according the resource usage.<p>> The Zig build system is amazing and 100x better than our makefiles.<p>This.<p>People often think Zig is just a language. But it's a toolchain, that can be used even for code not written in Zig.<p>It's a fantastic replacement for makefiles / CMake / ccache / hacky shell scripts, with seamless cross-compilation and webassembly support.
I have written some rust I like it. I prefer GO for day to day but I wont turn my nose up at Rust...<p>Cargo on the other hand... I saw someone say "Rust is turning into the language that tokio ate" ... and this is a cargo shortcoming.<p>Zig dependency management feels more Go like, and in my book thats a good thing. I like decentralized.<p>Zig is going to be what I build my next "fun" project in. Im actually excited to spend that time when I find it. I haven't felt that way about something new in a long time.
This feels very shortsighted to me.<p>"Easy to learn" and "easy to hire for" are an advantage in the first few weeks. Besides, we now have data indicating that ramp up time in Rust is not longer than in other languages.<p>On the other hand, serving millions of users with a language that isn't even v1 doesn't seem very reasonable. The advantages of a language that is memory safe in practice and also heavily favors correctness in general boosts productivity tenfold in the long term.<p>I'm speaking from experience, I switched from C++ to Rust professionally and I'm still not over how more productive and "lovable" the language in general is. A language like zig isn't bringing much to the table in comparison (in particular with the user-hurting decisions around "all warnings are errors, period")
These kinds of posts can pretty much always be summerized down to that is what we wanted to use. The arguments are very weak and unconvincing.<p>People love to say, use the right tool for the job but no one actually does it.<p>Developers will use what they know or what they feel comfortable using.
I think it's interesting to observe the development speed of Bun vs Deno when comparing Zig and Rust.<p>Bun is written in Zig and links to the WebKit's JavaScriptCore.<p>Deno is written in Rust and links to V8.<p>It seems to me that the development of Bun is significantly faster than Deno, how much of that is down to the easy of interoperability of Zig and C/C++ vs some of the hoops you have to jump though when using Rust with a C/C++ lib?<p>(I may be wrong on this an the Bun team are just exceptionally quick)
> Zig works with debuggers our developers know out of the box.<p>Is this not true of Rust? I use lldb via terminal and VSCode with Rust, I am not sure what I'm missing.
Zig is basically a more ergonomic C while Rust is an entirely different memory-safe language. I don't see why Rust would ever get picked over any other language if high-performance memory safety isn't a priority. And, if it IS a priority, I don't see why anyone would pick any language other than Rust.
C-interop while certainly more involved in Rust compared to Zig, it is generally a one-off effort (for most projects). wards it's generally an incremental effort to map additional C code. I am not sure I would make this an important factor but to each his own.
> Memory safety and "no undefined behaviors" (obviously untrue, but that was the belief and part of the conversation we had to have<p>Trying to better understand this claim, is it because also unsafe rust exists?
A question for those who are in the Zig camp.<p>I've heard talks that zig is now mostly stable and there are no big api changes expected but I haven't been able to find any official statement on that, is this true?