Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Zig feels more practical than Rust for real-world CLI tools

dayvster.com

Post reply on HN
Print view View original

311–320 of 412 posts

Re: Zig feels more practical than Rust for real-world CLI tools

#311

Post by simonask »

clevor wrote: post #305
AlotOfReading wrote: post #212

Earlier quoted context omitted.

The thing I wish we would remember, as developers, is that not all programs need to be so "safe". "Safety" is just a shorthand for "my program means what I say". Unsafety is semantic gibberish. There's lots of reasons to write artistically gibberish code, just as there is with natural language (e.g. Lewis Carroll). Most programs aren't going for code as art though. They're trying to accomplish something definite thro…

If you want or need the guarantees Rust provides, then go ahead and use Rust. If you want to handle the guarantees yourself, then Rust may not be the language for you. You can still have bugs whether or not you use Rust, so your Rust program may have some form of unsafety. In Linux, a Rust program with setuid root can lead to privilege escalation vulnerabilities, even if it doesn't contain a single line of "unsafe" c…

I think you have both misread the comment you replied to and misunderstood the concept of memory safety.

Re: Zig feels more practical than Rust for real-world CLI tools

#312

Post by aw1621107 »

dayvster wrote: post #255
mattwilsonn888 wrote: post #104

Earlier quoted context omitted.

As long as the audience accepts the framing that ergonomics doesn't matter because it can't be quantified, the hand-waving exemplified above will confound. "This chair is guaranteed not to collapse out from under you. It might be a little less comfortable and a little heavier, but most athletic people get used to that and don't even notice!" Let's quote the article: > I’d say as it currently stands Rust has poor deve…

> The Rust community should be upfront about this tradeoff - it's a universal tradeoff, that is: Safety is less ergonomic. It's true when you ride a skateboard with a helmet on, it's true when you program, it's true for sex. Well put! And this should not be contentious issue, it simply is annoying to deal with Rust's very strict compiler. It's not a matter of opinion it simply is more annoying than if you were to use…

> if someone has gotten access to your system where they can run `coreutil` commands you probably have bigger problems than them running a couple of commands that leak.

Speaking more abstractly since I haven't looked at the CVEs in question, but an attacker directly accessing coreutils on your system isn't the only possible attack vector. Another potentially interesting one would be them expecting you to run coreutils on something under they control. For example, a hypothetical exploit in grep might be exploitable by getting you to grep through a repo with a malicious file.

A more concrete example would be some of the various zero-click iMessage exploits, where the vulnerable software isn't exploited via the attackers directly accessing the victim's device but is exploited by sending a malicious file.

Re: Zig feels more practical than Rust for real-world CLI tools

#313

Post by quotemstr »

lerno wrote: post #307
quotemstr wrote: post #215

Earlier quoted context omitted.

> The words of every C programmer who created a CVE. Much of Zig's user base seems to be people new to systems programming. Coming from a managed code background, writing native code feels like being a powerful wizard casting fireball everywhere. After you write a few unsafe programs without anything going obviously wrong, you feel invincible. You start to think the people crowing about memory safety are doing it bec…

I can't speak for Zig users, but an interesting alternative to just new/delete or malloc/free and various garbage collection strategies is pervasive use of temp allocation using arenas, such as Jai and Odin's temp allocators (essentially frame allocators) and C3's stack-like temp allocator. Zig also favours using arenas, but more ad hoc. What happens in those cases is that you drop a whole lot of disorganized dynamic…

If arena allocators were a panacea, Subversion and Apache would be safer than your typical C program, yes?

Re: Zig feels more practical than Rust for real-world CLI tools

#314

Post by crote »

wolvesechoes wrote: post #247
anon-3988 wrote: post #112

Earlier quoted context omitted.

I would argue that good C or C++ code is actually just Rust code with extra steps. So in this sense, Rust gets you to the "desired result" much easier compared to using C or C++ because no one is there to enforce anything and make you do it. You can argue that using C or C++ can get you to 80% of the way but most people don't actively think "okay, how do I REALLY mess up this program?" and fix all the various invaria…

There are valid and safe programs rejected by Rust compiler if you don't go through rituals required to please it (slaping Rc, Refcells etc). No amount of "oh your Rust code is actually something you would ended up with if you would choose C" will change that.

