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

281–290 of 336 posts

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

#281

Post by tialaramex »

duped wrote: post #223
MaulingMonkey wrote: post #196

Earlier quoted context omitted.

I adore unsafe, appreciate it as a feature... but it is an escape hatch. One that is sometimes necessary, one that is sometimes not necessary but might still be (ab)used for performance, or initial 1:1 porting of C/C++ code. There are a lot of cases where that escape hatch should probably welded shut though. Fortunately, the Rust ecosystem has tools like `cargo geiger`, and straight out of the box I can also write: /…

I feel like this perpetuates a bad mental model. Unsafe is not an escape hatch. Code within unsafe blocks must uphold the same semantics as code outside it but the compiler cannot guarantee that those semantics are upheld. If we're using analogies, `unsafe` is like a "hard hat required" sign. There's nothing intrinsically different about the space inside or outside of it, other than that you can't be sure a brick isn…

Yeah, I'd have more sympathy for the "It's an escape hatch" model of this feature if the C++ approaches to this problem didn't keep adding actual escape hatches and waving away concerns as "Rust does this too so it's fine".

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

#282

Post by Liquid_Fire »

rtfeldman wrote: post #149
Liquid_Fire wrote: post #110

Earlier quoted context omitted.

> 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! :)

True, but not sure how it's relevant - you don't need memory corruption for the test to perform arbitrary I/O. And even if you trust the tests to not do anything bad, you don't need memory corruption for this to be an issue - any bug in the code emitted by the compiler could cause bad things to happen.

But all of this is ultimately completely unrelated to the concept of "unsafe". You can delete your home directory just fine in safe Rust/Go/Python/etc. You can write a compiler that emits broken code in the same languages; even in a 100% pure functional language with 0 side effects and a perfect bug-free implementation.

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

#283

Post by afdbcreid »

pjmlp wrote: post #269
afdbcreid wrote: post #222

Earlier quoted context omitted.

Considering that you often run the code after you compile it, it might not matter. Anyway, like it or not, most compilers don't consider themselves security sensitive and will not consider malicious code that is able to hijack the compiler a security vulnerability.

Ken Thompson won the award for nothing, yeah.

Totally unrelated; The trusting trust attack was about downloading a malicious compiler because malicious code was injected into it in some early version.

(And if you ask me, it was indeed overrated, but that's unrelated).

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

#287

Post by pjmlp »

jandrewrogers wrote: post #270
pjmlp wrote: post #265

Earlier quoted context omitted.

Real time GC as used by the military in weapons control systems, and on factory automation robots, keeping PTC and Aicas in business, people pay to use them.

TBH, physics limits how latency-sensitive weapons systems need to be and you can largely just disable the GC in these contexts. They use CPUs from the 1990s to do hypersonic terminal guidance. You don’t have to do any performance engineering for many latency-sensitive weapon systems. Could probably write it in Javascript. For throughput-optimized systems, some of which are real-time, you never see a GC. That loss in…

Throughput-optimized systems like HFT?

https://www.lmax.com/exchange/technology

No, you could not guide battleship weapons in Javascriptt

https://www.lockheedmartin.com/en-us/products/aegis-combat-s...

https://dl.acm.org/doi/abs/10.1145/2402709.2402699

And no they don't disable the GC, they have real time GC implementations,

https://www.ptc.com/en/products/developer-tools/perc

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

#289

Post by tmtvl »

znkr wrote: post #276
estebank wrote: post #254

Earlier quoted context omitted.

There's a material difference on one taking risks for oneself and one taking risks where the brunt of the consequences fall on others.

You mean like driving a car?

Yep: there's a difference between driving a car in traffic and driving a car in a rally or in an endurance race. There will always be some rules and regulations unless you're on your own privately owned race track with no one else on there, but the regulations can differ greatly depending on the situation.

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

#290

Post by pjmlp »

afdbcreid wrote: post #283
pjmlp wrote: post #269

Earlier quoted context omitted.

Ken Thompson won the award for nothing, yeah.

Totally unrelated; The trusting trust attack was about downloading a malicious compiler because malicious code was injected into it in some early version. (And if you ask me, it was indeed overrated, but that's unrelated).

That was one way the attack could be done, there are many other ways if the compiler binary can be open for manipulation.
Post reply on HN