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

21–30 of 336 posts

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

#21

Post by paulddraper »

steveklabnik wrote: post #11

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

Agreed, that’s disturbingly incorrect.

If anything, compilers are perfect models of trees and well formed programs.

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

#22

Post by [deleted] »

onlyrealcuzzo wrote: post #9
Hinrik wrote: post #5

Earlier quoted context omitted.

Layperson here: what is special about Go's runtime, aside from the GC?

It's literally the most sophisticated scheduling engine in the world. In practice, Go can typically outperform Rust in throughput (using more memory), despite having a mountain of disadvantages against it in theory. That's how good the Go scheduler/runtime is.

[deleted]

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

#23

Post by grayrest »

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.

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

#24

Post by Ar-Curunir »

dnautics wrote: post #16
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.

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

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

#25

Post by jcgl »

onlyrealcuzzo wrote: post #9
Hinrik wrote: post #5

Earlier quoted context omitted.

Layperson here: what is special about Go's runtime, aside from the GC?

It's literally the most sophisticated scheduling engine in the world. In practice, Go can typically outperform Rust in throughput (using more memory), despite having a mountain of disadvantages against it in theory. That's how good the Go scheduler/runtime is.

This is the first I've heard anyone claim higher throughput for Go than Rust. Any articles you'd point to to learn more?

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

#26

Post by satvikpendem »

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 compiler is incredibly fast. I wonder how it'd fare with Jane Street's extensions for the borrow checker etc in OxCaml, if it's good enough for their HFT I'm sure it's good enough for a new language.

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

#27

Post by Aurornis »

steveklabnik wrote: post #11

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

That line confused me, too. What parts of their compiler require memory-unsafe operations to produce machine code?

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

#28

Post by EPWN3D »

steveklabnik wrote: post #11

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

Yeah that is definitely 1000% wrong. A compiler can do its job with totally abstract data structures. If anything would need to do unsafe stuff in memory, it would probably be a linker.

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

#30

Post by Aurornis »

onlyrealcuzzo wrote: post #9
Hinrik wrote: post #5

Earlier quoted context omitted.

Layperson here: what is special about Go's runtime, aside from the GC?

It's literally the most sophisticated scheduling engine in the world. In practice, Go can typically outperform Rust in throughput (using more memory), despite having a mountain of disadvantages against it in theory. That's how good the Go scheduler/runtime is.

> n practice, Go can typically outperform Rust in throughput (using more memory), despite having a mountain of disadvantages against it in theory

This is a huge claim that disagrees with both my real-world experience and everything I've seen from artificial comparisons.

Every high performance Go system I've worked on has quickly reached the point where we're optimizing memory management and doing things that would have been explicit in a non-GC language like Rust anyway.

The Go runtime is amazingly optimized, but it comes with overhead over doing the same work directly in a lower level language.

Post reply on HN