[onlyrealcuzzo]

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

[dabinat]

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.

[insanitybit]

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

[onlyrealcuzzo]

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]

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]

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]

You can because all allocations are tracked and explicit

[gpm]

That's not sufficient - consider the following pseudocode

    x = malloc();
    if (opaque_cond()) free(x);
    if (other_opaque_cond()) use(x);

Conditions can be opaque and non-analyzable due to rices theorem - in any turing complete language. This code is correct (or at least not memory unsound) if opaque_cond and other_opaque_cond are never both true. Otherwise it isn't.

And functionally compiler analyses of whether conditions hold have to be trivial because using some form of theorem prover to decide of code is correct or not leads to code that is brittle against compiler version changes, and slow compile times. Thus opaque_cond could be as simple as `len == 0` and `other_opaque_cond` could be `len > 0` and it's unlikely you'd want the compiler to realize those are mutually exclusive (at the stage where it accepts programs, obviously during optimization it is very likely to take advantage of this).

Rust solves this by simply rejecting the pattern. Very roughly forcing you to write if opaque_cond() { free(x) } else if other_opaque_cond() { use_x } (or something else where the program structure and not just the logic in the conditions guarantees correctness). Zig simply allows it and leaves it up to the programmer not to make a mistake.

And as onlyrealcuzzo suggests aliases are where this type of analysis (accepting enough programs to be useful but still imposing enough structure you can prove correctness) is really tricky.

[onlyrealcuzzo]

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.

[Peaches4Rent]

Apologies for the noob question, but what is an IR?

[dnautics]

intermediate representation. attempting to analyze zig code directly would be too hard (especially with comptime). on the way to the compiler backend, the compiler builds a simplified representation that only has "actually existing functions" and is very straightforward, e.g.

    function 10112:
    0: argument 0
    1: argument 1
    2: argument 2
    3: add 0, 1
    4: store 2
    5: call function 1342, (2, 4)
    6: return 5

you can see how building a data dependency graph from this would be easy.

[lioeters]

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]

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]

Can selectively turn off the borrow check for dev builds?

[veber-alex]

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.

[solatic]

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.

[AlienRobot]

A better comparison would be Python.

The way Python added types is the most disgusting thing imaginable... but it has type hints now, so I guess that makes some people happy.

[afdbcreid]

That is possible (clang has experimental lifetime annotations support), but that is not enough to guarantee memory safety.

As a simple example, Zig has no private fields. That makes encapsulating any unsafety impossible.

[dnautics]

no. You don't need private fields. All you have to do is analyze the code, harness the compiler to generate a time-dependent data dependency graph, and map allocation/frees/uses, if you can 'color' branches where data are shared you can also track and check to see there isn't an aliasing violation too.

it is easy to patch the zig compiler to enable this this (export the code graph; about 50 LOC). The analysis is much much harder to get right.

[afdbcreid]

This analysis is undecidable. There is a reason sound static analyzers (including languages like Rust) require in-code annotations.

[AlotOfReading]

It seems like it'd be pretty reasonable to get something akin to polonius. I can write up an engine in zig if it'd help?

[rcxdude]

It is only feasible to do this if the whole of the codebase idea designed to allow it, and it's still going to blow up in odd ways of you don't have a way to describe lifetimes in your interfaces. The magic of rust's design is that it turns this memory tracking into a local problem, such that you can design an interface and be sure that every use case is safe and verifiably so.

[solatic]

> Zig has no private fields

You may have missed the point here. You could add a comment to the struct field that marks the field as private, and build a TypeScript/JSDoc analogue that analyzes all accesses to the field and fails if it finds accesses from functions that aren't part of the struct that owns the field. You don't even need a comment on the field - you could copy Go's convention, add a comment to the struct definition marking it as "follows Go convention", and then fail any access from outside the struct to a field that starts with a lower-case character.

It doesn't prevent you from ignoring that tool and writing Zig code that imports the struct and accesses the field. It is, of course, not part of the Zig language itself. But if you adopted a tool like that, it would be your responsibility to run it across-the-board and pay attention to the results - same as how it is your responsibility to pay attention to the results if you added those JSDoc comments.

[afdbcreid]

I have picked private fields as an example of feature that is needed because it is very simple. You're right that you can build an analyzer (with additional code annotations) to support that, but it's only one example.

Take another example: unsafe traits. They are fundamental to some safety encapsulations, most famously concurrency (`Send`/`Sync`). Here you cannot just build an analyzer to mark something unsafe, because Zig has no traits, its generics are duck-typed.

You can, of course, add traits. But at this point you're essentially creating your own language that compiles to Zig, with all problems this entails (e.g. bad ecosystem support). It's also hard to claim that Zig can be memory safe then.

[veber-alex]

Exactly.

Every part of the language must support memory safety from first principles.

[dnautics]

empirically untrue. several projects exist that bolt on extra safety to unsafe languages or unsafe parts of language. SeL4 for C, MIRI for rust unsafe. i guess ada/spark for ada too, is the OG, spark being added to ada 4 years after its first release

[pjmlp]

Swift, Linear Haskell, Chapel, Ada/SPARK are all counter examples from such claim.

[lioeters]

Also OxCaml, from what I hear.

[rienbdj]

OCaml already starts form a memory safe base being GCd?

[lioeters]

I'm not familiar but I think this paper describes how OxCaml works:

Oxidizing OCaml with Modal Memory Management - https://dl.acm.org/doi/10.1145/3674642

> We focus on three mode axes: affinity, uniqueness and locality. Modes are fully backwards compatible with existing OCaml code and can be completely inferred. Our work makes manual memory management in OCaml safe and convenient and charts a path towards bringing the benefits of Rust to OCaml.

https://github.com/oxcaml/oxcaml

[pjmlp]

Yes, it is getting there, however I would rather count it when they finally manage to upstream everything to OCaml as per plan.

[dnautics]

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

[kfuse]

C# was already a very mature language when it had referenes and later "ref safety" added to it.

[dnautics]

> 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]

No, it would fundamentally change how Zig works.

[dnautics]

no, it would not. If you do not believe me, you should try out the repo.

[Ar-Curunir]

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]

1. it is possible to do code annotations in zig even though i havent implemented it in this iteration of clr (the first poc demonstrated this). i want to see how far i can get without them.

2. let's take double free (easiest to explain).

you dont have to tag ownership, you can be agnostic about who should free, and merely report if two nondisjoint code paths attempt to free the same memory.

[Gigachad]

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]

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

[djha-skin]

Chief design goals were radically easy concurrency and speed of compilation.

[minraws]

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]

What weird new generic features? Generic type aliases? Those aren't very complicated.

[vips7L]

Is the Go GC that special? Is it even generational yet?

[silisili]

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]

It makes plenty sense to be. There aren’t many negatives and there are plenty of workloads that would benefit.

[Mawr]

Idk, is it? 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#discussioncom...

[vips7L]

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.

[fnord77]

Goroutines?

[onlyrealcuzzo]

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.

[Aurornis]

> 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]

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

[jcgl]

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]

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.

[jandrewrogers]

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

[insanitybit]

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.

[zacmps]

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?

[pjmlp]

What a joke, ignoring Erlang, and the custom schedulers from JVM and CLR runtimes.

[dnautics]

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]

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.

[dnautics]

> 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