Of course. After all, it is mathematically impossible to prove the correctness of all valid and safe programs - the halting problem clearly shows that. The real question should not be "Are there valid and safe programs Rust will reject?" but "How common is it that your well-written valid and safe program will be rejected by the Rust compiler?".

In practice the vast majority will be accepted, and what remains is stuff the Rust compiler cannot prove to be correct. If Rust doesn't like your code, there are two solutions. The first is to go through the rituals to rewrite it as provably-safe code - which can indeed feel a bit tedious if your code was designed using principles which don't map well to Rust. The second is to use `unsafe` blocks - but that means proving its safety is up to the programmer. But as we've historically seen with C and unsafe-heavy Rust code bases, programmers are horrible at proving safety, so your mileage may vary.

I don't want to be the "you're holding it wrong" person, but "Rust rejected my valid and safe program" more often than not means "there's a subtle bug in my program I am not aware of yet". The Rust borrow checker has matured a lot since its initial release, and it doesn't have any trouble handling the low-hanging fruit anymore. What's left is mainly complex and hard-to-reason-about stuff, and that's exactly the kind of code humans struggle with as well.

Re: Zig feels more practical than Rust for real-world CLI tools

#315

Post by pron »

johncolanduoni wrote: post #262
pron wrote: post #196

Earlier quoted context omitted.

> Unfortunately there are too many non-believers for systems programming languages with automatic resource management to take off as they should. Or those languages had other (possibly unrelated) problems that made them less attractive. I think that in a high-economic-value, competitive activity such as software, it is tenuous to claim that something delivers a significant positive gain and at the same time that that…

I’m not willing to go to bat for Oberon, but large swaths of software engineering are done with no tradeoff analysis of different technologies at all. Most engineers know one imperative programming language and maybe some SQL. If you ask them what to use, they will simply wax poetic about how the one language they know is the perfect fit for the use-case. Even for teams further toward the right of the bell curve, his…

If a language offered a significant competitive advantage, such an analysis wouldn't be necessary. Someone would capitalise on it, and others would follow. There are selective pressures in software. Contingencies play an outsized role only when the intrinsics don't.

Re: Zig feels more practical than Rust for real-world CLI tools

#316

Post by mattwilsonn888 »

shakow wrote: post #279
mattwilsonn888 wrote: post #270

Earlier quoted context omitted.

This is incredibly misleading (technically true maybe) and you know it. Rust has slower compile times for the sake of safety, it's a tradeoff you shouldn't be ashamed of. I didn't narrowly claim the borrow checker (as opposed to the type system or other static analysis) was the sole focus of the tradeoff.

> Rust has slower compile times That's true. > for the sake of safety, That's false though. All deep dives in the topic find that the core issue is the sheer amount of unoptimized IR that is thrown at LLVM, especially due to the pervasive monomorphization of everything.

Well it is arguably Rust's worst issue and it has remained it for most of its life.

Are you really going to try and convince people that this is completely incidental and not a result of pursuing its robust static contracts? How pedantic should we about about it?

Re: Zig feels more practical than Rust for real-world CLI tools

#317

Post by johncolanduoni »

pron wrote: post #292
johncolanduoni wrote: post #258

Earlier quoted context omitted.

I buy that Zig would fit the risk/reward envelope for some projects. My only issue was with using a breakdown of amalgamated CVEs where most of the software would never actually be written in Zig or Rust regardless to demonstrate that. Perhaps that misunderstanding about my claims is most of the source of our disagreement. To your point about V8 and CPython: that calculus makes sense if I’m Microsoft and I could spen…

> If my day job is to reduce vulnerabilities in V8 itself, those would be totally out of scope and everybody would look at my like I’m crazy if I brought it up in a meeting. Maybe (and I'll return to that later), but even if the job were to specifically reduce vulnerabilities in V8, it may not be the case that focusing on UAF is the best way to go, and even if it were, it doesn't mean that eliminating UAF altogether…

> BTW, this scenario isn't so hypothetical for me, as I work on the Java platform, and I very much prefer spending my time on trying to reduce injection vulnerabilities in Java than on chasing down memory-safety-related vulnerabilities in HotSpot (because there's more security value to our users in the former than in the latter).

That's a good example and I agree with you there. I think the difference with V8 though is twofold:

