3 ms·

Isn't Zig's repetitive ceremonial code around allocators+ allocation + defer *.deinit() a sign of a serious shortcoming like golang's error handling? If zig is

by blubber 9mo ago

Isn't Zig's repetitive ceremonial code around allocators+ allocation + defer *.deinit() a sign of a serious shortcoming like golang's error handling? If zig is so good at metaprogramming, why isn't there a metaprogramming solution to this repetitive code?

jordand 9mo ago
Memory allocations are always done explicitly (nothing is hidden or implicit). I've not written enough Zig yet to appreciate that, but I've hit plenty of those issues year-after-year with C++ to know their approach is sane and rational.
- Measter 9mo ago
  Memory allocations in Rust are also always done explicitly, but Rust's library types don't have APIs that allow you to get it wrong.
  - vacuity 9mo ago
    Rust doesn't (yet) have the same level of control over allocators as Zig does.
    - Measter 9mo ago
      The Rust language has exactly that level of control. Rust's Alloc and STD implementations do not yet provide it.
      - vacuity 9mo ago
        That's like saying Rust has GC because GC libraries/runtimes can be implemented in/for Rust. Rust recognizes allocations on a language basis, but does not provide the same level of control over allocations on a language basis as Zig does. For instance, there is no stable interface for custom allocators for alloc/std.
        timschmidt 9mo ago
        std may not yet provide a stable interface for custom allocators (the Allocator API appears to be available in unstable presently), but use of custom allocators is common in no-std rust environments like embedded. Reading through https://github.com/irbull/custom_allocators https://github.com/irbull/custom_allocators the Allocator API doesn't seem particularly complicated. I think it's fair to expect that it will stabilize in time. > That's like saying Rust has GC because GC libraries/runtimes can be implemented in/for Rust. Quite a few have already been implemented and are available as libraries exactly as you describe, today. I wouldn't phrase that as "Rust has GC" because that might imply that the GC is required. But if your application might benefit from GC, it's certainly available in the language. I might say "GC is optionally available in Rust if desired" to be more accurate.
        vacuity 9mo ago
        https://news.ycombinator.com/item?id=46684673 https://news.ycombinator.com/item?id=46684673 (reply to sibling) > I think it's fair to expect that it will stabilize in time. The allocator work is facing a lot of obstacles, unfortunately. I prefer it to be unstable for as long as it needs, though. > Quite a few have already been implemented and are available as libraries exactly as you describe, today. I wouldn't phrase that as "Rust has GC" because that might imply that the GC is required. This is exactly my point. Rust does not prevent GC by any means, but Rust also does not encourage GC by any means. The same goes for custom allocators, aside from the highly-unstable Allocator API.
        timschmidt 9mo ago
        > The allocator work is facing a lot of obstacles, unfortunately. Got any links? Sounds like interesting reading. Seriously. Kind of thing I come here for. I'd really appreciate it. Or I can ask the AI for some. > I prefer it to be unstable for as long as it needs, though. Sure, same. Fully baking things is a process, and it's nice when things are fully baked. So I agree. I think Rust's async could be a bit more ergonomic, though it wasn't too difficult to wrap my head around, and sort of shockingly simple to implement a basic no-std async executor (~10 lines), so maybe I'm coming around. I was pleased to find out that it was simple enough that I could do it, and understand how it worked, as I try to do with all my microcontroller code, and wasn't dependent on a big async runtime like Tokio if I didn't need it's features (or bloat).

by blubber 9mo ago

jordand 9mo ago

Memory allocations are always done explicitly (nothing is hidden or implicit). I've not written enough Zig yet to appreciate that, but I've hit plenty of those issues year-after-year with C++ to know their approach is sane and rational.

Measter 9mo ago
Memory allocations in Rust are also always done explicitly, but Rust's library types don't have APIs that allow you to get it wrong.
- vacuity 9mo ago
  Rust doesn't (yet) have the same level of control over allocators as Zig does.
  - Measter 9mo ago
    The Rust language has exactly that level of control. Rust's Alloc and STD implementations do not yet provide it.
    - vacuity 9mo ago
      That's like saying Rust has GC because GC libraries/runtimes can be implemented in/for Rust. Rust recognizes allocations on a language basis, but does not provide the same level of control over allocations on a language basis as Zig does. For instance, there is no stable interface for custom allocators for alloc/std.
      - timschmidt 9mo ago
        std may not yet provide a stable interface for custom allocators (the Allocator API appears to be available in unstable presently), but use of custom allocators is common in no-std rust environments like embedded. Reading through https://github.com/irbull/custom_allocators https://github.com/irbull/custom_allocators the Allocator API doesn't seem particularly complicated. I think it's fair to expect that it will stabilize in time. > That's like saying Rust has GC because GC libraries/runtimes can be implemented in/for Rust. Quite a few have already been implemented and are available as libraries exactly as you describe, today. I wouldn't phrase that as "Rust has GC" because that might imply that the GC is required. But if your application might benefit from GC, it's certainly available in the language. I might say "GC is optionally available in Rust if desired" to be more accurate.
        vacuity 9mo ago
        https://news.ycombinator.com/item?id=46684673 https://news.ycombinator.com/item?id=46684673 (reply to sibling) > I think it's fair to expect that it will stabilize in time. The allocator work is facing a lot of obstacles, unfortunately. I prefer it to be unstable for as long as it needs, though. > Quite a few have already been implemented and are available as libraries exactly as you describe, today. I wouldn't phrase that as "Rust has GC" because that might imply that the GC is required. This is exactly my point. Rust does not prevent GC by any means, but Rust also does not encourage GC by any means. The same goes for custom allocators, aside from the highly-unstable Allocator API.
        timschmidt 9mo ago
        > The allocator work is facing a lot of obstacles, unfortunately. Got any links? Sounds like interesting reading. Seriously. Kind of thing I come here for. I'd really appreciate it. Or I can ask the AI for some. > I prefer it to be unstable for as long as it needs, though. Sure, same. Fully baking things is a process, and it's nice when things are fully baked. So I agree. I think Rust's async could be a bit more ergonomic, though it wasn't too difficult to wrap my head around, and sort of shockingly simple to implement a basic no-std async executor (~10 lines), so maybe I'm coming around. I was pleased to find out that it was simple enough that I could do it, and understand how it worked, as I try to do with all my microcontroller code, and wasn't dependent on a big async runtime like Tokio if I didn't need it's features (or bloat).