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

271–280 of 412 posts

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

#271

Post by discreteevent »

AlotOfReading wrote: post #212
scoopdewoop wrote: post #51

This is a really bad take, on par with the "we don't need types" post from last week. The thing I wish we would remember, as developers, is that not all programs need to be so "safe". They really, truly don't. We all grew up loving lots of unsafe software. Star Fox 64, MS Paint, FruityLoops... the sad truth is that developers are so job-pilled and have pager-trauma, so they don't even remember why they got in the gam…

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…

You are not doing Rust any favours by arguing that code that may have memory safety issues is gibberish and something that could be associated with the IOCCC. Ramping something up to 11 makes it hard to take seriously.

You could write rust code with logic errors. I could write C with a memory leak that doesn't matter because of the context it runs in. Neither program is gibberish but one of them causes real problems.

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

#272

Post by mattwilsonn888 »

aw1621107 wrote: post #156
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…

> it's a universal tradeoff, that is: Safety is less ergonomic. I'm not sure that that tradeoff is quite so universal. GC'd languages (or even GC'd implementations like Fil-C) are equally or even more memory-safe than Rust but aren't necessarily any less ergonomic. If anything, it's not an uncommon position that GC'd languages are more ergonomic since they don't forbid some useful patterns that are difficult or impos…

*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.

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

#273

Post by mattwilsonn888 »

thinkharderdev wrote: post #203
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…

> 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. I interpreted the parent to be saying that ergonomics IS (at least partly) subjective. The subjective aspect is "what you are used to". And once you get used to Rust its ergonomics are fine, something I agree with having used Rust for a few years now. > The Rust…

I think you are clearly good-faith.

The issue is the underlying and unfair assumption that is so common in these debates: that the memory-unsafe language we're comparing against Rust is always C/C++, rather than a modern approach like Zig or Odin (which will share many arguments against C/C++).

You can prove to yourself this happens by looking around this thread! The topic is Zig vs. Rust and just look at how many pro-Rust arguments mention C (including yours).

It's a strong argument if we pose C as the opponent, because C can be so un-ergonomic that even Rust with its added constraints competes on that aspect. But compare it to something like Zig or Odin (which has ergonomic and safety features like passing allocators to any and all functions, bounds checking by default, sane slice semantics which preclude the need for pointer arithmetic) and the ergonomics/safety argument isn't so simple.

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

#274

Post by NielsAndersen67 »

I have been writing Rust code for 3.5 years. I never fight the borrow checker. The ownership rules are a blessing, when ever the compiler yells at me, then I know I am doing something that would have caused a seg fault i. C. It took a little while to get used to Rusts syntax, but once I got it, it was the best programming language I have ever used. It is just so beautiful how it enables multi threading and ensures that all errors are handled.

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

#275

Post by dayvster »

hannofcart wrote: post #264
dayvster wrote: post #257

Earlier quoted context omitted.

[flagged]

Haven't written C in a while but I think this program has an integer overflow error when you input 2 really large integers such that the sum is more than a 32 bit signed integer. Also I believe in entering null values will lead to undefined behaviour.

har har... have my upvote!

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

#276

Post by dayvster »

zanellato19 wrote: post #265
dayvster wrote: post #257

Earlier quoted context omitted.

[flagged]

I wasn't trying to be a dick, I am saying that my experience is that no big C program is ever safe. You replied that it is possible and I asked for an example. Providing a small script to prove that big C programs are safe isn't enough.

Making a broad statement like there has never been a memory safe C program is a bit of a dickish thing to say.

especially when you phrase it as

> Can you provide examples for it? Because it honestly doesn't seem like it has ever been done.

it comes off as pedantic and arrogant.

It obviously is possible to write memory safe software in C and obviously it has been done before otherwise we would not be currently communicating over the goddamn internet.

Asking for evidence of something this obvious is akin to asking for a source on if water is in fact wet.

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

#277

Post by massung »

> Seasoned Rust coders don’t spend time fighting the borrow checker...

Experienced Rust coders aren't going to find themselves in various borrow checker (and lifetime) pitfalls that newbies do, sure.

That said, the borrow checker and lifetime do cause problems for even experienced Rust programmers. Not because they don't understand memory management, lifetimes, etc. But because they don't - yet - fully understand the problem being solved.

All programs are an evolutionary process of developing a solution to a problem (or many problems). You think one thing, code it up, realize you missed something or didn't fully grok the issue, pivot, etc.

Rust does a great job in the compiler of letting the user know if they've borked something. But often times a refactor/fix in C/D/Zig due to learned (or new) requirements is just a tweak, while in Rust it becomes a major overhaul because now something needs to be `mut` or have a lifetime added to it. I - personally - consider that "fighting" the borrow checker, regardless of how helpful (or correct) it also is.

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

#278

Post by AlotOfReading »

scoopdewoop wrote: post #260
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 we could wave a magic wand and make all code safe with no downsides, who among us wouldn't? Anybody would, but Rust is not that wand, and there is no wand. Code needs to _exist_ in order to matter. Time is finite, my free-time is even more limited. Most of my code is garbage collected, and runs great, but if I needed it to be really fast, I would use Zig. I don't need to be told what software is for or how to ac…

I want to be clear here because I think you might have read that as less precisely worded than I intended.

When I say "my program means what I say", that means the code that is written has some precise meaning that can be faithfully translated into execution (sans hardware/runtime/toolchain bugs).

This is different than "I said what I mean". If you write different code, that may violate expectations and create a bug, but it will still be faithfully translated as written.

Safe Rust attempts to guarantee this with the absence of UB. The definition rust uses still isn't a universal definition, which we agree on. That's why my comment didn't actually talk about Rust. The definition I used should be valid no matter what particular guarantees you choose.

    Things being manually managed doesn't make them gibberish, and something being implicit, rather than explicit, doesn't mean its gibberish.
I completely agree. I like C, for what it's worth.

Where we disagree is that I'm saying this doesn't scale. A large enough program (for a surprisingly small definition of large) will always have gaps and mistakes that violate your chosen definition of safety, and those bits are the gibberish I'm talking about.

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

#279

Post by shakow »

mattwilsonn888 wrote: post #270
steveklabnik wrote: post #199

Earlier quoted context omitted.

The borrow checker is never a significant portion of compile times.

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.

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

#280

Post by mattwilsonn888 »

ajross wrote: post #195
simonask wrote: post #21

The benefit of Zig seems to be that it allows you to keep thinking like a C programmer. That may be great, but to a certain extent it’s also just a question of habit. Seasoned Rust coders don’t spend time fighting the borrow checker - their code is already written in a way that just works. Once you’ve been using Rust for a while, you don’t have to “restructure” your code to please the borrow checker, because you’ve a…

> Seasoned Rust coders don’t spend time fighting the borrow checker - their code is already written in a way that just works. That hasn't been my experience at all. At best, the first version of code pops out quickly and cleanly because the author knows the appropriate idiom to choose. Refactoring rust code to handle changes in that allocation idiom is extremely expensive, even for the most seasoned developers. Case…

I would be interested to read the debates that stems from this point.
Post reply on HN