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
> 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).
> 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.
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.
> 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.
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 making heavy use of binary third party dependencies
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.
Except that doesn't work for the business of selling binary libraries for mobile and mainstream desktop OSes.
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.
> 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?
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.
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.
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.
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
[2] https://ziglang.org/documentation/master/#toc-Lifetime-and-O...