When Zig is safer and faster than Rust: I recently wanted to compare Rust vs Zig, so I wrote a garbage collected bytecode interpreter in both languages It turned out that the Zig version was actually faster AND safer than the Rust version How come?
Garbage collection is a hard problem to solve in Rust, it fundamentally is something that doesn't play nicely with the borrow checker. It's possible to write one in safe Rust, typically using refcounting or arenas+handles, but those seem to be slower than a typical mark/sweep gc
@zack_overflow Alas, consistent with my experience that writing unsafe C++ is easier than writing unsafe Rust. I think the key thing is the Rust aliasing model is *too strong*. As you say in your post, you have to avoid forming refs, which kills ergonomics and is too easy to do by accident.
@zack_overflow Interesting post, I agree that writing unsafe rust is difficult. A point you don't cover in the post is how unsafe rust is expected to be encapsulated behind a safe interface, which considerably adds to the difficulty of writing unsafe Rust.
@zack_overflow Thank you! It's so refreshing to hear someone admit "well I tried for a while but I couldn't figure it out so I gave up" -- it's something that computer (language|system|software) designers *really* need to take to heart when considering why not everyone uses their darling.
@zack_overflow Good project. I doubt the pointer arithmetic in Rust accounts for it all, as those are nearly zero cost with pipelining and instruction scheduling these days. I would guess some extra bounds checking or something.
@zack_overflow @pietmichal Interesting, thanks! I wrote a GC a few years ago in C and expected to use it for my current language project. But things have evolved since, so I wanted to give Rust a try, but after reading your post I think I'll go with Zig instead as it seems more relevant for this task.
@zack_overflow it takes a certain kind of person to test performance and safety by writing a garbage collected bytecode interpreter
@zack_overflow It seems that you've tried to write zig/c++ style code in Rust, which is a bad idea. First of all, I saw `enum Obj` just as enum, and then you store it inside each kind. The usual way to do that in rust in reverse: enum Obj { Class(ObjClass), //etc }
@zack_overflow as a relative peasant in both, I'd love to hear what @ThePrimeagen and @jarredsumner have to say here.
@zack_overflow In your second tweet you straight up say “I had to use unsafe Rust” and then try to say that Zig is safer. Neither of them are safe.
@zack_overflow but, more importantly, how does it compare to Java? *ducks*
@zack_overflow Nice analysis, thanks for sharing! Have you found other cases where Zig is also safer, faster and/or easier to write?
@zack_overflow Ok! What?! Versus the Cs, Rust boons speed; but this result bucks it from the gradient! Flouting tramples, speed brings more Ls; but Cs are clunkier, slower, and more error-prone! How the fuck does Rust slam it’s borrow-checking iron fist between?!? How is real Zig code faster?!
@zack_overflow Basically the what I've been saying too.
@zack_overflow thoughts on mmtk? they have since pretty advanced gc with in rust.
@zack_overflow I have written around a dozen byte code interpreters/runtimes in my career. I never needed GC for any of them. Care to elaborate a bit on the use case?