Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

How Our Rust-to-Zig Rewrite Is Going

rtfeldman.com

Post reply on HN
Print view View original

181–190 of 336 posts

Re: How Our Rust-to-Zig Rewrite Is Going

#181

Post by onlyrealcuzzo »

slekker wrote: post #180
gpm wrote: post #166

Earlier quoted context omitted.

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.

You can because all allocations are tracked and explicit

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.

Re: How Our Rust-to-Zig Rewrite Is Going

#182

Post by christkv »

steveklabnik wrote: post #152
christkv wrote: post #147

Earlier quoted context omitted.

Yeah I get they use it but I don't understand why you would buy it. it's just the runtime for code that makes up the agent.

Bun was a startup. Startups can go out of business, and then you are now scrambling to move your code to something else. They could also be bought by someone who has different priorities regarding future development than you, and that's also a risk. The simplest solution to these problems, if you have the capital, is to buy them.

I get that but there is always node.js

Re: How Our Rust-to-Zig Rewrite Is Going

#184

Post by gpm »

slekker wrote: post #180
gpm wrote: post #166

Earlier quoted context omitted.

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.

You can because all allocations are tracked and explicit

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.

Re: How Our Rust-to-Zig Rewrite Is Going

#185

Post by AlotOfReading »

dnautics wrote: post #85
afdbcreid wrote: post #63

Earlier quoted context omitted.

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.

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…

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?

Re: How Our Rust-to-Zig Rewrite Is Going

#186

Post by [deleted] »

slekker wrote: post #180
gpm wrote: post #166

Earlier quoted context omitted.

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.

You can because all allocations are tracked and explicit

[deleted]

Re: How Our Rust-to-Zig Rewrite Is Going

#187

Post by inigyou »

steveklabnik wrote: post #169
inigyou wrote: post #164

Earlier quoted context omitted.

Does cve-rs break any type system rules? If so, why hasn't it been fixed yet?

> Does cve-rs break any type system rules? Yes. > If so, why hasn't it been fixed yet? Pretty classic software engineering reasons. The part of the system that it involves was in the process of being re-written already. The re-write fixes the bug. Because it is essentially a theoretical issue, and not an actual problem in any real code, it is not a five alarm fire. Waiting for that re-write to land makes the most sen…

If cve-rs exists, is safe rust safe? Can one prove that Rust code is safe only by auditing the unsafe blocks?

Re: How Our Rust-to-Zig Rewrite Is Going

#188

Post by bsder »

em-bee wrote: post #140
Aurornis wrote: post #90

Earlier quoted context omitted.

> Zig is not pre-1.0 because it’s not ready for production (bugs or missing features), it’s pre-1.0 because they want to be able to make breaking language changes. This is a solved problem in other projects. Either use the version numbers as intended and bump the major version number on breaking changes, or use Rust-style editions to opt in to the newer versions of the changes. Calling a project production-ready but…

languages ideally should not have breaking changes ever. on the other hand, a language with frequent breaking changes should not be considered production ready. people are of course free to live on the edge, and if someone decided that zig is good enough and they are not bothered by breaking changes then they are free to use it for their production system, but that doesn't mean it's ready for everyone. so i prefer th…

> languages ideally should not have breaking changes ever.

I disagree MIGHTILY. This is how you wind up with C++ and Java.

Languages need to be able to remove features to stay coherent. Occasionally, you get things wrong, it takes time to figure that out, and that's just the way life is.

Re: How Our Rust-to-Zig Rewrite Is Going

#189

Post by rcxdude »

dnautics wrote: post #85
afdbcreid wrote: post #63

Earlier quoted context omitted.

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.

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…

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.
Post reply on HN