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

141–150 of 230 posts

Re: Zig as an alternative to writing unsafe Rust

#141

Post by Karrot_Kream »

ok123456 wrote: post #9

This pretty much mirrors my experience. Rust is the inverse of Perl: It makes the easy stuff hard. Writing basic data structures isn't a niche, esoteric edge case. There may be a crate that "solves" what you're trying to do. But does it rely on the std---(i.e., is it unusable for systems programming)? Is it implemented making gratuitous copies of data everywhere? Does it have a hideous interface which will then pollu…

One technical criticism I have of the "community" is that a non-trivial portion of the community thinks that if the borrow checker forbids a program then the program is a bad program. None of the core contributors do this and many prominent library authors are upfront that this is not true, but I've read lots of comments and posts in Rust rooms about how the borrow checker should be the way to write and architect correct programs.

The Rust borrow checker imposes a style that is safe, but is not the only safe way to write that program.

Re: Zig as an alternative to writing unsafe Rust

#142

Post by malcolmstill »

dureuill wrote: post #131
malcolmstill wrote: post #115

Earlier quoted context omitted.

To be honest that's the major one for me. Someone else has mentioned lifetime annotations, but those uncommon enough that I don't find it much of an issue. If I was to think about it: comparing rust to zig, zig benefits a lot from error and optional types having their own syntax rather than being treated like any other type. For example a return type of: Result , Error>> in rust is rendered (mostly) equivalently in z…

i'm curious, how do you specify the error type in the zig version?

