Comment by onlyrealcuzzo
8 hours ago
Zig's incremental builds are DEFINITELY a killer feature. In the short term, I could see why you'd make a switch to get it. But, in the medium term, can we really not expect to see this in Rust in the somewhat near future?
I want to go fast, but I don't want to go fast just to shoot my foot off.
If only somehow we could get Rust's safety with all of Zig's features and Go's runtime without GC...
That's what I'm working on building [=
Rust's compile times will get faster long before Zig gets safer.
I'm pretty sure Zig has no plans to ever become safe - by any sane sense of the word - so, yes, I would expect...
zig does have plans to give access to IRs when stable so adding a borrow checker to zig will be even easier than it is now
5 replies →
This is being worked on: https://rust-lang.github.io/rust-project-goals/2026/roadmap-...
Most of the goals on this page are targeted for this year.
Instead of waiting for faster compiler in Rust, how about from the other direction, adding some kind of borrow checker to Zig? That sounds more within reach and practically achievable, possibly even in userland.
That's sort of what I'm doing...
I'm writing a language with Affine Ownership that transpiles to Zig and has a built-in FSM-based Green Fiber runtime.
Affine Ownership gives you memory safety + fearless concurrency + eliminates the need for Go's GC.
It's obviously going to slow down compilation - since you need to do Rust's borrow checking, etc. But I can do this incrementally as well...
It's impossible to add a borrow checker to any existing language.
The reason Rust has a working borrow checker is because every part of the language from structs, enum, traits, generics and all the way to the syntax itself has been designed to support lifetimes and borrow checking.
It's is not something you can just tack on to an existing language without fundamentally changing it.
I wouldn't say it's impossible, rather un-ergonomic. TypeScript can add type information to ordinary JavaScript code via JSDoc comments; the result can both be executed as ordinary JavaScript as-is and type-checked with TypeScript. But it's a huge pain to try to write (and maintain) everything that way, it was supported as a hack to help migrate legacy codebases. You could probably take a similar "the lifetimes are embedded in comments" approach with other languages, and the result would be similarly un-ergonomic.
11 replies →
Swift, Linear Haskell, Chapel, Ada/SPARK are all counter examples from such claim.
1 reply →
C# was already a very mature language when it had referenes and later "ref safety" added to it.
> It's impossible to add a borrow checker to any existing language.
Why do you say that. Have you tried and failed? It seems to be possible to add a borrow checker to zig, just as you can add MIRI to rust to get extra safety in unsafe blocks.
> how about from the other direction, adding some kind of borrow checker to Zig? That sounds more within reach and practically achievable, possibly even in userland.
It's doable, and as static analysis. see sibling comment.
No, it would fundamentally change how Zig works.
2 replies →
Layperson here: what is special about Go's runtime, aside from the GC?
Chief design goals were radically easy concurrency and speed of compilation.
Speed of compilation feels like a distant second in terms of goals given the weird new generic features they keep adding..
I was fine with basic generics they complicated it quite a bit much for my liking.
1 reply →
Is the Go GC that special? Is it even generational yet?
I'm not sure it would ever make sense to be. That makes the assumption tons of allocations get made that don't live long, which was(maybe is still?) more common in some languages. Go is more aggressive about not heap allocating, and has tools to help you avoid them.
Goroutines?
It's literally the most sophisticated scheduling engine in the world.
In practice, Go can typically outperform Rust in throughput (using more memory), despite having a mountain of disadvantages against it in theory.
That's how good the Go scheduler/runtime is.
> n practice, Go can typically outperform Rust in throughput (using more memory), despite having a mountain of disadvantages against it in theory
This is a huge claim that disagrees with both my real-world experience and everything I've seen from artificial comparisons.
Every high performance Go system I've worked on has quickly reached the point where we're optimizing memory management and doing things that would have been explicit in a non-GC language like Rust anyway.
The Go runtime is amazingly optimized, but it comes with overhead over doing the same work directly in a lower level language.
This is the first I've heard anyone claim higher throughput for Go than Rust. Any articles you'd point to to learn more?
1 reply →
I think this is interesting and warrants explanation. There are cases where a GC can be faster (sort of, Arenas get you most of the gains) but "the most sophisticated scheduling engine in the world" should be easy to at least partially support.
> It's literally the most sophisticated scheduling engine in the world.
That seems unlikely regardless of how good it is. This is a domain where state-of-the-art research is not in the public literature. Scheduling is an AI-complete problem.
What benchmarks are you referring to?
Rust itself doesn't have a scheduler of course, I assume this is comparing against tokio or one of the other async executors?
What a joke, ignoring Erlang, and the custom schedulers from JVM and CLR runtimes.
1 reply →
> if only somehow we could get Rust's safety with all of Zig's features
i periodically throw my unused codex tokens at this:
https://github.com/ityonemo/clr