5 ms·

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 rea

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 [=

Hinrik 3mo ago
Layperson here: what is special about Go's runtime, aside from the GC?
- onlyrealcuzzo 3mo ago
  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.
  - deleted 3mo ago
    [deleted]
  - jcgl 3mo ago
    This is the first I've heard anyone claim higher throughput for Go than Rust. Any articles you'd point to to learn more?
    - insanitybit 3mo ago
      I think one of the few performance benefits with a GC is that you can defer allocations. You can do that in Rust too though.
  - Aurornis 3mo ago
    > 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.
    - never_inline 3mo ago
      Go has few issues with performance (lack of in-line union types, interface overuse, inefficient idioms reg. collections, some missed optimizations) but its seems plausible for a idiomatic Go program to outperform an idiomatic rust program in some situations. Example: https://news.ycombinator.com/item?id=22336284 https://news.ycombinator.com/item?id=22336284
  - jandrewrogers 3mo ago
    > 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.
  - zacmps 3mo ago
    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?
  - insanitybit 3mo ago
    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.
  - pjmlp 3mo ago
    What a joke, ignoring Erlang, and the custom schedulers from JVM and CLR runtimes.
    - dnautics 3mo ago
      Erlang's scheduler is not sophisticated, which is what makes it AWESOME. but yeah. i would be surprised if the JVM's scheduler is not more sophisticated than go's if for no other reason than it has way more knobs you can tune. you know they put that knob in there because someone (probably Google cough cough) asked for it
      - pjmlp 3mo ago
        The missing part is that if what is in box isn't enough, both JVM and CLR allow you to fully customise how the scheduling algorithm works.
- fnord77 3mo ago
  Goroutines?
- djha-skin 3mo ago
  Chief design goals were radically easy concurrency and speed of compilation.
  - minraws 3mo ago
    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.
    - ameliaquining 3mo ago
      What weird new generic features? Generic type aliases? Those aren't very complicated.
- vips7L 3mo ago
  Is the Go GC that special? Is it even generational yet?
  - silisili 3mo ago
    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.
    - vips7L 3mo ago
      It makes plenty sense to be. There aren’t many negatives and there are plenty of workloads that would benefit.
  - Mawr 3mo ago
    Idk, is it? https://go.dev/blog/greenteagc https://go.dev/blog/greenteagc > Is it even generational yet? Is there any reason in particular it should be? Or are you just throwing random buzzwords around? Anyways, https://github.com/golang/go/discussions/70257#discussioncomment-11201305 https://github.com/golang/go/discussions/70257#discussioncom...
    - vips7L 3mo ago
      You seem to be really hostile for no apparent reason. There are plenty of reasons to be generational, there are lots of workloads that the current implementation might fall flat if it wasn't.
lioeters 3mo ago
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.
- onlyrealcuzzo 3mo ago
  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...
  - rienbdj 3mo ago
    Can selectively turn off the borrow check for dev builds?
- dnautics 3mo ago
  > 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.
  - Ar-Curunir 3mo ago
    No, it would fundamentally change how Zig works.
    - dnautics 3mo ago
      no, it would not. If you do not believe me, you should try out the repo.
      - Ar-Curunir 3mo ago
        the architecture doesn't make sense. MIRI doesn't perform static analysis on MIR. It is, as the name says, an interpreter. The borrow checker is entirely different from miri. Rust's borrow checker requires lifetime annotations. Zig code doesn't contain any such annotations. How does your design handle this?
dnautics 3mo ago
> 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 https://github.com/ityonemo/clr
deleted 3mo ago
[deleted]
dabinat 3mo ago
This is being worked on: https://rust-lang.github.io/rust-project-goals/2026/roadmap-fast-builds.html https://rust-lang.github.io/rust-project-goals/2026/roadmap-... Most of the goals on this page are targeted for this year.
insanitybit 3mo ago
Rust's compile times will get faster long before Zig gets safer.
- onlyrealcuzzo 3mo ago
  I'm pretty sure Zig has no plans to ever become safe - by any sane sense of the word - so, yes, I would expect...
  - dnautics 3mo ago
    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
    - gpm 3mo ago
      This is cool and will likely enable some cool tooling. I don't think a borrow checker is likely to be in that tooling. Borrow checking requires shaping the code, and all the dependencies, into easily analyzable (and at least in rust's version annotated) patterns. You can't borrow check arbitrary code not designed for it without false positives.
      - slekker 3mo ago
        You can because all allocations are tracked and explicit
        onlyrealcuzzo 3mo ago
        Allocations are less of a problem than aliases. Without affine/linear ownership - solving the aliasing problem is the Halting Problem. Rust didn't invent Affine Ownership just to make Rust hard. It did it because it's one of the only ways to have memory safety without a GC.
        dnautics 3mo ago
Gigachad 3mo ago
Are compile times that big of a deal? I haven't used Rust a ton, but the few times I have it seemed like the bulk of the compile time was a one off compiling the crates, and then compiling your own code was super fast. I feel like I'd massively prefer to end up with a binary free of memory exploits than shaving some time off compile.

