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

241–250 of 412 posts

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

#241

Post by Imustaskforhelp »

pjmlp wrote: post #168
Imustaskforhelp wrote: post #7

What are your thoughts on nim, odin and v-lang, D-lang? I feel like I am most interested about nim given how easy it was to pick up and how interoperable it is with C and it has a garbage collector and can change it which seems to be great for someone like me who doesn't want to worry about manual memory management right now but maybe if it becomes a bottleneck later, I can atleast fix it without worrying too much..

From those only Nim and D are interesting. We don't need yet another language with manual memory management in the 21st century, and V doesn't look that would ever be that relevant.

V is also similar to nim tho.

V is also similar to golang in syntax, something that I definitely admire tbh.

I am interested about nim and V more tbh as compared to D-lang

In fact I was going to omit D-lang from my comment but I know that those folks are up to something great too and I will try to look into them more but nim defintely peaks my interests as a production ready language-ish imo as compared to V-lang or even D-lang

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

#242

Post by daft_pink »

I think the underlying question is why move to Zig from a C variant?

There is a lot of research showing that a high percentage of security bugs are from memory safety issues across many different studies. I believe this is why people are pushing moving to Rust.

However, if you don’t get the memory safety in Zig. Why bother moving from your existing coding language? Why not just not learn a new language and code where you are?

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

#243

Post by pron »

johncolanduoni wrote: post #220
pron wrote: post #151

Earlier quoted context omitted.

First, UAF can be made largely non-dangerous without eliminating it (as in the link above and others). It's harder to exploit to begin with, and can be made much harder still virtually for free. So the number of UAFs and the number of exploitable vulnerabilities due to UAF are not the same, and have to be treated as separate things (because they can be handled separately). Second, I don't care if my bank card details…

> I don't care if my bank card details leak because of CSRF or because of a bug in Chromium Sure, but just by virtue of what these languages are used for, almost all CSRF vulnerabilities are not in code written in C, C++, Rust, or Zig. So if I’m targeting that space, why would I care that some Django app or whatever has a CSRF when analyzing what vulnerabilities are important to prevent for my potential Zig project?…

To your first point, you're sort-of right, but it's still not so simple. The value of vulnerabilities in V8 or in CPython is affected by their likelihood compared to other vulnerabilities to users using that same product (i.e. in JS or Python code). If I want to know how much I should pay for a screw in some machine, the answer isn't "whatever it costs to minimise the chance of the screw failing regardless of other components". Once the chance of a fault in the screw is significantly lower than the chance of the machine failing for other reasons, there's no much point in getting a more resilient screw, as it would have little to no effect on the resilience of the machine.

The rate of vulnerabilities obviously can't be zero, but it also doesn't need to be. It needs to be low enough for the existing coping processes to work well, and those processes need to be applied anyway. So really the question is always about cost: what's the cheapest way for me to get to a desired vulnerability rate?

Which brings me to why I may prefer a low-level language that doesn't prevent UAF: because the language that does present UAF has a cost that is not worth it for me, either because UAF vulnerabilities are not a major risk for my application or because I have cheaper ways to prevent them (without necessarily eliminating the possibility of UAF itself), such as with one of the modern pointer-tagging techniques.

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

#244

Post by rixed »

shmolyneaux wrote: post #210
nmilo wrote: post #170

I don't know why anyone would write CLI tools in rust or zig. I/O is going to be your bottleneck way more often than GC, in fact I don't really get the GC hate outside of game dev, databases and other memory intensive applications. Why not use Go, Python, etc? People try to make a false dichotomy between memory safety vs. non-memory safety when really it's GC vs. no GC --- memory safety without it is going to be hard…

Instant startup times are really nice. You definitely notice the difference. It also means that you can be a bit lazier when creating wrappers around those tools (running 1000's of times isn't a problem when the startup is 1ms, but would be a problem with 40ms of startup time). Distribution can also be a lot easier if you don't need to care about the user having a specific version of Python or specific packages avail…

What makes python very slow start up has little to do with the GC though. Actually, a GC program for a short-lived program such as most CLI tools can be the fastest option since you could disable the GC and let the OS dealloc all memory at exit.

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

#245

Post by vanyle »

For CLI tools, the program usually only executes for a few seconds and then returns. In this context, you don't even need arena allocators or any memory management at all. You can write the tool in C with malloc and let the OS free the memory at the end without worry.

You could argue with the reasoning that C feels more practical than Zig for real-world CLI tools.

The argument provided by the author feels a bit besides the point.

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

#246

Post by timeon »

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…

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

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

#247

Post by wolvesechoes »

anon-3988 wrote: post #112
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…

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.

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

#248

Post by jmull »

estebank wrote: post #211
jmull wrote: post #129

Earlier quoted context omitted.

I think the problem the practical programmer has with a statement like this is the implication that only certain languages require some basic understanding and a bit of discipline to avoid CVEs. Rust's model has a strict model that effectively prevents certain kinds of logic errors/bugs. So that's good (if you don't mind the price). But it doesn't address all kinds of other logic errors/bugs. It's like closing one do…

> But it doesn't address all kinds of other logic errors/bugs. It's like closing one door to the barn, but there are six more still wide open. Could you point at some language features that exist in other languages that Rust doesn't have that help with logic errors? Sum types + exhaustive pattern matching is one of the features that Rust does have that helps a lot to address logic errors. Immutability by default, syn…

IMO, simplicity is the number one feature. The developer should spend their attention on the problem space as much as possible, and on the solution space as little as possible.

There's a complexity cost to adding features, and while each one may make sense on its own, in aggregate they may collectively burden the developer with too much complexity.

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

#249

Post by zanellato19 »

rixed wrote: post #230
jasonpeacock wrote: post #108

Earlier quoted context omitted.

> produce memory safe software with a bit of discipline "a bit of discipline" is doing a lot of work here. "Just don't write (memory) bugs!" hasn't produced (memory) safe C, and they've been trying for 50yrs. The best practices have been to bolt on analyzers and strict "best practice" standards to enforce what should be part of the language. You're either writing in Rust, or you're writing in something else + using e…

> "Just don't write (memory) bugs!" hasn't produced (memory) safe C Yes it did, of course. Maybe it takes years of practice, the assistance of tools (there are many, most very good), but it's always been possible to write memory safe large C programs. Sure, it's easier to write a robust program in almost every other language. But to state that nobody ever produced a memory safe C program is just wrong. Maybe it was j…

>Yes it did, of course. Maybe it takes years of practice, the assistance of tools (there are many, most very good), but it's always been possible to write memory safe large C programs.

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

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

#250

Post by dadrian »

vanderZwan wrote: post #232
dadrian wrote: post #172

Earlier quoted context omitted.

I like Zig, although the Bun Github tracker is full of segfaults in Zig that are presumably quite exploitable. Unclear what to draw from this, though. [1]: https://github.com/oven-sh/bun/issues?q=is%3Aissue%20state%3...

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
Post reply on HN