Interview with Zig language creator Andrew Kelley [video]

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).

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?

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.

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.

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.

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.

I use Rust because I need performance, then I compile my Rust code for the exact CPU instructions available on my target machine and with PGO, binary dependencies can't do that.

Also, binary third party come with a lot of hassle (compiler version & options used can break your build) so I'm really glad Rust took the source-code dependency route instead (at least by default).

You can use binary dependencies though, as long as you compile everything with the same compiler it will works.

The only hassle is not wanting to learn how to use compiled languages properly, that is how we end up with the brain dead idea of header only libraries.

Regarding performance, Rust still needs to catch up with C++ in many domains.

There are plenty of reasons why C++ is my to go language outside my managed language options, despite my appreciation for Rust, and C++'s caveats of copy-paste compatibility with C.