Zig; what I think after months of using it

Post by Ygg2 » Wed, Feb 05, 2025, 8:58 PM UTC

throwawaymaths wrote: post #145

Ygg2 wrote: post #120

Earlier quoted context omitted.

> it appears the clr author anticipated you: you didnt fork it, try, and fail, so you have ceded the authority to credibly make your speculative complaint That's a caveat. Not an expectation. Plus that's not how proof works. Neither Zig nor Zig+Clr have really proven they are safe, ergo they are unsafe or possibly safe (respectively).

wow what are you afraid of. you're working really hard to tear down something that is an incomplete proof of concept.

Post by oneshtein » Thu, Feb 06, 2025, 12:33 AM UTC

mk12 wrote: post #146

oneshtein wrote: post #135

Earlier quoted context omitted.

For Rust references, rules[0] are not hard to follow: The pointer must be properly aligned. It must be non-null. It must be “dereferenceable”: a pointer is dereferenceable if the memory range of the given size starting at the pointer is entirely contained within the bounds of that allocated object. Note that in Rust, every (stack-allocated) variable is considered a separate allocated object. The pointer must point to…

One reason it’s harder to follow is you can’t have references to uninitialized memory. In Zig pointers to uninitialized memory are fine as long as you don’t dereference them. That’s also true of Rust’s raw pointers, but most Rust code uses references, so it can’t be reused in unsafe contexts. As a concrete example, I previously used Vec in unsafe code that dealt with uninitialized memory. This should be fine because…

    pub const unsafe fn as_uninit_ref(self) -> Option>
    where
        T: Sized,
    {
        // SAFETY: the caller must guarantee that `self` meets all the
        // requirements for a reference.
        if self.is_null() { None } else { Some(unsafe { &*(self as *const MaybeUninit) }) }
    }

Post by dustbunny » Thu, Feb 06, 2025, 3:53 AM UTC

pcwalton wrote: post #121

tapirl wrote: post #96

Earlier quoted context omitted.

Zig might not become very popular, but IMO, it will become more popular than Rust. Zig is good at all the areas Rust is good at. Zig is also good at game development which Rust is not good at. And Zig is better when integrating with C/C++ libraries.

> Zig is good at all the areas Rust is good at. Not memory safety. > Zig is also good at game development which Rust is not good at. Let's see. Over just the past year in Bevy I've implemented GPU driven rendering, two-phase GPU occlusion culling, specular tints and maps, clustered decals, multi-draw, bindless textures, mixed lighting, bindless lightmaps, glXF support, skinned mesh batching, light probe clustering, v…

Post by antonvs » Thu, Feb 06, 2025, 4:52 AM UTC

lnenad wrote: post #37

antonvs wrote: post #26

Earlier quoted context omitted.

It’s been a feature in languages for at least half a century. Scheme’s lexical scoping supported it in 1975, and Lisp adopted that.

Yeah, it's a feature of a language, doesn't mean we are forced to use it.

Post by dolmen » Thu, Feb 06, 2025, 2:45 PM UTC

hoelle wrote: post #57

> Zig does enhance on C, there is no doubt. I would rather write Zig than C. The design is better, more modern, and the language is safer. But why stop half way? Why fix some problems and ignore the most damaging ones? I was disappointed when Rust went 1.0. It appeared to be on a good track to dethroning C++ in the domain I work in (video games)... but they locked it a while before figuring out the ergonomics to make…