So usually you don't have to specify the error type. The Zig compiler works out what errors are returned from the function by looking at any errors returned directly or errors returned from other functions called within the body of the function. That set of errors forms an enum that is the actual error type, you just don't have to write that out explicitly. An example might be:

    fn someFunction(a: usize) !usize {
        if (a
The compiler infers the error type of `someFunction` as:

    error {
        LessThanTen,
        LessThanTwenty
    }
When you then `switch` on an error type, the compiler will exhaustively check that you have handled all the cases.

Note the "(mostly) equivalently" was a reference to the fact that Zig errors can't (currently) contain any other information, whereas an error in rust can carry other information.

Also note that the compiler can't infer the error type in all case, for example in the case of a recursive function. In that case you do need to explicitly write out the error set.

Re: Zig as an alternative to writing unsafe Rust

#143

Post by throwawaymaths »

DonaldPShimoda wrote: post #62
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

It's amusing to me that many of the people who complain about the aesthetics of Rust's syntax are quick to also say bad things about, like, Haskell, or Lisps, or other languages with comparatively low syntactic overhead. I think the thing people don't like about Rust is that it looks vaguely C-like but is clearly not C. People might like it better if it was further removed (aesthetically) from C's syntax. But then th…

Languages on the two ends of the spectrum are "not that great", IMO. Lisp is awful because even though there are very few greeblies, it introduces a TON of cognitive overhead, because you need to be constantly thinking about what something is, because the layout is TOO uniform. Rust on the other hand has a lot of greeblies and you have to remember what it is and what they do. For example macro attributes (and all their hidden effects) as well as the turbofish. Even some things like -> for the function body are simply unnecessary.

Re: Zig as an alternative to writing unsafe Rust

#144

Post by dureuill »

malcolmstill wrote: post #142
dureuill wrote: post #131

Earlier quoted context omitted.

i'm curious, how do you specify the error type in the zig version?

So usually you don't have to specify the error type. The Zig compiler works out what errors are returned from the function by looking at any errors returned directly or errors returned from other functions called within the body of the function. That set of errors forms an enum that is the actual error type, you just don't have to write that out explicitly. An example might be: fn someFunction(a: usize) !usize { if (…

Ah interesting approach, thx for the answer.

1. Doesn't that risk introducing accidental breaking changes by adding a new error to the set in the implementation, since the set of errors is inferred from the implementation? Having a compile error in this case in Rust is often the last barrier standing between me and an accidental major semver bump (since callers have to exhaustively match on the error conditions) 2. Can you have data in the variants of the error enumeration?

Re: Zig as an alternative to writing unsafe Rust

#145

Post by q3k »

jcranmer wrote: post #123
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?

I suspect the things that people are reacting to are a mixture of the following: * Types in Rust use prefixing to create derived types whereas C family languages generally use postfixing. A pointer is i32, not int ; an array [i32; 5], not int[5], etc. This makes special characters appear more heavily at the beginning of the scan line, and probably makes them slightly more noticeable as a result. * Lifetimes have the…

> * Passing in explicit generic type arguments for a function requires an extra :: for seemingly no reason.

There is a very good reason for this. Behold, the Bastion of the Turbofish.

https://github.com/rust-lang/rust/blob/master/tests/ui/parse...

Re: Zig as an alternative to writing unsafe Rust

#146

Post by foldr »

alpaca128 wrote: post #108
foldr wrote: post #66

Earlier quoted context omitted.

One random thing that bugs me about Rust's syntax is array initialization. In Go I can initialize an array (or strictly speaking a slice) of structs like this: var foo []my_struct = {{"foo", 1, "bar"}, {"foo", 1, "bar}, ...} This is often useful in tests (where each struct value represents a test case). Rust doesn't seem to offer any similarly compact initialization syntax for arrays or Vecs. You have to write some a…

Dropping field names from definitions like Go would make the syntax inconsistent with destructuring and pattern matching. It's always possible to define a constructor function that takes unnamed values if you care about code verbosity in test cases. Or use `type M = MyStruct` to have an abbreviated type name within the test function. Rust is more on the verbose/explicit side and I agree that can sometimes be annoying…

>Dropping field names from definitions like Go would make the syntax inconsistent with destructuring and pattern matching

There's no reason you couldn't match on struct fields positionally as well. It would actually be quite convenient for cases like struct Point { x: f64, y: f64 }.

Re: Zig as an alternative to writing unsafe Rust

#147

Post by nindalf »

saurik wrote: post #59
rat9988 wrote: post #33

Earlier quoted context omitted.

This is the same as people behaving as jerks claiming that other people are jerks.

If you define "being a jerk" to include "calling out someone for being a jerk" then you will never be able to improve the situation.

They’re not just calling out though. They’re condescending with their “airquotes”, they’re stereotyping with their broad strokes.

It’s not useful criticism to simply say “this community was such-and-such”. I’d expect them to do better. Speak specifically to people saying something you disagree with. Don’t let it fester within you and then take it out on a broad group.

And I know you didn’t do any of this, but you did seem to be defending some pretty low quality behaviour.

Re: Zig as an alternative to writing unsafe Rust

#148

Post by bpolverini »

Asooka wrote: post #125
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…

One big difference between unsafe Rust and C is that C compilers have flags to turn off the UB, so you have a lot less mental load when writing it. You go from e.g. "if this index calculation overflows, we may read from outside the array, because the bounds check was deleted" to "if this index calculation overflows, we may read from the wrong index, but never outside of the array bounds". UB is Damocles's sword and t…

Very true and worth evangelizing to others. I have unknowingly violated -fstrict-aliasing in some part of my code only to discover later that it is benign at -O0 and metastasized at -O3.

This freaks me out the most in networking code, where there is all kinds of casting of structs (esp. if you blindly copy-paste examples from StackOverflow) and performance usually matters. Rust has inspired me to take more time to profile C code to see whether strict aliasing (strict overflow, etc.) actually make a significant enough improvement to merit the UB-risk, review time, and acid in the stomach.

Re: Zig as an alternative to writing unsafe Rust

#149

Post by malcolmstill »

dureuill wrote: post #144
malcolmstill wrote: post #142

Earlier quoted context omitted.

So usually you don't have to specify the error type. The Zig compiler works out what errors are returned from the function by looking at any errors returned directly or errors returned from other functions called within the body of the function. That set of errors forms an enum that is the actual error type, you just don't have to write that out explicitly. An example might be: fn someFunction(a: usize) !usize { if (…

Ah interesting approach, thx for the answer. 1. Doesn't that risk introducing accidental breaking changes by adding a new error to the set in the implementation, since the set of errors is inferred from the implementation? Having a compile error in this case in Rust is often the last barrier standing between me and an accidental major semver bump (since callers have to exhaustively match on the error conditions) 2. C…

> Doesn't that risk introducing accidental breaking changes by adding a new error to the set in the implementation, since the set of errors is inferred from the implementation?

Do you have an illustrative example? (I'm not implying it's not possible, just trying to think of a good example so I can give a good answer)

> since callers have to exhaustively match on the error conditions

If it's exhaustiveness that you're referring to, zig will make you handle all the possible errors (you can still do a catch all type thing when handling errors, which has the potential to "hide" an error that you otherwise wanted to handle explicitly).

> Can you have data in the variants of the error enumeration

No, they compile to just integers. Essentially it compiles to the same as C function that returns an `int` representing the error (with your actual return type passed in as a pointer, say).

Another limitation of zig error values is I think they're globally scoped, so you potentially could have two libraries have clashing error names that you then can't differentiate (I don't know if there are any plans to try and resolve that).

I will say that this automatic error set inference gives writing zig code this lovely "flow", where I do some error checks at the top of the function and early return some errors (which I just invent the names of there and then) and then move onto the happy path of the function, happy in the knowledge that the error handling is already "correct" (in that if the error isn't handled it'll (typically) bubble all the way up to main and exit the program). Any refinement on how a specific error is handled, I can go back to an appropriate place in the call stack and handle it. I always feel like it's helping me write correct code.

Re: Zig as an alternative to writing unsafe Rust

#150

Post by hitekker »

mustache_kimono wrote: post #26
ok123456 wrote: post #9

This pretty much mirrors my experience. Rust is the inverse of Perl: It makes the easy stuff hard. Writing basic data structures isn't a niche, esoteric edge case. There may be a crate that "solves" what you're trying to do. But does it rely on the std---(i.e., is it unusable for systems programming)? Is it implemented making gratuitous copies of data everywhere? Does it have a hideous interface which will then pollu…

> Rust is the inverse of Perl: It makes the easy stuff hard. It's a bargain. Rust is pretty great, but it doesn't make some things easy because it would make everything else hard. This comment is amusing, mostly because Perl is so full of tradeoffs. Do you want to write something to do some string parsing quickly? Great language, maybe. Do you want to understand what you've written later? Maybe not so great. > Writin…

[flagged]
Post reply on HN