5 ms·

I really like the Zig approach of improving the tooling for manual memory management rather than replacing manual memory management. I think Rust is a great, w

by skohan 6y ago

I really like the Zig approach of improving the tooling for manual memory management rather than replacing manual memory management. I think Rust is a great, worthy language, and for a lot of use-cases it makes sense to optimize for trying to just put everything on the stack, but there are a lot of other cases where what you really want to do is own allocation by yourself instead of trusting it to the compiler. I haven't tried Zig, but I really want to see if it can deliver on this.

whatshisface 6y ago
Rust has manual allocation with Box<T>, it's just not as automatic as Zig. Rust's manual allocation pain is constant-factor overhead: typing out the type signatures takes longer every time you use it, but the complexity doesn't grow beyond that. I don't enjoy typing Box everywhere, but it's not that bad. https://doc.rust-lang.org/std/boxed/index.html https://doc.rust-lang.org/std/boxed/index.html
- skohan 6y ago
  Rust allows virtually any type of memory management you want, my point is the syntax is not optimized for things like arena-based memory management or custom allocators. Rust assumes most of the time you'll be passing around references to values or small structures allocated on the stack.
  - whatshisface 6y ago
    Yes, that's quite right. For many purposes, that's helpful encouragement, but sometimes you just want a reference.
  - the_duke 6y ago
    In Zig, as far as I understand, you really just pass an allocator around. I don't see any special syntax to support this? This could be done in Rust. There is, for example, the simple bump allocator bumpalo [1]. It would be nice if the the std collections supported this (in planning, but hasn't seen much progress), and most dependencies would not be built around a manually passed allocator. > Rust assumes most of the time you'll be passing around references to values or small structures allocated on the stack. Can you clarify what you mean here? All of the std collections (Vec, HashMap, etc) use allocation. There are also `Box`, `Rc` and `Arc`, which allocate and are used everywhere. [1] https://github.com/fitzgen/bumpalo https://github.com/fitzgen/bumpalo
    - skohan 6y ago
      Again, it's not about what you are able to do in Rust vs. Zig, it's essentially about the API of the language. Zig's semantics around memory management are imperative: i.e. you are telling the compiler when to allocate and deallocate memory. Rust's are declarative: you tell the compiler how the memory for a given value should be managed, and the compiler interprets these requirements to decide when memory should be allocated or deallocated. Again, I do not think this a weakness of Rust, and I do not think it should change. In very many cases, the Rust approach is very helpful. The point is there are also cases where imperative, explicit memory management is desirable.
      - the_duke 6y ago
        > The point is there are also cases where imperative, explicit memory management is desirable. I agree that is the case, and Zigs convention of passing an allocator around and making those calls very explicit has merit. I think you are over-estimating the amount of "magic" in Rust though. The allocation-related logic is not part of the language or the compiler, but comes from the std (or alloc) crate. You just don't usually see a "malloc" call because it is hidden behind types in the standard library, which default to a global allocator. You still "manually" allocate by calling eg `Box::new()`. The only magic is that Rust calls a destructor ( Drop::drop) when a value goes out of scope. Types can implement drop and use it to deallocate or decrement a reference counter. This is made possible by using an affine type system with lifetimes and move semantics. This is conceptually not that different from doing something like `defer allocator.free(x)` in Zig, though less explicit. ps: I realize that conventions make a difference. But nothing in Zig would stop me from having a global variable with an allocator, and using that without passing it around.
        dnautics 6y ago
        > But nothing in Zig would stop me from having a global variable with an allocator, and using that without passing it around. That's correct and you probably should do that in your own applications, but it will be frowned upon in libraries, and people will not choose to use them if you make that choice. There's also another pattern, where you stuff a pointer to your allocator in your struct and have your "object" carry around its allocation system, you don't have to pass around allocators that way.
