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

301–310 of 336 posts

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

#301

Post by dnautics »

onlyrealcuzzo wrote: post #181
slekker wrote: post #180

Earlier quoted context omitted.

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.

1. rust didnt invent affine ownership. 2. It's possible to bolt on to other languages (see ada). zig in particular is easy (disclaimer: i think, i haven't implemented it yet)

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

#302

Post by dnautics »

kibwen wrote: post #246
dnautics wrote: post #232

Earlier quoted context omitted.

i mean in zig-clr it pushes you towards more expressive patterns, for example, making you label pointers as optional if their status is ambiguous

A language is more expressive when it allows more programs and less expressive when it allows fewer programs. I don't know zig-clr, but if it rejects programs that Zig accepts (for example, by rejecting the aforementioned ambiguous pointers), then it is less expressive, not more (keeping in mind that being less expressive is not a pejorative).

no thats not the definition of more expressive. more expressive means the language can encode more programmer intent without making a dog's breakfast of the code.

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

#303

Post by dnautics »

AlotOfReading wrote: post #185
dnautics wrote: post #85

Earlier quoted context omitted.

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?

start by examining zig-clr

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

#304

Post by dnautics »

afdbcreid wrote: post #194
dnautics wrote: post #85

Earlier quoted context omitted.

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…

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

it is possible to do in-code annotations in zig, if you're clever. you can get pretty far without them too.

as an example, you can check for double free without ownership tagging, by being agnostic about who should free, and flagging if two nondisjoint code paths attempt to free the same allocation.

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

#305

Post by dnautics »

Ar-Curunir wrote: post #156
dnautics wrote: post #77

Earlier quoted context omitted.

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

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?

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.

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

#306

Post by kibwen »

dnautics wrote: post #302
kibwen wrote: post #246

Earlier quoted context omitted.

A language is more expressive when it allows more programs and less expressive when it allows fewer programs. I don't know zig-clr, but if it rejects programs that Zig accepts (for example, by rejecting the aforementioned ambiguous pointers), then it is less expressive, not more (keeping in mind that being less expressive is not a pejorative).

no thats not the definition of more expressive. more expressive means the language can encode more programmer intent without making a dog's breakfast of the code.

Now we're just having a semantic argument over the word "expressiveness", which is not especially interesting; see https://chrispenner.ca/posts/expressiveness-spectrum . My argument above remains true regardless of the terms you choose to use.

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

#307

Post by vips7L »

Mawr wrote: post #250
vips7L wrote: post #119

Earlier quoted context omitted.

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

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

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.

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

#308

Post by estebank »

znkr wrote: post #276
estebank wrote: post #254

Earlier quoted context omitted.

There's a material difference on one taking risks for oneself and one taking risks where the brunt of the consequences fall on others.

You mean like driving a car?

I don't think using an example that includes licensing, plenty of regulations governing drivers, the cars themselves and the built environment, enforcement, and plenty of research on the impact of passive infrastructure to make things safer (bollards, daylighting, raised pedestrian intersections, curbs, traffic lights, etc.) makes the case you seem to be trying to make.

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

#309

Post by gpm »

dnautics wrote: post #221
gpm wrote: post #184

Earlier quoted context omitted.

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 condition…

so yes it is possible to detect those patterns and ban them as unsafe, and have a"safety checked alternative. clr does this currently: https://github.com/ityonemo/clr#safety-oriented-architecture

It's possible to detect and ban the version of the problematic pattern that I made as short and simple as possible to illustrate the point, sure.

I'm general though, I don't believe it is practical to do so. Not without every library being designed with the checker in mind and annotated to more precisely describe their APIs. Which is why I'm not surprised to see the limitations.md that seems to exclude all the hard cases (aliasing, pointers used as first class values, cross function analysis): https://github.com/ityonemo/clr/blob/main/LIMITATIONS.md#mem...

Obviously if you rewrite the zig world to obey rust like rules and include rust like annotations you can implement a rust like borrow checker, but I don't think that it would still be meaningfully zig. It might be an interesting language worth exploring.

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

#310

Post by whytevuhuni »

inigyou wrote: post #286
steveklabnik wrote: post #191

Earlier quoted context omitted.

Every compiler has bugs.

Not what I asked

If cve-rs exists, we still say that safe Rust is safe, in the same way that we say Python is safe despite potential bugs in its interpreter or native libraries, and that Java is safe despite potential bugs in the JVM or JNI libraries, and so on.
Post reply on HN