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

281–290 of 412 posts

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

#281

Post by blacksmith_tb »

dadrian wrote: post #250
vanderZwan wrote: post #232

Earlier quoted context omitted.

Wasn't Bun the project where the creator once tweeted something along the lines of "if you're not willing to work 50+ hours a week don't bother applying to my team" ? Because if so then I'm not surprised and also don't think Zig is really to blame for that.

Not clear to me there's a correlation between hours worked and number of memory safety vulnerabilities

I think the implication is something like "overwork / fraying morale from long hours means shipping more bugs".

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

#282

Post by shakow »

quotemstr wrote: post #218
SkiFire13 wrote: post #194

Earlier quoted context omitted.

The tradeoff is between performance, safety and ergonomics. With GC languages you lose the first one.

> The tradeoff is between performance, safety and ergonomics. With GC languages you lose the first one. That's a myth that just won't die. How is it that people simultaneously believe 1) GC makes a language slow, and 2) Go is fast? Go's also isn't the only safe GC. There are plenty of good options out there. You are unlikely to encounter a performance issue using one of these languages that you could resolve only wit…

Go is not fast though.

It's plenty fast compared to commonly used languages such as JS, PHP or Python, but can easily be let in the dust by Java and C#, which arguably play in the same court.

And AOT-compiled, no GC languages like C++, Rust or Zig just run circles around it.

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

#283

Post by scoopdewoop »

AlotOfReading wrote: post #278
scoopdewoop wrote: post #260

Earlier quoted context omitted.

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

I understood and considered both things you could have meant. Either way I think you come off as an armchair coder that overstates what rust safety actually is (its not abstract, i enumerated it). You are doing rust a disservice in the most stereotypical way. I have no more time for this, going to go play one of hundred of thousands of gibberish games.

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

#284

Post by AlotOfReading »

discreteevent wrote: post #271
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…

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.

I'm not making either of those arguments. I'm not even using IOCCC as a pejorative association. The comment you're responding to explicitly compares IOCCC code to poetry and Lewis Carroll. One thing I am saying is that most code isn't written for those kinds of purposes. I can't imagine that's a controversial statement though.

I'm open to suggestions on how to clarify things as you're the second comment to misunderstand it and I'm not sure how to better explain it.

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

#285

Post by ksec »

dayvster wrote: post #276
zanellato19 wrote: post #265

Earlier quoted context omitted.

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

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

Interesting the way this was perceived. I thought he was just asking a honest question.

Again shows online discussion and communication is hard.

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

#286

Post by shakow »

mattwilsonn888 wrote: post #137
SoraNoTenshi wrote: post #125

Earlier quoted context omitted.

It also drives me insane when i dump the problems i have with Rust about this exact issue, that i usually have to restructure my code to satisfy the compilers needs, and they come at me with the "Skill Issue" club... I honestly don't even know what to respond to that, but it's kind of weird to me to honestly think that you'd need essentially a "PhD" in order to use a tool...

It's an amazing piece of marketing to corner anyone who dislikes a certain hassle as being mentally deficient - that's what "skill issue" means in this context.

> that's what "skill issue" means in this context.

“Skill issue” definitely does not means “mentally deficient”. It comes from the videogames world, where it is used to disparage the lack of training/natural ability of other players; frequently accompanied by “get good”, i.e. continue training & grinding to up your skill.

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

#287

Post by zanellato19 »

dayvster wrote: post #276
zanellato19 wrote: post #265

Earlier quoted context omitted.

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

I think pretty much any non trivial C example has memory safety issues. It doesn't mean that they aren't useful and can't be used. But time and time again we have seen security reports that point to memory issues. So no, I don't think I'm asking for something obvious, quite the contrary. I think the claim that it's possible to write big C programs that are memory safe is really strong and I heavily disagree with it.

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

#288

Post by mattwilsonn888 »

K0nserv wrote: post #174

I mostly don't agree with this take. A couple of my quibbles: "Cognitive overhead: You’re constantly thinking about lifetimes, ownership, and borrow scopes, even for simple tasks. A small CLI like my notes tool suddenly feels like juggling hot potatoes." None of this goes away if you are using C or Zig, you just get less help from the compiler. "Developers are not idiots" Even intelligent people will make mistakes be…

To contradict you: avoiding false positives (programmer is correct, compilation fails anyways) by refactoring code into the second or third best design, is exactly the type of cognitive overhead that deserves to be vindicated when complained about. It can fundamentally changes the design of the entire codebase.

I believe that explains why many game developers, who have a very complex job to do by default, usually see the Rust tradeoff as not worth it. Less optionality in system design compounds the difficulty of an already difficult task.

If The Rust Compiler never produced false positives it should in theory be (ignoring syntactic/semantic flaws) damn-near as ergonomic as anything. Much, much easier said than done.

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

#289

Post by ksec »

mattwilsonn888 wrote: post #273
thinkharderdev wrote: post #203

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

Thank You that makes a lot of sense. I guess we will have to wait for Zig to become 1.0 first and then do a proper comparison.

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

#290

Post by rstuart4133 »

mattwilsonn888 wrote: post #104
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…

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.

That can be true for small programs. Not always, because Rust's type system makes for programs that can be every bit as compact as Python if the algorithm doesn't interact badly with the borrow checker. Or even if it does. For example this tutorial converts a fairly nary C program to Rust: https://cliffle.com/p/dangerust/ The C was 234 lines, the finished memory safe Rust 198 lines.

But when it comes to large programs, the ergonomics strangely tips into reverse. By "strangely tips into reverse", I mean yes it takes more tokens and thinking to produce a working Rust program, but overall it saves time. Here a "large program" means a programmer can't fit it all in his head at one time. I think Andrew Huang summed the effect up best, when he said if you start pulling on a thread in a Rust program, you always get to the end. In other languages, you often just make the knot tighter.

Post reply on HN