I'm not close to Zig development, but in addition to the GeneralPurposeAllocator work that a comment already links to, there is other ongoing stuff in that space, like an allocator in 64-bit that does not reuse pages (and instead keeps using new addresses in the "infinite" 64-bit space).
There are also known techniques like Type-After-Type that can avoid use-after free in C and C++ [0]. And also advances in hardware like ARM MTE [1]. Those things - and GPA, and not reusing 64-bit pages - have various tradeoffs in terms of overhead, but Zig is a developing language that has a chance to explore possibilities that C and C++ can't. So this is an interesting area to follow.
Seriously. You get these tests for free with zig, no extra tooling, if you use testing allocator in your tests. This also is a carrot to get you to write tests. Hell, I even mocked libc's malloc/calloc/free to make sure that my code doesn't leak memory:
Rust does not free you from having to track memory, for large classes of important data structures. And, if you want to implement smart pointers for your app in zig, it is easy.
Yes, your examples are two proprietary, nonstandard techniques. Or alternatively using a third-class toolset (jemalloc toolkit e.g ).
Sanity is having a single, anointed way to do it in the stdlib.
Any plans to go one step further towards memory safety (and even better data race freedom)? Maybe using ARC when the overhead is acceptable (like Swift), it static analysis is not possible due to the type system not supporting the concepts of ownership, borrowing, lifetimes and so on?
Zig is super exciting, but without a GC or Rust type system, I’m worried about going “back” to a language where I have to think about memory leaks, use after free and so on.
As of now the tradeoff of Rust's type system is that code may leak memory and you may need to investigate all occurrences to fix it, because there is no tooling yet (testing everything is infeasible).
You can have either extensive static analysis or fast compile times. Tracking ownership down to semantic analysis (where type layouts are in resolved form) requires adjusting and slowing down the complete compiler.
"It's intentionally less safe! That's why you should use it!"
Zig may strike a better balance than Rust does here, but it seems more like Rust stole its lunch. I don't know why I'd migrate from C/C++ to Zig instead of going all the way to Rust?
1. Rust doesnt let you safety-check bit-compressed stuff and instead relies on well-formed types during runtime (basically everything that union allows).
2. Graph memory patterns in Rust are completely unsafe.
3. Code might leak and you dont have tooling to check your dependencies. Trusting the test coverage does not help you there with Rust, because Rust tooling is infeasible for testing leaks.
4. CTFE is not easy to track in Rust, so you dont know if certain code may have run-time cost or not.
1. Unclear what you mean. You can manipulate bits of scalars without writing unsafe code. You can't do bit manipulation of pointers without writing unsafe code. You can write a small library that packs pointers with unsafe code, and then use it safely everywhere you need it. See https://github.com/rpjohnst/dejavu/blob/master/gml/src/vm/va... for example.
2. Wrap up the unsafety in a library like petgraph and use it. Or just use petgraph.
3. jemalloc's leak analysis works with Rust, as does Heaptrack.
4. With const generics it's trivial to pass a value through a const generic parameter to ensure it was evaluated at compile time. Right now that only works for scalars but that limitation will be relaxed later.
5. Most Rust code is safe code which is free from UB. Dynamic checks of all unsafe-code UB is infeasible. So what?
2. petgraph looks like they only allow allocating and freeing in the same order and no deallocating of segments (think of a graph pointing to another graph) dynamically. So even if you wrap it, you cant arbitrarily deallocate and allocate things upon semantic conditions.
3. It would be more helpful to use static analysis or making functionality with potential leaks similar to have this information on code review instead of trying to test all code paths.
4. True. I think that works then. Looks like between Rust and Zig "const equals comptime".
5. "Dynamic checks of all unsafe-code UB is infeasible." It is only infeasible, if you dont have an idea on the memory model during comptime. The RFC also writes "In particular, this would mean we need to decide on an aliasing model before permitting raw pointers in CTFE.", because Rust is not settled on that yet. On the upside, this speeds up compilation, lol.
1. f32::from_bits/to_bits etc allow safe bit-casting between primitive types. Libraries like safe-transmute wrap up unsafe array pointer casts into safe APIs. Rust has great tools to address the use-cases where C would use unions.
2. The big picture here is that for graphs and other data structures, you figure out a safe API for the data structure and write a library that hides the unsafety behind that API (or just use a library that someone else already wrote). You get a clean separation between a small amount of unsafe code and a large amount of safe code. This is the Zen of Rust and it's why "Rust can't express <XYZ> safely" is almost never an important issue in practice.
3. Rust's ownership and determinstic destructors mean you really have to go out of your way to create a memory leak; "just forgot to free it" doesn't happen. A memory leak has to be something nontrivial like a global data structure that is added to but not removed from, or a reference-count cycle that isn't broken. There aren't really good automatic static techniques for detecting these AFAIK (and I have a background in static program analysis) --- you would need something that models heap states over time, like shape analysis, which doesn't scale. As far as I can tell Rust at least as strong as any other real-world non-GC language at preventing memory leaks, certainly stronger than Zig which lacks ownership and destructors.
5. This is an issue I don't know much about so I'll leave it.
FWIW the endgame for unsafe code in Rust is formal semantics for unsafe code, proof obligations that guarantee the unsafe code preserves Rust safety invariants, and proof-assistant tools that let you formally prove the safety of your "unsafe" code. There's a lot of work to get there but that work is well underway.
You wouldn't because you already know Rust. The mental overhead of Zig is essentially zero if you already know C. Also, generics and other syntax is cleaner in my opinion, but that doesn't matter that much.
