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

141–150 of 336 posts

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

#141

Post by narnarpapadaddy »

nicoburns wrote: post #138
narnarpapadaddy wrote: post #53

Earlier quoted context omitted.

I agree that it’s not inherent to emitting machine code but I do think it reflects a different set of priorities. In extremely high performance code you use different data structures and algorithms and change your approach to memory allocation. TigerBeetle famously does all memory allocation once on startup. Roc is attempting to make a similar set of trade-offs in their compiler as Zig, so it makes sense that the aut…

> In extremely high performance code you use different data structures and algorithms and change your approach to memory allocation. It's worth noting that the reason Rust doesn't include support for custom memory allocation patterns like Zig does has nothing to do with memory safety. It's more of a historical accident that it just wasn't something that was prioritised early in the projects history and is now hard to…

No disagreement in principle; in practice taking that approach in Zig is safer than in Rust, because in Rust it’s “all or nothing.”

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

#142

Post by tadfisher »

pjmlp wrote: post #86
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…

Many people try to twist the fact memory safe languages have unsafe code blocks to make the pivot that why bother. It is like someone arguing that since they always bump the head somehow while wearing seatbelts, then they are only a nuisance and should not be used.

Because they view "unsafe" as an escape hatch instead of a feature. It's a way to encapsulate dangerous behavior, tightly, with clear postcondiitions. Sometimes it's the only way to do things like interact with inherently unsafe FFI code, or hardware.

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

#143

Post by benj111 »

paulddraper wrote: post #21
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.

Maybe in theory. In practise you have thing like super optimisers. You have side effects that the compiler needs to understand etc.

That said I'm struggling to think of something that would need to be unsafe.

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

#144

Post by inigyou »

nvme0n1p1 wrote: post #129
inigyou wrote: post #120

Earlier quoted context omitted.

Then that's equivocation. Why do we want a very specific form of safety instead of wanting safety in general?

> safety in general This is impossible. General words like "safe" and "good" are subjective, and useless in a technical context unless you ground the discussion by giving them specific definitions. Otherwise everyone ends up talking past each other.

Okay, thanks for debunking all good products, safe houses and clean water. I guess they are just products, houses, and water.

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

#145

Post by steveklabnik »

nicoburns wrote: post #138
narnarpapadaddy wrote: post #53

Earlier quoted context omitted.

I agree that it’s not inherent to emitting machine code but I do think it reflects a different set of priorities. In extremely high performance code you use different data structures and algorithms and change your approach to memory allocation. TigerBeetle famously does all memory allocation once on startup. Roc is attempting to make a similar set of trade-offs in their compiler as Zig, so it makes sense that the aut…

> In extremely high performance code you use different data structures and algorithms and change your approach to memory allocation. It's worth noting that the reason Rust doesn't include support for custom memory allocation patterns like Zig does has nothing to do with memory safety. It's more of a historical accident that it just wasn't something that was prioritised early in the projects history and is now hard to…

It's also important to note that Rust as a language does not know about the heap at all, it is purely a library concern. This means that "doesn't include support for custom memory allocation patterns" is purely talking about standard library data structures, and if you need a ton of performance, you're probably going to be writing your own anyway.

It will be nice when the Allocator trait stabilizes so that the ecosystem can coordinate on making this stuff pluggable, but that's not a direct blocker for getting things done if you need to do things today.

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

#146

Post by uecker »

demosthanos wrote: post #87
afdbcreid wrote: post #60

Earlier quoted context omitted.

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

> Compilers are not security sensitive, usually. The compiler is one of the most significant trust boundaries we have. Its decisions can intentionally or unintentionally create vulnerabilities in programs compiled by the compiler, which means that if you can compromise a compiler you can compromise everything downstream. Unsafe memory access in a compiler can be exploited in order to hijack the compiler itself (this…

For this to be useful you would need to modify the compiler binary to make the exploit persistent. Otherwise why put an exploit for the compiler in the source to so that the compiler can put some malware in a binary, when you can put the malware in the source directly?

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

#148

Post by ameliaquining »

minraws wrote: post #99
djha-skin wrote: post #51

Earlier quoted context omitted.

Chief design goals were radically easy concurrency and speed of compilation.

Speed of compilation feels like a distant second in terms of goals given the weird new generic features they keep adding.. I was fine with basic generics they complicated it quite a bit much for my liking.

What weird new generic features? Generic type aliases? Those aren't very complicated.

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

#149

Post by rtfeldman »

Liquid_Fire wrote: post #110
rtfeldman wrote: post #74

Earlier quoted context omitted.

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

> 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 Your tests run in an entirely separate process from the compiler (and from cargo). This makes it very different from memory corruption in the compiler: - The test process can only corrupt its own memory. - You don't need…

> Does roc run tests in the same process as the compiler?

We do for tests of pure functions, yes.

> Your tests run in an entirely separate process from the compiler (and from cargo).

That's a great point and a relevant distinction, although Rust tests can run arbitrary I/O, so it's not like having them be in a separate process means memory corruption is harmless! :)

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

#150

Post by ameliaquining »

kstrauser wrote: post #107
epage wrote: post #80

Earlier quoted context omitted.

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.

Can you talk a little more about that? How would that work, and what would the developer experience be like when using it?

The proposal's at https://hackmd.io/@rust-cargo-team/SJT-p_rL2; progress is tracked at https://github.com/rust-lang/cargo/issues/12633.
Post reply on HN