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

91–100 of 230 posts

Re: Zig as an alternative to writing unsafe Rust

#91

Post by dist1ll »

mr_00ff00 wrote: post #20
j16sdiz wrote: post #16

Earlier quoted context omitted.

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.

There is a huge body of work around proof-based programming.

If you're looking for a full blown SMT solver and general purpose dependently-typed PL have a look at F*

https://fstar-lang.org

Re: Zig as an alternative to writing unsafe Rust

#92

Post by coderedart »

malcolmstill wrote: post #81
stouset wrote: post #37

Earlier quoted context omitted.

People keep saying this and I just do not get it . It's just… not that bad?

There are a number of sources of noise in rust, but the one I find most annoying (because it's also so common) is the double colon. My current theory is that it's because the colon is the same height as lowercase letters. If you end up with a long::run::of::module::names, I find it all just blurs into one.

can you please point out a few more annoyances in rust syntax? I am a newbie playing with language design and could use some perspective :)

Re: Zig as an alternative to writing unsafe Rust

#93

Post by indymike »

DonaldPShimoda wrote: post #58
pie_flavor wrote: post #50

Earlier quoted context omitted.

As long as you don't care about UB or edge cases. Every time Rust makes something hard, it's forcing you to handle an edge case up front.

It's blowing my mind how many commenters here don't understand this. Rust isn't hard just for fun. It's hard because the code you've been writing for so long is actually bad and you've not been thinking it through appropriately. This is why we keep finding serious bugs in code that is decades-old, despite the belief that code so old must be well-tested by now.

> we keep finding serious bugs in code that is decades-old

I'm sure of one thing: we will find many and different bugs in decades old rust code one day, too. The problem with software is that it has code in it ;-)

Re: Zig as an alternative to writing unsafe Rust

#94

Post by anon4242 »

woodruffw wrote: post #79
guipsp wrote: post #69

Earlier quoted context omitted.

The rust undefined behaviour rules are stricter than C: mutating a non mutable reference is UB, for example. Non mutable references don't exist in C.

> Non mutable references don't exist in C. Sure they do: C has a well-defined notion of const-correctness. If you mutate through a `const`, you're invoking undefined behavior. Both C and C++ allow you to strip `const` from a const-qualified value or reference, but only under the condition that you don't actually modify that value. Edit: which, in case it isn't clear, means that Rust's UB is exactly the same as C's in…

Actually in C++ you are allowed to strip const and modify the value as long as the original object (not necessarily object in an OO sense) isn't const [1].

[1] https://en.cppreference.com/w/cpp/language/const_cast

Re: Zig as an alternative to writing unsafe Rust

#95

Post by nyanpasu64 »

> If I have a raw pointer to an array of data (*mut T), I can turn it into a slice &mut [T], and I get to use a for ... in loop on it or any of the handy iterators (.for_each(), .map(), etc.).

I wonder if *mut [u8] would be a workable alternative to &mut [u8]. I haven't looked into creating such pointers yet, but `fn f(a: *mut [u8]) {}` is legal while `fn f(a: *mut [u8]) { a.len(); }` doesn't compile on stable due to https://github.com/rust-lang/rust/issues/71146. Looks like raw slice pointers aren't fully baked yet.

Re: Zig as an alternative to writing unsafe Rust

#96

Post by edflsafoiewq »

zamalek wrote: post #75
ilrwbwrkhv wrote: post #24

Earlier quoted context omitted.

On top of that Rust might be the ugliest modern language.

That is extremely subjective. I find the syntax extremely easy to read, and there are significantly fewer edge cases than nearly all other mainstream languages: * Why does C# require a break; under switch? * What about the "Most Vexing Parse"? * Why does Zig change capitalization of @import and @TypeOf? Rust is an extremely "guessable" language. It's highly likely that experimenting with syntax will succeed in Rust,…

> Why does Zig change capitalization of @import and @TypeOf?

TypeOf returns a type. Corresponding to how type names are uppercase.

Re: Zig as an alternative to writing unsafe Rust

#97

Post by munificent »

jasonjmcghee wrote: post #72
pie_flavor wrote: post #54

Earlier quoted context omitted.

It's not about actual ugliness, it's just something that is hard to articulate as something other than ugliness. https://matklad.github.io/2023/01/26/rusts-ugly-syntax.html

I'm going to assume, based on when he said "As a slightly more serious and useful exercise" and then proceeds to remove each piece of the code that's intentionally there for performance and safety, that the whole post is satire?

The second sentence of the post is the thesis: "I think that most of the time when people think they have an issue with Rust’s syntax, they actually object to Rust’s semantics."

By removing the ugly "syntax" (and thus also removing important semantics), they're showing that the reason Rust has a lot going on syntactically is because the code is actually expressing important semantics. You can't have a nicer Rust syntax without losing semantics in the process.

Re: Zig as an alternative to writing unsafe Rust

#98

Post by bxparks »

malcolmstill wrote: post #81
stouset wrote: post #37

Earlier quoted context omitted.

People keep saying this and I just do not get it . It's just… not that bad?

There are a number of sources of noise in rust, but the one I find most annoying (because it's also so common) is the double colon. My current theory is that it's because the colon is the same height as lowercase letters. If you end up with a long::run::of::module::names, I find it all just blurs into one.

That is a very interesting observation. I am starting to have a similar distaste for the visual noise caused by the ':' in my fully type-annotated Python code. This is particularly noticeable after spending a few weeks writing Golang, then going back to my Python code. The Go code feels far cleaner syntactically and visually.

Re: Zig as an alternative to writing unsafe Rust

#99

Post by munificent »

estebank wrote: post #53
dhruvdh wrote: post #46

Earlier quoted context omitted.

There is no way it will take a whole second regardless. Even when compiled in debug mode, it takes about 100 ms. Try it here, I had Bing AI write it out - https://play.rust-lang.org/?version=stable&mode=release&edit...

OP isn't talking about the performance of Rust code to calculate fib(35), but rather the performance of a Rust implementation vs a Zig implementation of an interpreted language executing code to calculate fib(35). They are saying that the Rust VM they wrote is slower than the Zig VM they wrote.

And, in particular, an interpreted dynamically typed language.

Re: Zig as an alternative to writing unsafe Rust

#100

Post by somethingor »

zamalek wrote: post #75
ilrwbwrkhv wrote: post #24

Earlier quoted context omitted.

On top of that Rust might be the ugliest modern language.

That is extremely subjective. I find the syntax extremely easy to read, and there are significantly fewer edge cases than nearly all other mainstream languages: * Why does C# require a break; under switch? * What about the "Most Vexing Parse"? * Why does Zig change capitalization of @import and @TypeOf? Rust is an extremely "guessable" language. It's highly likely that experimenting with syntax will succeed in Rust,…

@TypeOf returns a type: https://ziglang.org/documentation/master/#Names
Post reply on HN