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

181–190 of 230 posts

Re: Zig as an alternative to writing unsafe Rust

#181

Post by jeffdn »

munificent wrote: post #99
estebank wrote: post #53

Earlier quoted context omitted.

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.

From a book that was a real joy to read and take one’s first steps into the magical world of compilers —- thank you for writing it!

Re: Zig as an alternative to writing unsafe Rust

#182

Post by nindalf »

kprotty wrote: post #136
hn92726819 wrote: post #101

Earlier quoted context omitted.

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

Rust has a low bar for creating CVEs, because the standards for safety are higher.

From the link you’re sharing

> Fortunately, they are context-sensitive library APIs that are not usually used in a way that the bugs can be triggered. Many of them require very specific interaction to trigger (e.g., partially consume an iterator and zip() it with another iterator) that is not likely to appear in their daily usage.

Here’s a concrete example that shows the difference between how different languages approach CVEs. Rust is not the only language affected by this TOCTOU bug (https://blog.rust-lang.org/2022/01/20/cve-2022-21658.html) but other languages finesse it by saying “all bets are off when you’re interacting with the filesystem”. Therefore no CVE for them, while Rust ends up looking insecure in the eyes of those who count CVEs.

What I’m saying is - don’t count CVEs without looking at the context and content of those CVEs. Don’t assume that some software is secure simply because they don’t file CVEs, because that’s an ostrich approach.

Re: Zig as an alternative to writing unsafe Rust

#183

Post by jononor »

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…

Which compiler flags do I use to turn off UB?

Re: Zig as an alternative to writing unsafe Rust

#184

Post by wg0 »

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…

Are all the UBs defined/documented/catalogued somewhere?

Re: Zig as an alternative to writing unsafe Rust

#185

Post by GrumpySloth »

TheCoreh wrote: post #47
adamrezich wrote: post #40

Earlier quoted context omitted.

why should writing a basic data structure be an edge case? …what?

All of the "basic" data structures are already provided by either the standard library or crate ecosystem, so you'll rarely (if ever) need to write your own linked list or hash map from scratch. I say "basic" in quotes because once you factor in the concurrency, ownership and memory safety concerns that are optional in other languages, but mandatory in Rust, there really isn't a simple implementation of these structu…

Rust is supposed to be a systems programming language. If writing basic data structures was an edge case in it, the language would be broken. Luckily, in my experience it isn’t (at least not in this way).

Re: Zig as an alternative to writing unsafe Rust

#186

Post by scoutt »

kaba0 wrote: post #112
hgs3 wrote: post #70

Earlier quoted context omitted.

> It seems to consist solely of extremely online people who get a dopamine hit from both telling people they're doing things wrong and creating the most complex solutions possible. I've observed that certain programming languages have a culture of complexity. I'm not sure why this is. I can only speculate its because these programmers are working on "boring" problems so they make busy work for themselves OR their beg…

I don’t know, people who go too hard on simplicity often don’t even grasp the underlying problem in a given case (looking at this utterly dumb piece of text as an example: http://harmful.cat-v.org/software/ ) - sure, no sane people would want to deliberately introduce complexity/abstractions, but abstraction is the only weapon we have against complexity. Problems have an inherent complexity which simply cannot ever b…

Complex problems and complex solutions are two different things. The genius is in solving complex problems with simple solutions. While it might seem that adding a crate to solve a problem is a simple thing, from the system programmer point of view (mine), it is not.

Re: Zig as an alternative to writing unsafe Rust

#187

Post by pjmlp »

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…

Some flags to turn off some UB, and not all of them have those flags.

Re: Zig as an alternative to writing unsafe Rust

#188

Post by pjmlp »

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…

There is already C for when one wants to do otherwise.

Re: Zig as an alternative to writing unsafe Rust

#189

Post by pjmlp »

spoiler wrote: post #89
mustache_kimono wrote: post #57

Earlier quoted context omitted.

> Still, we, the Rust community, should take the high road and respond to the criticism by assuming that it's valid and asking what we can do better. I have to disagree. I think this meme/issue has been talked to death. And I'm sure I find retrograde, sour-pussing about Rust just as distasteful as others find dewy Rust optimism. The answer is -- they're both silly. Draw the line at speaking about the tech or the comm…

But also, where is this malevolent, toxic Rust community that disgruntled C++ developers always engage with? I've yet to encounter a single person from this unstoppable force of sanctimonious assholes ruining everyone's fun on non-Rust projects. By their accounts Rust is a mental health catastrophe for our industry. Anyway, shit posting aside. I do agree with them that the Rust community is a bit eager to suggest rew…

As polyglot dev, with love/hate relationship with almost any language worth using, until Rust gets free of "my compiler compiles yours", there is always an attack vector from those devs.

It was like this during the Usenet flamewars on C vs C++, and while I rejoice most C compilers now being written in C++, there are a few domains where C++ failed to take over C.

Rust advocacy strike force would do better to learn from history of programming languages adoption.

Re: Zig as an alternative to writing unsafe Rust

#190

Post by lerno »

This claim just killed me: "Apart from [Zig] not having crazy UB like in unsafe Rust". Zig has more UB than even C. Yes, Zig has safety checks you can turn on, but then it's not fast anymore. The claim saying Zig has no UB is like saying C has no UB because you can run it with UB-sanitizers.

Don't get me wrong, it's great to have this directly enabled in "safe" mode like Zig does it. But to use that to say Zig is more safe is extremely misleading.

Post reply on HN