Why I Chose Rust Over Zig

Recorded live on twitch, GET IN

### Article

### My Stream

### Best Way To Support Me
Become a backend engineer. Its my favorite site

This is also the best way to support me is to support yourself becoming a better backend engineer.

MY MAIN YT CHANNEL: Has well edited engineering videos

Discord

[NeilHaskins]

"A mutex is just a semaphore of length one."

"A monad is just a monoid in the category of endofunctors."

[OutBoXeR]

Came to this channel for programming, stayed for the moustache

[LtdJorge]

I think "If it compiles, it works" should be reworded to something like "if it compiles, it does what you described". If what you described is wrong, then the output will be wrong, but that's not really a bug, it's just wrong logic. Rust eliminates, by default, the ambiguity that unsafe code can carry. You could have described the correct algorithm, but have data races which do introduce bugs, for example.

[knlcpov]

5:00 It appears that Prime mistakenly interprets the phrase 'If it compiles, it works' to mean 'If it compiles, it works correctly.' However, no one using this phrase believes that programs written in Rust or Haskell are free of logic bugs. Instead, it means that a compiled program won't crash unexpectedly due to issues like mismatched types, use-after-free errors.

[seiakari]

I read the title as "Why I Choose Rush over Zerg", and I thought that didn't make a lot of sense.

[christopher]

If it compiles, then all that is remaining is business logic bugs. I like that

[DmitryVoytik]

Prime, if your worst bugs are logical bugs, it simply means you write code in dynamic languages. Worst bugs in C are silent memory corruption and data races. Only C system SW engineers know what heisenbugs are not by reading memes, but spending days trying to debug them.

[brod]

@3:00 "when you have a black uncle you have to do something"...
as a black person... FACTS!

[freeideas]

I object, your honor, to calling debugging tricky memory issues in C/C++ code, a "skill issue". The best C/C++ programmers in the world have this problem. So, unless "not having god-like omniscience" is considered a "skill issue", then this is not a skill issue. It is a language issue. I'm not saying it is a language issue that isn't worth the extra work. Not saying we should all stop with C/C++, just saying that isn't exactly a skill issue.

[stysner]

I really don't get the point of hating on "if it compiles it works"... It eliminates a type of bug completely, the logic bugs are there in any language?

[callumbirks]

Re; “If it compiles, it works”;
As someone who comes from C/C++ like Pekka, this definitely *feels* partially true in Rust. Yes logic bugs are still a problem, but in my experience most of the bugs I have to deal with in C++ are memory errors (working with low level systems programming). Almost all of these are compiler errors in Rust.

[jmw]

I just love Rust, that’s not going to change

[nateb]

Most of my career was also C in the kernel (Windows kernel in this case). You get really good at C after years and rarely code bugs of the security-vulnerability nature. There are linters and safe string libraries and stuff like that to make things safer. The book "Writing Solid Code" set me on the right path early on.

[lawrencejob]

To distill the author’s point, they pint out that Zig doesn’t have a dedicated type (meta) language for types because Zig is used for both metaprogramming and programming. The argument for making the type language the same as the main language is that you don’t have to learn two languages and the interplay is good. The argument against is that a meta language might have different requirements and benefit from being a different language (usually declarative, different primitives like, say, Type)

[julkiewicz]

Dude, that's not true that ownership is not a biggie. It is a biggie. Especially in a kernel environment where you have to worry about concurrency, reentrancy (you could call user code and then be called again from that user code). The hardest to find bugs, are by far those to do with memory safety. Because ultimately you're not writing a closed system where you have control over everything. You're writing an open system where most of the running code is user code, or kernel module code. It's incredibly hard to reproduce issues. It's much much easier to fix invalid logic bugs than memory management bugs in such an environment.

[DrGeoxion]

Async Rust doesn't use green threads though. It's agnostic.
Sure, Tokio's runtime for async uses green-ish threads, but that's not the only runtime!
You can use async on embedded devices without allocators and without OS threads too.

Async Rust really is just polling objects and having wakers that can notify the executor to poll again. Anything more than that is runtime specific and is different for each runtime you may use

[zaper]

NGL "I prefer the pre-proccesor over Zig comptime" is such a insane take I genuinely feel like it invalidates the entire article.

[LusidDreaming]

If you build any heavily concurrent system, I think ownership actually does cause a lot of bugs. I worked on an engineering simulation software that did a ton of concurrent calculations, some of which were interdependent, and the two biggest classes of bugs I dealt with were serialization issues (more related to networking) and data races.

Even currently, working in the cloud, i deal wih more race conditions across services than logic bugs. I feel like the majority of logic bugs were found early on in testing because they are typically deterministic and thus easily reproducible. But with race conditions, there have been a handful where they were seen, but then couldn't be reproduced, and the QA engineer would end up getting gaslit into thinking they must've just not executed the test correctly.

[ralph_d_youtuber]

The mentality of doing things "the Rust way" is real. Even when I go back to writing Java for school work, I now prefer using interfaces and enums over inheritance. Additionally, I make sure that all nullable objects are wrapped in an Optional.

[BosonCollider]

The main complaint I have about zig is that in industry it is kind of difficult to push over just using a linter-enforced subset of C++ or Swift. It is an incremental improvement over C but it doesn't provide a fundamentally new capability that you can't get from any of the million of other C replacements that have popped up over the years (Ada, D or Nim without GC, V, Odin, Pascal, Delphi, fortran, C2 and C3, Holy C, and the list just goes on and on, also holy C is cooler than zig).

Rust on the other hand genuinely does provide a new capability (non-GCed language with memory safety). Yes, it can be painful to write it, and yes I wish it were smaller and closer to what Greydon originally wanted, and yes you should probably just use threads instead of async/await, but at least I can immediately explain what the point of it is, and parallel (not concurrent) code with Rayon is better than pretty much any alternative I've seen.

If you want a better C that is simple like Go, I like C3. It's a sane "fixed C" that does not try to do everything like C++ and just removes the obviously broken C footguns by making things defined, adds defer, interfaces, slices, odin-like error handling, and Go-like build tooling, while staying fully ABI compatible. If you want a C that is a bit more like Go, that's what I would suggest.