1. Nobody runs fully untrusted code on HotSpot today and expects it to stop anybody from doing anything. For browser JavaScript engines, of course the expectation is that the engine (and the browser built on it) are highly resistant to software sandbox escapes. A HotSpot RCE that requires a code construction nobody would actually write is usually unexploitable - if you can control the code the JVM runs, you already own the process. A JavaScript sandbox escape is in most cases a valuable part of an exploit chain for the browser.

2. Even with Google's leverage on the JS and web standardization processes, they have very limited ability to ship user-visible security features and get them adopted. Trusted Types, which could take a big chunk out of very common XSS vulnerabilities and wasn't really controversial, was implemented in Safari 5 years after Chrome shipped it. Firefox still doesn't support it. Let's be super optimistic and say that after another 5 years it'll be as common as CSP is today - that's ten years to provide a broad security benefit.

These are of course special aspects of V8's security environment, but having a mountain of memory safe code you can tweak on top of your unsafe code like the JVM has is also unusual. The main reason I'd be unlikely to reach for Zig + temporal pointer auth on something I work on is that I don't write a lot of programs that can't be done in a normie GC-based memory safe programming language, but for which having to debug UAF and data race bugs (even if they crash cleanly!) is a suitable tradeoff for the Rust -> Zig drop in language complexity.

Re: Zig feels more practical than Rust for real-world CLI tools

#318

Post by mattwilsonn888 »

aw1621107 wrote: post #310
mattwilsonn888 wrote: post #272

Earlier quoted context omitted.

*Under the assumption that you are maximizing both. I often hear complaints that Rust's semantics actually haven't maximized ergonomics, even factoring in the added difficulty it faces in pursuit of safety. It's totally possible languages as ergonomic as Rust can be more safe, just because Rust isn't perfect or even has some notable, partially subjective, design flaws.

> Under the assumption that you are maximizing both. I'm not sure that changes anything about my comment? GC'd languages can give you safety and* ergonomics, no need to trade off one for the other. Obviously doing so requires tradeoffs of their own, but such additional criteria were not mentioned in the comment I originally replied to. > I often hear complaints that Rust's semantics actually haven't maximized ergonom…

Your earlier point that languages exist that are safer than Rust but not less ergonomic is irrelevant - that's the point I made.

One can fail, or artificially make a language less ergonomic and that doesn't mean that fixing that somehow has an effect on the safety tradeoff.

So obviously it is when safety and ergonomics are each already maximized that pushing one or the other results in a tradeoff. It's like saying removing weight from a car isn't a tradeoff because the weight was bricks in the trunk.

Anyways I was holding performance constant in all of this because the underlying assumption of Rust and Zig and Odin and C is that performance will make no sacrifices.

Re: Zig feels more practical than Rust for real-world CLI tools

#319

Post by mattwilsonn888 »

charcircuit wrote: post #259
mattwilsonn888 wrote: post #104

Earlier quoted context omitted.

As long as the audience accepts the framing that ergonomics doesn't matter because it can't be quantified, the hand-waving exemplified above will confound. "This chair is guaranteed not to collapse out from under you. It might be a little less comfortable and a little heavier, but most athletic people get used to that and don't even notice!" Let's quote the article: > I’d say as it currently stands Rust has poor deve…

>Safety is less ergonomic. It's not safety that makes it less ergonomic, it's correctness.

Implying that correctness necessitates a lack of ergonomics is deeply flawed.

The distinction between correctness and safety is that safety is willing to suffer false positives, in pursuit of correctness. Correctness is just correctness.

Re: Zig feels more practical than Rust for real-world CLI tools

#320

Post by mattwilsonn888 »

timeon wrote: post #246
mattwilsonn888 wrote: post #104

Earlier quoted context omitted.

As long as the audience accepts the framing that ergonomics doesn't matter because it can't be quantified, the hand-waving exemplified above will confound. "This chair is guaranteed not to collapse out from under you. It might be a little less comfortable and a little heavier, but most athletic people get used to that and don't even notice!" Let's quote the article: > I’d say as it currently stands Rust has poor deve…

How are chairs related to programming languages? Analogies are just made-up arguments.

Because a primary function of the chair is the same to programming languages: ergonomics.

That is obviously true, otherwise we'd code in assembly and type in UTF-8 byte codes.

Post reply on HN