How (memory) safe is Zig? (2021)

You don't have to query all checks at all times. You only have to borrow check when you pr to main. What is the sum latency of the coder dealing with conceptual problem of satisfying the borrow checker at every stage during an arduous refactor where they don't fully have the destination model in mind (and might want to try things out only to discard them). Versus, just ignoring it, seeing how the chips fall, and fixing ownership errors in one or two passes at the end once you've settled om the code structure? Of course you don't have to take the full round trip-to-someone-else's-computer latency either. If you can run it in CI, I presume you could run it locally too, and borrow checking is not particularly slow for the computer.

You're also not (because one can't) quantifying the problem of a developer getting exasperated and saying, fuck it, it passes the borrow checker, good enough, instead of actually taking the time to make their code legible first and then making sure it is memory safe. This absolutely happens.

your argument doesn't hold water, because you are appealing to the existence of a schroedinger's programmer that simultaneously would use rust but also wouldn't turn on a borrow checker if it existed in another language.

My point is the fact that people use Rust means that people do care. And those people will run static analysis checks (as long those static analysis checks aren't the shitty or overly difficult to run), and they will notice that your library isn't checked. Or, better yet, they will integrate it into their project, run the checker on their project, find the problem in the lazy person's dependency and PR a fix or fork it if the maintainer is an asshole.

Here's the thing. Rust is currently "the only game in town" for spatiotemporal memory safety and that is sucking the air out of the atmosphere, because no one wants to invest time into trying other ideas. And that's a shame, because everyone makes assumptions that Rust must be the only way to do spatiotemporal safety (cough cough Ada/Spark). And it gives cover for people to claim things that are presumptuous and totally untested like our schroedinger's programmer here.

Rust has a lot lot lot of shitty things in it, like RAII, and proc macros, and pushing you into some incredibly complicated (and privileged) templated types that are doing some things under the hood (remember when rust switched from jemalloc to malloc?), and Rust hasn't ever gotten to keyword generics yet. Those of us who don't want that kind of BS in our language have to constantly be accused of not caring about memory safety which is hardly the truth.

> your argument doesn't hold water, because you are appealing to the existence of a schroedinger's programmer that simultaneously would use rust but also wouldn't turn on a borrow checker if it existed in another language.

I'm appealing to the existence of people who would like rust very much, but find the borrow checker to be cumbersome / annoying / difficult. I suspect a lot of people would fall into this camp. Including a lot of people who admire Zig, Jai, Odin, dmd. And probably a lot of C++ developers.

In my opinion, most of the best parts of rust have nothing to do with the borrow checker. For example, sum types, the rust standard library, cargo & crates.io, traits, Result / Option, editions, rust's unit testing, etc.

If someone released a borrow checker for zig, would it get 100% adoption? No way. Especially if it was hard to learn, required adding unfamiliar "lifetime annotations" throughout your code and sometimes required you to refactor functions that you know are correct anyway.

> Here's the thing. Rust is currently "the only game in town" for spatiotemporal memory safety and that is sucking the air out of the atmosphere, because no one wants to invest time into trying other ideas. [...] Those of us who don't want that kind of BS in our language have to constantly be accused of not caring about memory safety which is hardly the truth.

I think we've found agreement. I've been saying this for years - Rust is humanity's first serious attempt at a programming language like this. Its like the first iPad. I think there's lots of ways a rust successor could learn from rust's mistakes and make a better language. I'm really looking forward to what a borrow checker might look like a few more languages down the line.

Welcome to the magic of Zig, where ideas that can't actually work actually do work :-)

    const std = @import("std");

    pub fn main() !void {
        var not_heap_memory: [1024]u8 = undefined;
        var fixed_buffer_allocator = std.heap.FixedBufferAllocator.init(&not_heap_memory);
        const allocator = fixed_buffer_allocator.allocator();
        var my_list = std.ArrayList(i32).init(allocator);
        defer my_list.deinit();

        // notice the try! allocation may fail!
        try my_list.append(1);
        try my_list.append(2);
    
        for (my_list.items) |d| {
            std.debug.print("{}\n", .{d});
        }
    }

The value here is not that you have unbounded stack memory - obviously. The value is that you can use the same API for a growable list (std.ArrayList) backed by stack memory, as you would for a growable list backed by heap memory. This could be useful if you have a function that accepts an ArrayList as an argument and will append to it, but you have a known maximum size for the ArrayList in the context that you're using it. You cannot use the standard Vec type in the same way in Rust. You cannot use any data structures from the Rust standard library that do allocations in the same way.

Yes, of course, you can make data structures that accept custom allocators in the same way in Rust. Maybe there are even community libraries that do it already. The problem is that because they're not in the standard library, you're going to have a hard time using those data structures with any other community libraries. And thus, in practice, you have less control over your allocation strategies in Rust than you do in Zig.