5 ms·

Can you clarify your point?

sigzero 5y ago
Probably related to the following: https://github.com/ziglang/zig/issues/3180 https://github.com/ziglang/zig/issues/3180
- wyldfire 5y ago
  Gee, IIUC it looks like it's been addressed by offering a new allocator that's able to detect use-after-free.
  - kristoff_it 5y ago
    To be fair this alone is nowhere near what Rust can do for you in terms of safety.
    - wyldfire 5y ago
      But Zig makes this tradeoff intentionally. By design.
      - kllrnohj 5y ago
        "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?
        adamdusty 5y ago
        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.
        matu3ba 5y ago
        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. 5. Not all UB during comptime or runtime is (planned to be) checked/checkable https://rust-lang.github.io/rfcs/3016-const-ub.html https://rust-lang.github.io/rfcs/3016-const-ub.html
        roca 5y ago
        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/value.rs 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? But anyway, none of these are reasons to use Zig.
        matu3ba 5y ago
        1. Union is used to dynamically interpret data of an underlying buffer or memory segment. You will find union as being inherently unsafe in Rust: https://doc.rust-lang.org/reference/items/unions.html https://doc.rust-lang.org/reference/items/unions.html 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.
    - ngrilly 5y ago
      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.
      - matu3ba 5y ago
        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.
        ngrilly 5y ago
        Did you mean Zig? I don’t understand how Rust code can leak memory?
        steveklabnik 5y ago
        https://doc.rust-lang.org/std/boxed/struct.Box.html#method.leak https://doc.rust-lang.org/std/boxed/struct.Box.html#method.l...
  - pjmlp 5y ago
    So can debugging tools for C and C++ since late 1990's, zero progress there.

Probably related to the following: https://github.com/ziglang/zig/issues/3180 https://github.com/ziglang/zig/issues/3180

wyldfire 5y ago
Gee, IIUC it looks like it's been addressed by offering a new allocator that's able to detect use-after-free.
- kristoff_it 5y ago
  To be fair this alone is nowhere near what Rust can do for you in terms of safety.
  - wyldfire 5y ago
    But Zig makes this tradeoff intentionally. By design.
    - kllrnohj 5y ago
      "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?
      - adamdusty 5y ago
        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.
      - matu3ba 5y ago
        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. 5. Not all UB during comptime or runtime is (planned to be) checked/checkable https://rust-lang.github.io/rfcs/3016-const-ub.html https://rust-lang.github.io/rfcs/3016-const-ub.html
        roca 5y ago
        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/value.rs 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? But anyway, none of these are reasons to use Zig.
        matu3ba 5y ago
        1. Union is used to dynamically interpret data of an underlying buffer or memory segment. You will find union as being inherently unsafe in Rust: https://doc.rust-lang.org/reference/items/unions.html https://doc.rust-lang.org/reference/items/unions.html 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.
  - ngrilly 5y ago
    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.
    - matu3ba 5y ago
      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.
      - ngrilly 5y ago
        Did you mean Zig? I don’t understand how Rust code can leak memory?
        steveklabnik 5y ago
        https://doc.rust-lang.org/std/boxed/struct.Box.html#method.leak https://doc.rust-lang.org/std/boxed/struct.Box.html#method.l...
- pjmlp 5y ago
  So can debugging tools for C and C++ since late 1990's, zero progress there.