Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Zig as an alternative to writing unsafe Rust

zackoverflow.dev

Post reply on HN
Print view View original

11–20 of 230 posts

Re: Zig as an alternative to writing unsafe Rust

#11

Post by WalterBright »

bpolverini wrote: post #5

I buy the premise that Zig is better if you know you will have lots of pointer arithmetic going on. Having written a fair amount of unsafe C interop code in Rust, I feel like these critiques of the ergonomics are valid. The new #![feature(strict_provenance)] adds a new layer of complexity, that, I hope, improves some of this experience while adding safety. Rust's benefits are not free. The benefits of Rust's (wonderf…

> I usually find myself wishing I could have some macro where I just write in C and have it exposed as an unsafe back in Rust.

In D you can just import a .c file mycfile.c with:

    import mycfile; // C file filled with C functions
and they'll be treated as @system code by the D semantics. They're even inlinable.

Re: Zig as an alternative to writing unsafe Rust

#12

Post by ksec »

>There are endless debates online about Rust vs. Zig

I have never read anything that suggest or argued Zig as better than Rust, or "Rust vs Zig". Not on HN, not on Reddit, not on Twitter. In fact this link / title is the first one. ( I do wish the title was "Unsafe Rust" to better reflect on the content. )

There are however plenty who still prefer Zig over Rust, even knowing when Rust is better.

I also want to note RESF generally does not consider "unsafe" Rust to be Rust.

Edit: LOL I knew this would be heavily downvoted.

Re: Zig as an alternative to writing unsafe Rust

#13

Post by Karellen »

Wait, the benchmark to find the 35th fibonacci number took 1.077s for the Zig VM vs 1.657s for the Rust VM?

I realise that these VMs are going to be totally idiomatic Zig/Rust, with the most straightforward implementation possible, and little-to-no performance tuning, but even so - that's gotta be a typo, right? Or it's actually finding `fib(350)`? Or each "run" is actually finding `fib(35)` 100 (1000?) times?

Re: Zig as an alternative to writing unsafe Rust

#14

Post by WalterBright »

pyrolistical wrote: post #7

Isn’t var ptr: [*]u8 = @ptrCast([*]u8, &slice[0]); the same as var ptr = slice.ptr; ? Or am I missing something

The `slice.ptr` version is allowed in D, but `&slice[0]` is preferred because that comes with a check that the slice has a non-zero length and the pointer will actually point to something valid. That's why the former is allowed in @system code, and the latter is used in @safe code.

Re: Zig as an alternative to writing unsafe Rust

#15

Post by jrsyo »

nvrspyx wrote: post #2

The link is down for me. Perhaps HN hug of death? Below is link to the site on the Wayback Machine. https://web.archive.org/web/20230307172822/https://zackoverf...

Try ping "zackoverflow.dev" and "cname.vercel-dns.com". If only the former times out, it's possible your local ISP is blocking Vercel's IP. If that's the case, you could contact Vercel support to help assist.

Re: Zig as an alternative to writing unsafe Rust

#16

Post by j16sdiz »

satvikpendem wrote: post #10

Note, this is specifically talking about unsafe Rust versus Zig. Personally unsafe does have some rough edges, I'm looking forward to seeing how the Rust team manages to make it better in the future.

UB in unsafe rust sometimes "leaks" outside the unsafe scope and cause crashing elsewhere.

If rust can pair with a proof checker and let user write some correctness proof, it can be way more useful than the current borrow checker.

Re: Zig as an alternative to writing unsafe Rust

#17

Post by fizx »

Karellen wrote: post #13

Wait, the benchmark to find the 35th fibonacci number took 1.077s for the Zig VM vs 1.657s for the Rust VM? I realise that these VMs are going to be totally idiomatic Zig/Rust, with the most straightforward implementation possible, and little-to-no performance tuning, but even so - that's gotta be a typo, right? Or it's actually finding `fib(350)`? Or each "run" is actually finding `fib(35)` 100 (1000?) times?

It's intentionally using the naive 2^N solution to stress test lots of tiny function calls.

Re: Zig as an alternative to writing unsafe Rust

#18

Post by pjmlp »

Using custom allocators to taint memory for security checks is no better than what C and C++ toolchains have been providing for decades.

I was already using debug allocators in Visual C++ 5.0, with a memory report at the program exit.

For the latest documentation,

https://learn.microsoft.com/en-us/cpp/c-runtime-library/crt-...

Re: Zig as an alternative to writing unsafe Rust

#19

Post by TheRealPomax »

Karellen wrote: post #13

Wait, the benchmark to find the 35th fibonacci number took 1.077s for the Zig VM vs 1.657s for the Rust VM? I realise that these VMs are going to be totally idiomatic Zig/Rust, with the most straightforward implementation possible, and little-to-no performance tuning, but even so - that's gotta be a typo, right? Or it's actually finding `fib(350)`? Or each "run" is actually finding `fib(35)` 100 (1000?) times?

No caching, every recursive call runs the entire chain from scratch. fib(35) without caching takes roughly 14 million calls to resolve.

Re: Zig as an alternative to writing unsafe Rust

#20

Post by mr_00ff00 »

j16sdiz wrote: post #16
satvikpendem wrote: post #10

Note, this is specifically talking about unsafe Rust versus Zig. Personally unsafe does have some rough edges, I'm looking forward to seeing how the Rust team manages to make it better in the future.

UB in unsafe rust sometimes "leaks" outside the unsafe scope and cause crashing elsewhere. If rust can pair with a proof checker and let user write some correctness proof, it can be way more useful than the current borrow checker.

The correctness proof idea sounds intriguing. Ada does this already yes?

And do you have any examples of where UB from unsafe rust leaks to outside the program? Surely you would look back at the unsafe code always to fix it.

Post reply on HN