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

171–180 of 336 posts

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

#171

Post by g42gregory »

steveklabnik wrote: post #161
g42gregory wrote: post #154

Does this mean every time you find yourself using lots of “unsafe” Rust blocks, it’s not the right tool for the job? I suspect it’s not that simple, but what are people’s experience?

It really depends. For example, it might mean that you do not know the way to do the same thing, but in a safe manner. It might mean that you could refactor your code to do things more safely. Of course, reasonable people may also believe that it is easier to use an unsafe language directly rather than change the ways that you code. In my experience doing embedded, operating systems work, compiler work, and others, y…

Makes sense. Thanks!

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

#174

Post by Quot »

veber-alex wrote: post #41
landr0id wrote: post #12

>ReleaseSafe catches use-after-free errors through runtime checks which panic if the program tries to use freed memory. I don't know Zig so maybe they know something I don't, but I have seen no evidence that it catches any type of use-after-free including double-free? While writing a blog post (below) I went through the documentation to figure out the possible runtime memory safety checks Zig can insert. The term "us…

I believe you are correct. I think ReleaseSafe just adds bound checking and panics on unreachable code. I don't think Zig offers any temporal memory safety.

I don't know enough about Zig to explain it, but there is more to ReleaseSafe than checks and panics. ReleaseSafe also clears memory that no longer has an owner (I might be describing that wrong, that is just how I understand it). I found this out with a rendering issue recently.

The bug was around passing a slice to OpenGL which referenced memory outside of its lifetime. Since the memory location had no owner, vertices would still exist in Dev builds and everything would work fine, but in ReleaseSafe the application would run and just have nothing to render.

Since OpenGL was trying to read the memory, there was no panic from Zig, but it was a cool look into how the different build modes handle memory.

This is the commit where I fixed the issue: https://github.com/quot/donut/commit/8fff107e76278c4bf55007c...

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

#175

Post by uaksom »

drdexebtjl wrote: post #97
rwz wrote: post #71

Earlier quoted context omitted.

> they want to be able to make breaking language changes That sounds like it's not ready for production to me.

I invite you to read the release notes and see for yourself the types of breaking changes we’re talking about. To me it is not much different from Lua, which despite being on 5.x for decades, makes breaking changes on minor releases (because it predates SemVer). I also don’t see it being much different from any other language or language runtime that has a major release every year. It’s fine to update at your own pac…

> I invite you to read the release notes and see for yourself the types of breaking changes we’re talking about.

I did, and I immediately found this in the latest release: https://ziglang.org/download/0.16.0/release-notes.html#IO-as...

That seems like it would require changing a lot of code. Calling it "production ready" is dishonest at best

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

#176

Post by steveklabnik »

torginus wrote: post #170
steveklabnik wrote: post #62

Earlier quoted context omitted.

I do think it reflects different priorities, but one of those differences is that from my perspective, safety and performance are not inherently at odds. Yes, sometimes it is needed, but not as much as some people seem to think. Sometimes, it also means writing code in ways that communicate things to the compiler that you may not think of if you're not used to thinking in this manner. A lot of the ways in which the z…

> A lot of the ways in which the zig compiler works doesn't use pointers, it uses indices. This stuff is easier to write as safe code, not less easy. I respectfully disagree. This is only true if you view malloc as qualitatively different from a piece of code that gives you an index for a free object in an object pool. Provided you don't ask/give back memory from/to the OS, what malloc is doing is giving you an index…

I fully agree that there are similarities here. But we disagree about some of the details.

> you have essentially zero protection in Rust that helps you with finding Node-s that have been used for something else etc.

The most obvious technique is generations. You can of course do that in Zig as well.

> if you do use-after-free on a page claimed by the OS,

This assumes that you're working in the context where there is an OS. That isn't always the case. Also, there are other cases than just use-after-free: for example, compilers will optimize around null pointers being UB, which can cause other problems, whereas an index of zero does not get the same treatment.

But also, again: Zig does not use malloc for its ASTs, as far as I know. It uses lists and indices. I haven't literally read the code lately myself, but I would be surprised if they went back to malloc'ing individual nodes.

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

#177

Post by Joker_vD »

steveklabnik wrote: post #55
rtfeldman wrote: post #38

Earlier quoted context omitted.

> I think that for the hot binary patching / code reloading features, yes, that is going to need unsafe. But for regular old "producing an executable" compilation? Emitting machine code isn't the part that requires unsafe. The language's runtime is a more likely site to find unsafe. Agreed! Emitting machine code is not unsafe, since it's just writing bytes down - it's only once you execute that machine code that ther…

I am disappointed you're downvoted, Richard. This is a fine reply, and I hope you know that a minor quibble with a single line in the post doesn't mean that I think it's a bad one overall. (EDIT: a few minutes later, the parent comment is no longer grey.) I also think it's a good thing that you wrote the post in general, when I saw it pop up I was like "oh, of course, this post should exist!" I'm surprised I didn't t…

> Usually this would be done via an interpreter, so I'm not sure that it really requires unsafe either.

Well, I personally have written a const-expression evaluator that actually reuses the rest of the compiler: it compiles the expression in the current environment with some specific adjustments to the codegen settings, launches the temporary executable and gathers its output... frankly, it's more hassle than it's worth compared to writing a separate const-expression interpreter. Plus, of course, it also runs slower since most constant expressions are usually pretty trivial.

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

#179

Post by uaksom »

royal__ wrote: post #54

I don't even know what Zig is but I've seen this topic come up so many times on this site that I'm starting to think the people who are actually doing this are unsure themselves whether it's a good idea or not.

It does seem like they're trying to convince themselves. If you like Zig, that's a good enough reason to use it. Why waste time on language tribalism?

I have the same issue with "use the right tool" rhetoric. The right tool is the one that does the job and that you know best.

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

#180

Post by slekker »

gpm wrote: post #166
dnautics wrote: post #139

Earlier quoted context omitted.

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

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