全部文章0
Hacker Newsjorangreef··访问 1

How Our Rust-to-Zig Rewrite Is Going

原网页

Article URL: https://rtfeldman.com/rust-to-zig

Comments URL: https://news.ycombinator.com/item?id=48933149

Points: 363

# Comments: 202

Hacker News 讨论

367 points · 204 comments · 查看原帖

  1. steveklabnik

    I think this is a fine post. But one comment: > remember that for compilers which emit machine code, like roc and rustc, doing memory-unsafe things is a big part of the job I don't really think that this is true, in the way that it's written. 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.

  2. landr0id

    >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 "use-after-free" or "UaF" never occurs on that documentation page. Searching for "safety-checked" doesn't yield any related hits either. Unless maybe they're using the DebugAllocator in release builds? Even that does not reliably surface UaF. https://landaire.net/memory-safety-by-default-is-non-negotia...

  3. arthurbrown

    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 written in OCaml, same with WASM. I'm curious about what milestone gets reached where the maintainers collectively decide to transition away.

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

  5. feelamee

    > As discussed earlier, having full control over allocations and deallocations is what I want in our compiler's implementation. And in tests, I also appreciate the testing allocators detecting leaks—it can even detect leaks in compiled Roc code! Unfortunately, to get that benefit requires a lot of "init this, defer deinit" code in tests that has to be correct or else the test fails on a memory leak. None of that is necessary in Rust. I care more about the compiler's implementation being the way I want it than the tests looking nicer, but in a perfect world I could somehow have both. haha, just for fun... do you want a C++ in your perfect world :D?

  6. norir

    This piece would have been a lot more compelling if they had actually done science on selecting a language for compiler development. From what I can tell, they had an untested hypothesis that a low level systems language is necessary for a high performance compiler https://www.roc-lang.org/faq#self-hosted-compiler and from that concluded that their only choice besides rust was zig. I know from experience that this initial assumption is wrong. Compiler performance is dominated by algorithms. The fastes managed languages tend to be at worst within a factor of two for wall time on any given algorithm. Algorithmic differences can be unbounded in their performance gaps. Zig itself is a perfect counterexample to the theory that writing a compiler in a low level systems language will lead to a fast compiler. Roc seems to compile at around 15k lines per second. That is not fast. There were evide

  7. giancarlostoro

    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.

  8. bbkane

    Tangentially relates, but if any Roc devs are around I'm curious about the use cases for Roc. It's supposed to be a scripting language right you embed into your C ABI right? Do you see it competing with WASM for the plugin use case (i.e. a really large Roc platform)? Why would an app author prefer to expose a Roc layer to their app rather than a WASM layer? With a WASM layer, plugin devs can write in any language. Another use case I've heard from it is as a more app-level language (i.e. a really small Roc platform). Do you see it competing with Gleam for server side http code? Do you see it competing with Elm for client side code?