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

251–260 of 336 posts

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

#251

Post by gabriela_c »

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…

> I don't really think that this is true, in the way that it's written.

Well, it's true when it's written badly (eg. the same way as when somebody writes in-line "shellcode" by doing `*(T*)ptr = (T)val;` or similar.

I think there's some history of some compilers that were basically non-trivial to port to other architectures/bit-sizes b.c. of this piggybacking.

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

#252

Post by dwattttt »

samatman wrote: post #220
minraws wrote: post #93

Earlier quoted context omitted.

I would like to understand this more, > 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. Cause this hasn't been true for me or for anyone maybe your definition of memory being corrupted is the not same as mine. I am not even sure what you are trying to prove with this. I a…

Scenario A: A program has a memory vulnerability. That's bad, and the reason it's bad: attacker-controlled data can potentially trigger this vulnerability, which could even lead to privilege escalation. Scenario B: A program writes machine code in an executable region of memory, and the code has a memory vulnerability. That's bad, and the reason it's bad: attacker-controlled data can potentially trigger this vulnerab…

Or scenario D:

A text editor stores a URL in a location on disk, and another component then fetches and executes that with its current privileges.

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

#253

Post by lowbloodsugar »

> though (more on this later) and we ended up with about 1,200 uses of unsafe (out of our 300K lines of Rust code

Vs

>Rust code has a different source of memory-safety gaps: the unsafe sections that nearly every Rust program has somewhere in its dependencies. Unsafe Rust has all the memory unsafety risk of ReleaseFast Zig code, but none of the runtime checks to catch issues during development

Well if ReleaseFast would work for you then just write that in rust. The unsafe keyword can be used to write a shitshow, or it can be used to write small pieces of functionality, such as ArcUnion, that are safe to use. I don’t agree that every application has to have any unsafe code. If you find yourself needing it, then you go build the abstraction you need in another crate, miri the fuck out of that, and then just consume it in your application.

If you’re fine with the shitshow, then use zig, because that’ll improve rusts stats.

If you think you’re in the magical “I know what I’m doing and I need the extra performance” then you probably don’t know what you’re doing. You’re young. Knock yourself out. I’ve written assembly language hackery for video games you wouldn’t believe. Would I use any of that for a language others are going to use? You’re not that smart. And if you are, someone else on your project isn’t. Just a matter of time.

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

#254

Post by estebank »

ploxiln wrote: post #244
pjmlp wrote: post #86

Earlier quoted context omitted.

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.

I think it's a reaction to many simpler advocates of Rust saying "it's unsafe and irresponsible of you to not use Rust, you can't write software in C or C++ or Zig (or Go?) and have memory unsafety and put your users at risk, it's not safe, you have to use Rust to be safe". Freakin' safety. I like doing lots of unsafe things in life: rock climbing without gear (short bouldering sections on hiking trails), bicycling a…

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

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

#256

Post by fragmede »

dwattttt wrote: post #252
samatman wrote: post #220

Earlier quoted context omitted.

Scenario A: A program has a memory vulnerability. That's bad, and the reason it's bad: attacker-controlled data can potentially trigger this vulnerability, which could even lead to privilege escalation. Scenario B: A program writes machine code in an executable region of memory, and the code has a memory vulnerability. That's bad, and the reason it's bad: attacker-controlled data can potentially trigger this vulnerab…

Or scenario D: A text editor stores a URL in a location on disk, and another component then fetches and executes that with its current privileges.

Or in this day and age, that component is an AI agent, and it executes with the things stored in its memory, and is abused into exfiltrating data.

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

#258

Post by wolvesechoes »

jandrewrogers wrote: post #203
sph wrote: post #167

Earlier quoted context omitted.

I don’t think there’s too many of us on the ‘GC did nothing wrong’ hill. Reading the average HN opinion, it seems everybody is writing high-performance latency-sensitive systems that would implode if a response would take 1 ms longer than normal.

Sampling bias. Most of the people responding are probably those with a strong opinion because of what they work on. Everyone else is likely relatively indifferent to it. It is a misconception that GCs only affect latency-sensitive systems. High-performance throughput-optimized systems are also sensitive at ~1µs granularity for different reasons, so GCs are not used there either. That a GC is adverse to the performanc…

> Most of the people responding are probably those with a strong opinion because of what they work on

Quite the opposite. People here have strong opinion because they work on web apps and CLI toys.

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

#259

Post by solatic »

afdbcreid wrote: post #195
solatic wrote: post #136

Earlier quoted context omitted.

> Zig has no private fields You may have missed the point here. You could add a comment to the struct field that marks the field as private, and build a TypeScript/JSDoc analogue that analyzes all accesses to the field and fails if it finds accesses from functions that aren't part of the struct that owns the field. You don't even need a comment on the field - you could copy Go's convention, add a comment to the struc…

I have picked private fields as an example of feature that is needed because it is very simple. You're right that you can build an analyzer (with additional code annotations) to support that, but it's only one example. Take another example: unsafe traits. They are fundamental to some safety encapsulations, most famously concurrency (`Send`/`Sync`). Here you cannot just build an analyzer to mark something unsafe, beca…

> You can, of course, add traits. But at this point you're essentially creating your own language that compiles to Zig

I think herein lies the rub. What's the difference between a static analysis tool and an actual separate language that transpiles to the original? Hypothetically - again, very un-ergonomically - you could add traits to Zig code in comments, or in example-traits.typezig files that would be skipped by the Zig compiler (like how *.d.ts files are skipped). How much of a language is writing code in a particular syntax, versus how much of a language is writing code that will pass a tool "building" it, versus how much of a language is about the final compiled output that you get from the tool? All static analysis tools that support line-level exceptions are, essentially, programmed by comments, with their own language (typically highly simplified compared to a "full" programming language), that affect whether or not the "language" passes or not. What Typescript/JSDoc shows is that, actually, much more complicated tooling can be built with this programming-by-comments model than had been done before (to my knowledge), and thus even more powerful still tooling could be built with that model.

Of course there's a difference between static analysis and a language that transpiles. But perhaps it's more a question of degree than a simple binary classification.

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

#260

Post by pjmlp »

dnautics wrote: post #113
pjmlp wrote: post #92

Earlier quoted context omitted.

What a joke, ignoring Erlang, and the custom schedulers from JVM and CLR runtimes.

Erlang's scheduler is not sophisticated, which is what makes it AWESOME. but yeah. i would be surprised if the JVM's scheduler is not more sophisticated than go's if for no other reason than it has way more knobs you can tune. you know they put that knob in there because someone (probably Google cough cough) asked for it

The missing part is that if what is in box isn't enough, both JVM and CLR allow you to fully customise how the scheduling algorithm works.
Post reply on HN