4 ms·

There is some ongoing work towards custom allocators for containers in Rust std. [1] Right now you could also go no_std (you still get the core library, which

There is some ongoing work towards custom allocators for containers in Rust std. [1] Right now you could also go no_std (you still get the core library, which does not contain any allocating data structures) and use custom containers with a passed in allocator. Zig is definitely a cool language, and it will be interesting if they can come up with good solutions to memory management! But sentences like these in the documentation [2] would make me prefer Rust for most low level domains (for now): > It is the Zig programmer's responsibility to ensure that a pointer is not accessed when the memory pointed to is no longer available. Note that a slice is a form of pointer, in that it references other memory. ... > ... the documentation for the function should explain who "owns" the pointer [1] https://github.com/rust-lang/wg-allocators https://github.com/rust-lang/wg-allocators [2] https://ziglang.org/documentation/master/#toc-Lifetime-and-Ownership https://ziglang.org/documentation/master/#toc-Lifetime-and-O...

pron 6y ago
> But sentences like these in the documentation [2] would make me prefer Rust for most low level domains While such use-after-free issues are not prevented at compile time, the plan is to ultimately have safe Zig catch them (and panic) at runtime, i.e. safe Zig shouldn't have undefined behaviour. Because this is done with runtime checks, the expectation is that those checks will be turned off (selectively, perhaps) in production, after testing has satisfied you. In that case, the guarantees aren't as strong as Rusts, but those guarantees come at a significant cost -- to language complexity and compilation time -- that can also have a negative effect on correctness. So while Zig's approach to safety/correctness is certainly very different from Rust's, I don't think it is necessarily weaker (perhaps it could even be stronger, but the question is hard to settle).
- defen 6y ago
  > In that case, the guarantees aren't as strong as Rusts, but those guarantees come at a significant cost -- to language complexity and compilation time -- that can also have a negative effect on correctness How would those guarantees have a negative effect on correctness? Are you thinking something like, you need to design your data structure / program in a non-intuitive way that makes it more difficult to get the logic right, even though you are protected from memory safety issues?
  - pron 6y ago
    Because a complex language is harder to read, and so slower to read and understand, and so to maintain over time without introducing bugs; compilation speed also slows you down, which means you write fewer tests. In general, getting a correct program requires effort. If that effort goes elsewhere, there's less of it for correctness.
- aw1621107 6y ago
  > but those guarantees come at a significant cost -- to language complexity and compilation time Aren't Rust's compilation time woes more due to the amount of IR the front/middle-end give to LLVM? I was under the impression that the type system-related stuff isn't that expensive.
  - littlestymaar 6y ago
    The borrow-checking and ownership mechanism is cheap, and it's almost never a significant part of the big compilation time encountered in Rust. What's not cheap, and is responsible for long compilation times (the order is arbitrary, the relative weights are highly dependent of the code-base): - size of the code generation units (the whole crate vs individual files in C) - procedural macros - generics & traits - interaction between generics & LLVM IR generation (a lot of bloat is created, to be removed by LLVM later) - LLVM itself Most of those are being worked on, but in the end it's mostly a social problem: as Rust users are used to long compile time, many of them don't especially take care of it, and most gains in the compiler are often outweighed by people writing slower code. It's already possible to write Rust code that compiles quickly, if you pay attention. The culture is evolving though, and more and more library authors are now mindful of compilation time of their crate (and the tooling to diagnose it is also improving). Key takeaway: Memory safety isn't what makes Rust compile slowly, “zero-cost abstractions” is.
    - pron 6y ago
      > Memory safety isn't what makes Rust compile slowly, “zero-cost abstractions” is. What one of Rust's designers told me when I asked him why they made the language so complicated is that nearly all of Rust's features exist to serve the borrow checker (except maybe macros). Once you have those features, and because Rust is a low-level language, you must have "zero-cost abstractions." I don't know whether some other hypothetical low-language language could exist that gives you both sound compile-time memory safety guarantees as well as be a simple language that compiles quickly -- I would love to evaluate such a language, but we don't have one right now.
    - pjmlp 6y ago
vvanders 6y ago
Yeah, I've been using no_std for this use case and pretty happy with it. If you want a full blown container you can use heapless, building a custom container is really straightforward and requires a minimal amount of unsafe.
avasthe 6y ago
That is pretty common in low level domains. Rust instead comes with complexity of borrowck and lifetimes management no matter how rustaceans say it is second nature.

pron 6y ago

> But sentences like these in the documentation [2] would make me prefer Rust for most low level domains While such use-after-free issues are not prevented at compile time, the plan is to ultimately have safe Zig catch them (and panic) at runtime, i.e. safe Zig shouldn't have undefined behaviour. Because this is done with runtime checks, the expectation is that those checks will be turned off (selectively, perhaps) in production, after testing has satisfied you. In that case, the guarantees aren't as strong as Rusts, but those guarantees come at a significant cost -- to language complexity and compilation time -- that can also have a negative effect on correctness. So while Zig's approach to safety/correctness is certainly very different from Rust's, I don't think it is necessarily weaker (perhaps it could even be stronger, but the question is hard to settle).

defen 6y ago
> In that case, the guarantees aren't as strong as Rusts, but those guarantees come at a significant cost -- to language complexity and compilation time -- that can also have a negative effect on correctness How would those guarantees have a negative effect on correctness? Are you thinking something like, you need to design your data structure / program in a non-intuitive way that makes it more difficult to get the logic right, even though you are protected from memory safety issues?
- pron 6y ago
  Because a complex language is harder to read, and so slower to read and understand, and so to maintain over time without introducing bugs; compilation speed also slows you down, which means you write fewer tests. In general, getting a correct program requires effort. If that effort goes elsewhere, there's less of it for correctness.
aw1621107 6y ago
> but those guarantees come at a significant cost -- to language complexity and compilation time Aren't Rust's compilation time woes more due to the amount of IR the front/middle-end give to LLVM? I was under the impression that the type system-related stuff isn't that expensive.
- littlestymaar 6y ago
  The borrow-checking and ownership mechanism is cheap, and it's almost never a significant part of the big compilation time encountered in Rust. What's not cheap, and is responsible for long compilation times (the order is arbitrary, the relative weights are highly dependent of the code-base): - size of the code generation units (the whole crate vs individual files in C) - procedural macros - generics & traits - interaction between generics & LLVM IR generation (a lot of bloat is created, to be removed by LLVM later) - LLVM itself Most of those are being worked on, but in the end it's mostly a social problem: as Rust users are used to long compile time, many of them don't especially take care of it, and most gains in the compiler are often outweighed by people writing slower code. It's already possible to write Rust code that compiles quickly, if you pay attention. The culture is evolving though, and more and more library authors are now mindful of compilation time of their crate (and the tooling to diagnose it is also improving). Key takeaway: Memory safety isn't what makes Rust compile slowly, “zero-cost abstractions” is.
  - pron 6y ago
    > Memory safety isn't what makes Rust compile slowly, “zero-cost abstractions” is. What one of Rust's designers told me when I asked him why they made the language so complicated is that nearly all of Rust's features exist to serve the borrow checker (except maybe macros). Once you have those features, and because Rust is a low-level language, you must have "zero-cost abstractions." I don't know whether some other hypothetical low-language language could exist that gives you both sound compile-time memory safety guarantees as well as be a simple language that compiles quickly -- I would love to evaluate such a language, but we don't have one right now.
  - pjmlp 6y ago

vvanders 6y ago

Yeah, I've been using no_std for this use case and pretty happy with it. If you want a full blown container you can use heapless, building a custom container is really straightforward and requires a minimal amount of unsafe.

avasthe 6y ago

That is pretty common in low level domains. Rust instead comes with complexity of borrowck and lifetimes management no matter how rustaceans say it is second nature.