4 ms·

> 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

by 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
    With C++ I can get zero cost abstractions without Rust like compilation times, in spite C++ fame of slow compile times. How? By making heavy use of binary third party dependencies, every module gets its own binary library, no crazy use of metaprogramming, incremental compilation and linking. My WinUI/UWP professional work compile in a fraction of my Gtk-rs toy applications. I keep measuring improvements in this area, and hopefully Microsoft's own pain with Rust/WinRT might trigger some improvements.

by pron 6y ago

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
  With C++ I can get zero cost abstractions without Rust like compilation times, in spite C++ fame of slow compile times. How? By making heavy use of binary third party dependencies, every module gets its own binary library, no crazy use of metaprogramming, incremental compilation and linking. My WinUI/UWP professional work compile in a fraction of my Gtk-rs toy applications. I keep measuring improvements in this area, and hopefully Microsoft's own pain with Rust/WinRT might trigger some improvements.