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

131–140 of 230 posts

Re: Zig as an alternative to writing unsafe Rust

#131

Post by dureuill »

malcolmstill wrote: post #115
coderedart wrote: post #92

Earlier quoted context omitted.

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 :)

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?

Re: Zig as an alternative to writing unsafe Rust

#132

Post by steveklabnik »

guipsp wrote: post #69
woodruffw wrote: post #36

> Unsafe Rust is hard. A lot harder than C, this is because unsafe Rust has a lot of nuanced rules about undefined behaviour (UB) — thanks to the borrow checker — that make it easy to perniciously break things and introduce bugs. I don't think this is correct: Rust makes writing unsafe Rust correctly more onerous than writing C, but the actual rules for undefined behavior are the virtually same as in C: if you alias…

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.

C and Rust don't have more strict rules than each other; each has some things that the other disallows, and doesn't allow some things the other allows. It's not that simple.

Re: Zig as an alternative to writing unsafe Rust

#133

Post by steveklabnik »

sundarurfriend wrote: post #114

How significant is this to embedded development, eg. automotive software? I've been learning Rust on the side, and one of the main applications I have in mind is to get back into some embedded programming. I saw that there were libraries and even whole books about this [1], but I'm curious what the actual experience is like, and how much you have to wrangle raw pointers there. [1] https://docs.rust-embedded.org/book/

We do embedded work at Oxide. There's unsafe code, but not a ton of it. I haven't dug into this project's codebase at all, but the way it's described it sounds like there's way more than we use.

Re: Zig as an alternative to writing unsafe Rust

#134

Post by haberman »

pie_flavor wrote: post #50
DeathArrow wrote: post #45

Earlier quoted context omitted.

Writing data structures is trivial in C/C++.

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.

That would be true if Rust was a perfect language, but it isn't (no language is).

Sometimes Rust makes things hard because the invariants you want to express cannot be cleanly mapped onto Rust's type system. I described one such case here: https://blog.reverberate.org/2021/12/19/arenas-and-rust.html

Re: Zig as an alternative to writing unsafe Rust

#135

Post by indymike »

hn92726819 wrote: post #101
indymike wrote: post #93

Earlier quoted context omitted.

> 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 ;-)

Difference of course being that zero of these bugs will be due to buffer overflows or use after free or other memory bugs in safe rust, which is a huge source of bugs in C[1]. I don't understand why this argument keeps coming up. Not all bugs are the same and when you make entire classes of bugs unrepresentable, that's a massive win, especially when they happen to be the class containing >60% of the highest severity…

> I don't understand why this argument keeps coming up.

Not comment should be read as argument or part of a debate for or against using Rust or any other memory safe language. I made the comment because I've seen tool after tool come about to end the scourge of bugs in software... and so far my unconscious, untrained ability to find new and spectacular ways to create bugs has exceeded the ability of the makers of bug prevention tools to stop me.

Re: Zig as an alternative to writing unsafe Rust

#136

Post by kprotty »

hn92726819 wrote: post #101
indymike wrote: post #93

Earlier quoted context omitted.

> 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 ;-)

Difference of course being that zero of these bugs will be due to buffer overflows or use after free or other memory bugs in safe rust, which is a huge source of bugs in C[1]. I don't understand why this argument keeps coming up. Not all bugs are the same and when you make entire classes of bugs unrepresentable, that's a massive win, especially when they happen to be the class containing >60% of the highest severity…

> zero of these bugs will be due to buffer overflows or use after free or other memory bugs in safe rust

buffer overflows [0] [1], use after frees [2] [3], and other memory bugs [4] [5] [6] can appear in safe rust from unsound unsafe internals.

[0] https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2021-2887...

[1] https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2018-1000...

[2] https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2021-3116...

[3] https://github.com/rustsec/advisory-db/blob/main/crates/cros...

[4] https://github.com/rustsec/advisory-db/blob/main/crates/toki...

[5] https://github.com/rustsec/advisory-db/tree/main/crates/

[6] https://github.com/Qwaz/rust-cve

Re: Zig as an alternative to writing unsafe Rust

#137

Post by loeg »

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] makes the easy stuff hard.

I totally disagree with that claim. The easy thing to do is not use unsafe Rust. You can use stringly-typed datastructures with lots of refcounting or copying, just like Perl, without ever venturing into unsafe Rust.

> 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)?

In what world is Perl suitable for systems where possible memory allocation is a problem?

Re: Zig as an alternative to writing unsafe Rust

#138

Post by foldr »

guipsp wrote: post #73
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…

Do you mean the vec! macro?

It doesn't let you drop redundant struct tags, as far as I can tell.

Re: Zig as an alternative to writing unsafe Rust

#140

Post by foldr »

rom-antics wrote: post #77
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…

If you want compact, use an array of tuples: const foos = [("foo", 1, "bar"), ("foo", 1, "bar"), ...]; for (str1, num, str2) in &foos { // ... } For a proper struct you have to name the fields, because otherwise refactoring the fields could cause struct instances to silently get out of sync with the definition.

>otherwise refactoring the fields could cause struct instances to silently get out of sync with the definition.

Having to name the fields is only part of the pain. You also have to redundantly repeat the struct name. I don't see any fundamental reason why something like this shouldn't be valid:

    let foo: [MyStruct; _] = [{a: "foo", b: 1, c: "amp"}, {a: "bar", b: 1, c: "fff"}, {a: "amp", b: 1, c: "aaa"} ];
I can see the logic for insisting on field names. However, the builtin 'go vet' tool has a nice behavior where it will flag the use of unkeyed literals for public structs only. This strikes me as a good compromise between concision and safety.
Post reply on HN