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

101–110 of 230 posts

Re: Zig as an alternative to writing unsafe Rust

#101

Post by hn92726819 »

indymike wrote: post #93
DonaldPShimoda wrote: post #58

Earlier quoted context omitted.

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

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 bugs in C.

https://www.chromium.org/Home/chromium-security/memory-safet...

Re: Zig as an alternative to writing unsafe Rust

#102

Post by Rusky »

dimitrios1 wrote: post #55
ok123456 wrote: post #42

Earlier quoted context omitted.

The core language is fine, but when you actually start building things you need to introduce lifetimes, all the traits that you polluted your interface with and then add on async, it gets out-of-hand quickly.

The top comment gave a perfect example: #![feature(strict_provenance)] These feature enablement blocks drive me crazy. You could go from codebase to codebase and it's almost like you are working in a different language depending on how many of these are enabled or not. I've been trying rust on and off since it's release, and I still have yet to feel like I have a grasp on some "core" subset of the language I can fall…

A spec is not a replacement for #![feature] attributes. It's rather the opposite: #![feature] indicates that you are stepping out of the stable, specified core language and into an area that is still a work in progress and thus cannot have a committed specification yet. You shouldn't need it at all unless you are actively experimenting with some unfinished proposal.

Re: Zig as an alternative to writing unsafe Rust

#103

Post by flohofwoe »

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…

Typescript and Zig are two other languages that look vaguely C-like (even though they are on two opposite ends of "C like"), but both are a whole lot easier on the eyes than most Rust code.

C++ on the other hand also is vaguely C like, but can look equally messy as typical Rust code.

OTH I find Makepad's Rust style very readable, but I can't quite put my finger on it what's different from other Rust code bases:

https://github.com/makepad/makepad

Re: Zig as an alternative to writing unsafe Rust

#104

Post by brundolf »

likeabbas wrote: post #22
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. There’s a macro for doing this with Assembly, I can imagine one could be made for C. But why wouldn’t you just write unsafe rust at that point?

Colocation, and avoiding the ceremony of standing up all the extern types (and integrating a separate C compiler, etc)

Re: Zig as an alternative to writing unsafe Rust

#105

Post by infamouscow »

ksec wrote: post #12

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

[flagged]

Re: Zig as an alternative to writing unsafe Rust

#106

Post by brundolf »

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…

This is not correct. Here's a really good video that goes into the differences: https://youtu.be/DG-VLezRkYQ

Re: Zig as an alternative to writing unsafe Rust

#107

Post by woodruffw »

anon4242 wrote: post #94
woodruffw wrote: post #79

Earlier quoted context omitted.

> 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

Yes: the implication was that the original object was `const`. If you both add and remove const, that's well-defined.

(I've yet to see a C or C++ codebase where object provenance actually guarantees this; I've see a lot of C and C++ codebases with const-stripping induced UB.)

Re: Zig as an alternative to writing unsafe Rust

#108

Post by alpaca128 »

foldr wrote: post #66
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

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, but as autocompletion exists I can live with it.

Re: Zig as an alternative to writing unsafe Rust

#109

Post by no_wizard »

foldr wrote: post #66
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

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…

you'll have to forgive me, but isn't this why there should be a `::new()` callable attached to the struct?

I'm really new at Rust, but that was my takeaway, e.g. `String` has `String::new()`

Re: Zig as an alternative to writing unsafe Rust

#110

Post by stouset »

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.

Okay but who is writing code like this instead of using `use`?

Also this is an no-win situation. C++, Ruby, Perl, and others have used `::` as module-scoping syntax for decades. If Rust does something novel, it's penalized for being unfamiliar. If Rust uses syntax for which there's ample prior art, it's apparently line noise. If rust used a `.` as a separator, it's unclear if you're descending into modules or calling a function chain.

There's literally no way to win.

Post reply on HN