dnautics 6y ago
> I really like the Zig approach of improving the tooling for manual memory management rather than replacing manual memory management. The new test allocator checks your code for memory leaks, use after free, and double free in a highly ergonomic fashion. I think is fantastic that zig encourages writing tests, and I think if you get full test coverage in your zig code with the test allocator, you will probably solve 99% of your memory errors. I know this is possible in C++ (see alexandrescu's allocators talk from CppCon 2017?) But I would be surprised if anyone does it.
- fanf2 6y ago
  Address Sanitizer and valgrind are widely-used standard tools for finding allocation bugs
  - setpatchaddress 6y ago
    They are very effective, but relatively difficult to use.
    - pjmlp 6y ago
      On VS 2019, literally a checkbox away and rebuild.
    - chubot 6y ago
      They're built into both GCC and Clang and very easy to use IMO. The only hard part is figuring out how to pass -fsanitize=address into your compiler via your complex build system! And building with symbols. That is inherent to the C/C++ toolchain and not a problem that sanitizers can address.
      - samatman 6y ago
        Sure but a language where "the only hard part" isn't a factor surely has a leg up on one where it is. A lot of the advantage which Zig has over C is exactly in not having to support a towering edifice of tools and hacks which is older than I am. This is true to a significant degree of Rust and C++ as well.

by skohan 6y ago

whatshisface 6y ago

Rust has manual allocation with Box<T>, it's just not as automatic as Zig. Rust's manual allocation pain is constant-factor overhead: typing out the type signatures takes longer every time you use it, but the complexity doesn't grow beyond that. I don't enjoy typing Box everywhere, but it's not that bad. https://doc.rust-lang.org/std/boxed/index.html https://doc.rust-lang.org/std/boxed/index.html

skohan 6y ago
Rust allows virtually any type of memory management you want, my point is the syntax is not optimized for things like arena-based memory management or custom allocators. Rust assumes most of the time you'll be passing around references to values or small structures allocated on the stack.
- whatshisface 6y ago
  Yes, that's quite right. For many purposes, that's helpful encouragement, but sometimes you just want a reference.
- the_duke 6y ago
  In Zig, as far as I understand, you really just pass an allocator around. I don't see any special syntax to support this? This could be done in Rust. There is, for example, the simple bump allocator bumpalo [1]. It would be nice if the the std collections supported this (in planning, but hasn't seen much progress), and most dependencies would not be built around a manually passed allocator. > Rust assumes most of the time you'll be passing around references to values or small structures allocated on the stack. Can you clarify what you mean here? All of the std collections (Vec, HashMap, etc) use allocation. There are also `Box`, `Rc` and `Arc`, which allocate and are used everywhere. [1] https://github.com/fitzgen/bumpalo https://github.com/fitzgen/bumpalo
  - skohan 6y ago
    Again, it's not about what you are able to do in Rust vs. Zig, it's essentially about the API of the language. Zig's semantics around memory management are imperative: i.e. you are telling the compiler when to allocate and deallocate memory. Rust's are declarative: you tell the compiler how the memory for a given value should be managed, and the compiler interprets these requirements to decide when memory should be allocated or deallocated. Again, I do not think this a weakness of Rust, and I do not think it should change. In very many cases, the Rust approach is very helpful. The point is there are also cases where imperative, explicit memory management is desirable.
    - the_duke 6y ago
      > The point is there are also cases where imperative, explicit memory management is desirable. I agree that is the case, and Zigs convention of passing an allocator around and making those calls very explicit has merit. I think you are over-estimating the amount of "magic" in Rust though. The allocation-related logic is not part of the language or the compiler, but comes from the std (or alloc) crate. You just don't usually see a "malloc" call because it is hidden behind types in the standard library, which default to a global allocator. You still "manually" allocate by calling eg `Box::new()`. The only magic is that Rust calls a destructor ( Drop::drop) when a value goes out of scope. Types can implement drop and use it to deallocate or decrement a reference counter. This is made possible by using an affine type system with lifetimes and move semantics. This is conceptually not that different from doing something like `defer allocator.free(x)` in Zig, though less explicit. ps: I realize that conventions make a difference. But nothing in Zig would stop me from having a global variable with an allocator, and using that without passing it around.
      - dnautics 6y ago
        > But nothing in Zig would stop me from having a global variable with an allocator, and using that without passing it around. That's correct and you probably should do that in your own applications, but it will be frowned upon in libraries, and people will not choose to use them if you make that choice. There's also another pattern, where you stuff a pointer to your allocator in your struct and have your "object" carry around its allocation system, you don't have to pass around allocators that way.

dnautics 6y ago

> I really like the Zig approach of improving the tooling for manual memory management rather than replacing manual memory management. The new test allocator checks your code for memory leaks, use after free, and double free in a highly ergonomic fashion. I think is fantastic that zig encourages writing tests, and I think if you get full test coverage in your zig code with the test allocator, you will probably solve 99% of your memory errors. I know this is possible in C++ (see alexandrescu's allocators talk from CppCon 2017?) But I would be surprised if anyone does it.

fanf2 6y ago
Address Sanitizer and valgrind are widely-used standard tools for finding allocation bugs
- setpatchaddress 6y ago
  They are very effective, but relatively difficult to use.
  - pjmlp 6y ago
    On VS 2019, literally a checkbox away and rebuild.
  - chubot 6y ago
    They're built into both GCC and Clang and very easy to use IMO. The only hard part is figuring out how to pass -fsanitize=address into your compiler via your complex build system! And building with symbols. That is inherent to the C/C++ toolchain and not a problem that sanitizers can address.
    - samatman 6y ago
      Sure but a language where "the only hard part" isn't a factor surely has a leg up on one where it is. A lot of the advantage which Zig has over C is exactly in not having to support a towering edifice of tools and hacks which is older than I am. This is true to a significant degree of Rust and C++ as well.