Hinrik 3mo ago

Layperson here: what is special about Go's runtime, aside from the GC?

onlyrealcuzzo 3mo ago
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.
- deleted 3mo ago
  [deleted]
- jcgl 3mo ago
  This is the first I've heard anyone claim higher throughput for Go than Rust. Any articles you'd point to to learn more?
  - insanitybit 3mo ago
    I think one of the few performance benefits with a GC is that you can defer allocations. You can do that in Rust too though.
- Aurornis 3mo ago
  > 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.
  - never_inline 3mo ago
    Go has few issues with performance (lack of in-line union types, interface overuse, inefficient idioms reg. collections, some missed optimizations) but its seems plausible for a idiomatic Go program to outperform an idiomatic rust program in some situations. Example: https://news.ycombinator.com/item?id=22336284 https://news.ycombinator.com/item?id=22336284
- jandrewrogers 3mo ago
  > 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.
- zacmps 3mo ago
  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?
- insanitybit 3mo ago
  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.
- pjmlp 3mo ago
  What a joke, ignoring Erlang, and the custom schedulers from JVM and CLR runtimes.
  - dnautics 3mo ago
    Erlang's scheduler is not sophisticated, which is what makes it AWESOME. but yeah. i would be surprised if the JVM's scheduler is not more sophisticated than go's if for no other reason than it has way more knobs you can tune. you know they put that knob in there because someone (probably Google cough cough) asked for it
    - pjmlp 3mo ago
      The missing part is that if what is in box isn't enough, both JVM and CLR allow you to fully customise how the scheduling algorithm works.
fnord77 3mo ago
Goroutines?
djha-skin 3mo ago
Chief design goals were radically easy concurrency and speed of compilation.
- minraws 3mo ago
  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.
  - ameliaquining 3mo ago
    What weird new generic features? Generic type aliases? Those aren't very complicated.
vips7L 3mo ago
Is the Go GC that special? Is it even generational yet?
- silisili 3mo ago
  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.
  - vips7L 3mo ago
    It makes plenty sense to be. There aren’t many negatives and there are plenty of workloads that would benefit.
- Mawr 3mo ago
  Idk, is it? https://go.dev/blog/greenteagc https://go.dev/blog/greenteagc > Is it even generational yet? Is there any reason in particular it should be? Or are you just throwing random buzzwords around? Anyways, https://github.com/golang/go/discussions/70257#discussioncomment-11201305 https://github.com/golang/go/discussions/70257#discussioncom...
  - vips7L 3mo ago
    You seem to be really hostile for no apparent reason. There are plenty of reasons to be generational, there are lots of workloads that the current implementation might fall flat if it wasn't.

lioeters 3mo ago

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.

onlyrealcuzzo 3mo ago
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...
- rienbdj 3mo ago
  Can selectively turn off the borrow check for dev builds?
dnautics 3mo ago
> 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.
- Ar-Curunir 3mo ago
  No, it would fundamentally change how Zig works.
  - dnautics 3mo ago
    no, it would not. If you do not believe me, you should try out the repo.
    - Ar-Curunir 3mo ago
      the architecture doesn't make sense. MIRI doesn't perform static analysis on MIR. It is, as the name says, an interpreter. The borrow checker is entirely different from miri. Rust's borrow checker requires lifetime annotations. Zig code doesn't contain any such annotations. How does your design handle this?

dnautics 3mo ago

> 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 https://github.com/ityonemo/clr

deleted 3mo ago

[deleted]

dabinat 3mo ago

This is being worked on: https://rust-lang.github.io/rust-project-goals/2026/roadmap-fast-builds.html https://rust-lang.github.io/rust-project-goals/2026/roadmap-... Most of the goals on this page are targeted for this year.

insanitybit 3mo ago

Rust's compile times will get faster long before Zig gets safer.

onlyrealcuzzo 3mo ago
I'm pretty sure Zig has no plans to ever become safe - by any sane sense of the word - so, yes, I would expect...
- dnautics 3mo ago
  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
  - gpm 3mo ago
    This is cool and will likely enable some cool tooling. I don't think a borrow checker is likely to be in that tooling. Borrow checking requires shaping the code, and all the dependencies, into easily analyzable (and at least in rust's version annotated) patterns. You can't borrow check arbitrary code not designed for it without false positives.
    - slekker 3mo ago
      You can because all allocations are tracked and explicit
      - onlyrealcuzzo 3mo ago
        Allocations are less of a problem than aliases. Without affine/linear ownership - solving the aliasing problem is the Halting Problem. Rust didn't invent Affine Ownership just to make Rust hard. It did it because it's one of the only ways to have memory safety without a GC.
        dnautics 3mo ago

Gigachad 3mo ago

Are compile times that big of a deal? I haven't used Rust a ton, but the few times I have it seemed like the bulk of the compile time was a one off compiling the crates, and then compiling your own code was super fast. I feel like I'd massively prefer to end up with a binary free of memory exploits than shaving some time off compile.