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

111–120 of 336 posts

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

#111

Post by [deleted] »

landr0id wrote: post #81
flohofwoe wrote: post #46

Earlier quoted context omitted.

The DebugAllocator catches use-after-free (at least on page-level), but at the cost of never recycling memory addresses (e.g. it eats through the virtual address space). https://ziglang.org/documentation/master/std/#src/std/heap/d... For higher level code, "generation-counted index handles" might be the better solution to provide temporal runtime memory safety, not part of Zig the stdlib though. Or even better: never…

>The DebugAllocator catches use-after-free (at least on page-level) To clarify, is that to say that you have to use the `std.heap.page_allocator` as its backing allocator?

[deleted]

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

#113

Post by dnautics »

pjmlp wrote: post #92
onlyrealcuzzo wrote: post #9

Earlier quoted context omitted.

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.

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

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

#115

Post by minraws »

landr0id wrote: post #12

>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 "us…

I as someone with writing Zig a bunch, can safely say if it does it hasn't even worked for me.

I am talking from experience from a pre-ai human mitts writing code perspective maybe Zig + LLMs do some magic.

The more I read the article the more I feel like this is just bad not sure if I should be giving it as much latitude as I have been in my prior comments.

There are other claims as well that are weirdly phrased at least.

Reads like an article written to justify some arguments they had rather than a genuine take at this point.

But I will give the benefit of doubt I enjoy weird articles, languages and share a dislike for aggressive AI-ness of all things.

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

#116

Post by kfuse »

veber-alex wrote: post #37
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.

It's impossible to add a borrow checker to any existing language. The reason Rust has a working borrow checker is because every part of the language from structs, enum, traits, generics and all the way to the syntax itself has been designed to support lifetimes and borrow checking. It's is not something you can just tack on to an existing language without fundamentally changing it.

C# was already a very mature language when it had referenes and later "ref safety" added to it.

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

#118

Post by dminik »

andriy_koval wrote: post #100
dminik wrote: post #64

While I'm a rust enthusiast, I do agree that certain languages lend themselves well to particular domains. So a rewrite from Rust to something better suited is fine by me. In fact, while I do work on a rust project, I would not have and still would not recommend it as the choice for that particular project. That being said, I had to do some double takes while reading this. > https://rtfeldman.com/rust-to-zig#memory-s…

> In fact, while I do work on a rust project, I would not have and still would not recommend it as the choice for that particular project. wondering what type of project is that? I think besides some very embedded projects with very little memory where you need C/assembly, rust is good enough for all kind of projects..

I work both on a pretty much bog-standard web (GraphQL) backend and the frontend that uses it. We switched over from Apollo on node to async-graphql on Rust.

The runtime performance is much better, but the compiler time performance is terrible. To be fair, this is mostly the fault of async-graphql, but that doesn't really matter all that much. For example, it's not uncommon for a single character SQL query change to trigger over a minute long incremental rebuild.

The rust compiler is just choking on the number of generics and codegenned functions.

I've personally looked at how to improve this, but short of breaking up the type graph using federation, nothing can help. Not even cranelift makes a noticeable dent.

Additionally, the team started off composed by a bunch of TypeScript/React/Node developers, so mistakes were made along the way.

Honestly, I would have recommended to just use C#.

That's not to say that I don't think Rust can work for web development. We have some (GraphQL-less) services where Rust is a great fit. Just maybe shouldn't have been the default. That or give up graphql ...

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

#119

Post by vips7L »

Hinrik wrote: post #5
onlyrealcuzzo wrote: post #3

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

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

Is the Go GC that special? Is it even generational yet?

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

#120

Post by inigyou »

AlotOfReading wrote: post #101
inigyou wrote: post #88

Earlier quoted context omitted.

I'll play devil's advocate. I think emitting machine code intended to run is unsafe because you could emit unsafe machine code, which could run. It's the whole system that is either safe or not, not the individual components. If your system gets hacked by a buffer overflow in the end, nobody cares whether it was the linker that overflowed or the code emitted by the linker.

"Safe" has a very specific definition in Rust. It's not identical to the broader definition used in technical English. You can easily have safe rust code with behaviors any reasonable layperson would call unsafe, like crashing a plane. The original article, comment, and replies were using the word in the Rust sense from my reading, not the English meaning.

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