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

71–80 of 336 posts

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

#71

Post by rwz »

drdexebtjl wrote: post #44
dev_l1x_be wrote: post #19

Zig is a pre-1.0 language while Rust is post-1.0. This alone is settles which one to pick for may developers. The library support is probably favours Rust too. Rust build times are much slower than Zig, I get that, but I rarely optimize software for build times.

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. Nowadays when you can just point an agent at release notes and have it update everything, I actually prefer not having to wait through rare major releases to get new language features.

> they want to be able to make breaking language changes

That sounds like it's not ready for production to me.

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

#72

Post by steveklabnik »

grayrest wrote: post #23
arthurbrown wrote: post #14

Interesting that OCaml was flexible and expressive enough to be used as a prototype testbed but not chosen as the implementation language, especially given the maturity of both. I would be surprised if Zigs incremental builds could be meaningfully faster than dune's. Cross compilation is great, but not mentioned in the "why Zig" section. Is memory control that crucial for a compiler? Rust itself was originally writte…

One of the primary goals for the Roc project is compiler speed. I presume OCaml is out of the running because it's not a systems language.

OCaml has often historically been considered a language that's been appropriate to write systems tooling like compilers, runtimes, and unikernels in, even though GC'd languages were/are not often considered for such projects.

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

#73

Post by tredre3 »

c-hendricks wrote: post #36
giancarlostoro wrote: post #31

One thing I wish Rust would improve over time is the builds. Its one of the biggest sources of wasted storage space on all my computers, builds a ton of libraries can take tens of gigs, it adds up very quickly. Not sure what the best solution is, one I found is to set the global build folder so dependencies get reused across projects, but imho it should be an OOTB default behavior whatever the real solution should be…

I always got a kick out of that, coming from a JavaScript background where people constantly harp on the size of node modules. My Tauri project, where the backend is much smaller code-wise than the frontend, has 9gb of rust artifacts (node_modules is 550mb for comparison)

Rust isn't great, and it shouldn't be a surprised since it's designed after npm. However one metric where nodes_modules is still worse for me is the sheer number of small files in it.

Having nearly one million files in nodes_modules isn't that unusual. The problem is that on most common file systems the minimum allocation is usually at least 4KB. So even if the actual data is less than 500MB, you end up with 4GB disk space used/wasted.

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

#74

Post by rtfeldman »

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…

Also a good point! TIL that Rust and C++ use interpreters for const, although of course that wouldn't work for running tests. Then again, in the specific case of Rust I believe rustc only compiles the tests and then something else like Cargo executes them. Of course, as I noted elsewhere, if rustc emits machine code and then cargo immediately executes it, there's the same opportunity for end user memory being corrupted (due to miscompilation) as if rustc and cargo shared a code base.

By the way, I thought your question was totally reasonable - my first thought reading it was "Oh yeah I wasn't trying to say that writing bytes is unsafe, I definitely should have worded that differently."

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

#75

Post by skybrian »

Aurornis wrote: post #57
skybrian wrote: post #50

Earlier quoted context omitted.

They are saying that running the compiled code is memory-unsafe when there is a compiler bug, and that’s what developers do next. The memory corruption happens in a different process. In this respect, effectively all the compiler should be treated sort of like an unsafe region because it requires extra care to avoid memory corruption bugs.

That's not what it says at all. The section we're talking about is for the compiler and emitting machine code > we ended up with about 1,200 uses of unsafe > remember that for compilers which emit machine code, like roc and rustc, doing memory-unsafe things is a big part of the job Anywhere talking about the `unsafe` keyword is within the Rust code.

The article is a bit confusing because they also write:

> Regardless of which process had the bug—the compiler or compiled program—in both cases the processor only did the bad thing because the compiler told it to. And in both cases the fix is the same: the compiler's code must change, since that code was what caused the memory corruption.

But yeah, I wonder what those 1,200 unsafe uses actually did?

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

#76

Post by pjmlp »

afdbcreid wrote: post #60
pjmlp wrote: post #47

Quite interesting the hand waving of security issues with Zig, oh well. If I want to use allocator debuggers I already have the production ready tools that exist for C and C++ for at least 30 years.

Compilers are not security sensitive, usually. And while UB could theoretically poison the generated code, this isn't a bigger risk than logic bugs.

Of course they are, anything can be a gateway to inject backdoors, if security is not taken into account.

And as mentioned, if what Zig offers is already in Purify, there is hardly any added value over C and C++, without the headaches of a niche language.

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

#77

Post by dnautics »

Ar-Curunir wrote: post #24
dnautics wrote: post #16

Earlier quoted context omitted.

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

No, it would fundamentally change how Zig works.

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

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

#78

Post by steveklabnik »

AlotOfReading wrote: post #65
steveklabnik wrote: post #52

Earlier quoted context omitted.

> probably be a linker I don't think that's any different either. The core job of linking isn't particularly unsafe. (Unless, similarly, you're doing the hot reloading stuff)

I've noticed that people equate "low level stuff" with unsafe, regardless of whether it's contextually justified.

I think it's an understandable prior. Historically, "low level stuff" was near-exclusively (see my comment below about OCaml...) written in unsafe languages. Even if that wasn't always literally required, it sometimes was, and so thinking this is the case was a reasonable thing to think.

It is only relatively recently that we have gained more realistic options in these spaces, and so not fully understanding the implications, or preferring the historically normal choices, is understandable.

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

#79

Post by dnautics »

veber-alex wrote: post #37
lioeters wrote: post #7

Earlier quoted context omitted.

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.

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.

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

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

#80

Post by epage »

giancarlostoro wrote: post #31

One thing I wish Rust would improve over time is the builds. Its one of the biggest sources of wasted storage space on all my computers, builds a ton of libraries can take tens of gigs, it adds up very quickly. Not sure what the best solution is, one I found is to set the global build folder so dependencies get reused across projects, but imho it should be an OOTB default behavior whatever the real solution should be…

We are trading away disk space for faster builds. We could make them faster in some cases by using even more...

On the other hand, it would be good to garbage collect those caches. We are wrapping up work on a new layout for intermediate build artifacts that will make it easier to GC them.

Post reply on HN