Why I Chose Rust Over Zig

"A mutex is just a semaphore of length one." "A monad is just a monoid in the category of endofunctors."

Came to this channel for programming, stayed for the moustache

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.

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

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.

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

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

They forced us to make redblack trees by hand in our data structures course.

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.

The difference between Zig’s comptime and C++ templates and constexpr is that Zig’s stuff is unified. In C++, you can call constexpr functions at compile time to produce compile-time constants, e.g. for array sizes or template value arguments. Template stuff is declarative, constexpr function execution is imperative. That makes sense from where C++ is coming from, but modern language designers realized that the clear separation of types and values isn’t useful at compile-time. In Zig, types are values at compile-time. A function can have parameters that contain types as values and return types as values at compile-time. In C++ lingo, that would mean that not only can you write a consteval function that takes in something and returns a number (for an array bound), but also, you can write a function that returns a type to be used as a type for a run-time value. Essentially, type_info, at compile-time, isn’t meaningfully different than a type, so why have them be different things? In C++, there are function templates, class templates, value templates, and alias templates. In D, there are just templates that happen to produce functions, classes, values or aliases (which is a lot more streamlined), and in Zig, there are no templates, but functions that shove types around as if they were values. Sorting types (at compile-time)? No harder than sorting values at compile-time, which is no harder than sorting values at run-time. Why copy values and alias types? If a type is a value (which it is at compile-time), an alias of a type is exactly a (const) copy of a type. So in Zig, things that are separated for no good reason (in hindsight) aren’t separate. The only difference between types and other values is that types don’t exist at run-time, which means if you’d end up with having to run a function that manipulates types at run-time (e.g. because of a run-time value argument), the compiler will complain.