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

251–260 of 412 posts

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

#251

Post by cestith »

pjmlp wrote: post #164
cestith wrote: post #80

Earlier quoted context omitted.

Do you know any other languages that tend to be safer than C and suitable for CLI tools but without the borrow checker? Over many years I’ve seen a lot in C++, Go, Perl, Python, Ruby, Pascal, various shells, assembly, Java, and some in Haxe, Ada, Lisp, Scheme, Julia, forms of Basic, and recently JavaScript or Typescript. Most of those are more memory safe than C. None of them have the borrow checker. This leaves me w…

OCaml for example, Unix system programming in OCaml, from 1991 https://ocaml.github.io/ocamlunix/

It’s such a nice language, too. It’s too bad it doesn’t get more attention. I know someone who regularly runs a couple of utilities written in Haskell, but they’re the only Haskell code in his entire organization. It’s a shop that has C, C++, Rust, JavaScript, TypeScript, Python, and Go in production, Java in legacy production, and has half a dozen other languages in production support situations. Haskell has not caught on there, though.

I’m aware a few companies use primarily OCaml just as a few use primarily some form of Lisp. It’s just that some of these really nice languages don’t see as much use as they could.

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

#252

Post by quotemstr »

rixed wrote: post #236
quotemstr wrote: post #218

Earlier quoted context omitted.

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

> How is it that people simultaneously believe > 1) GC makes a language slow, and > 2) Go is fast? Easy one: either not the same people, or people holding self contradicting thoughts. GC are slow not only because of scanning the memory but also because of the boxing. In my experience, 2 to 3 times slower. Still a better tradeoff in the vast majority of cases over manual memory management. A GC is well worth the peace…

> also because of the boxing

Not every GC boxes primitives. Most don't.

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

#253

Post by einpoklum »

Klonoar wrote: post #239
iphone_elegance wrote: post #60

when I think of rust I think of beauties like this, self.last.as_ref().unwrap().borrow().next.as_ref().unwrap().clone() I know it can be improved but that's what I think of

Without any context it’s impossible to tell if code needs to be that obtuse or if uou somehow built your way into a setup that you could’ve avoided. ;P

GP is suggesting that one typically finds oneself in such a situation with idiomatic code. Even if it can be avoided with some effort, it will all too easily not be avoided.

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

#254

Post by yen223 »

danudey wrote: post #167
travisgriggs wrote: post #135

Earlier quoted context omitted.

> Rust is your lane assist. It relieves you from the burden of constant vigilance. Interesting analogy. I love lane assist. When I love it. And hate it when it gets in the way. It can actively jerk the car in weird and surprising ways when presented with things it doesn’t cope well with. So I manage when it’s active very proactively. Rust of course has unsafe… but… to keep the analogy, that would be like driving in a…

I have also mostly only dabbled with Rust, and I've come to the conclusion that it is a fantastic language for a lot of things but it is very unforgiving. The optimal way to write Python is to have your code properly structured, but you can just puke a bunch of syntax into a .py file and it'll still run. You can experiment with a file that consists entirely of "print('Hello World')" and go from there. Import a json f…

Someone (Rich Hickey?) described this as a piano that doesn't make a sound until you play the piece perfectly, and that analogy has stuck with me since.

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

#255

Post by dayvster »

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. 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 any other language that does not put that much burden on you the developer.

Not all memory safety bugs are critical issues either. We like to pretend like they are but specifically in `coreutils` there were 2 memory safety bugs found recently.

However is it really a big concern? 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.

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

#256

Post by minraws »

K0nserv wrote: post #235
dayvster wrote: post #229

Earlier quoted context omitted.

this is an excellent example do you mind if I examine it a bit closer and perhaps use it in my article?

Yes of course, although, as I said in a sibling comment, it's a bit convoluted as an example. The fundamental problem is that the xor mutable and shared reference rule gets in your way when you access separate fields through &self and &mut self even if the borrows are non-overlapping. There has been discussion to solve this particular problem[0]. 0: https://github.com/rust-lang/rfcs/issues/1215

That RFC and Polonius, which Rust folks have been working on for the last 5-6 years is proof that there has been much effort made in related directions.

Rust being sub par for so long just shows how much people won't want to fund these problems and how hard they are to solve during program compile.

I ofc like Zig quite a bit but I find Rust to suit my tastes better. Zig feels too much like C with extra steps. And the lack of good tooling and stability around Zig hurts large scale adoption.

But I think in 10 years Zig will be the de facto better-ish C.

And Rust will be the low level language for any large project where safety is amongst the top 3 priorities.

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

#257

Post by dayvster »

zanellato19 wrote: post #249
rixed wrote: post #230

Earlier quoted context omitted.

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

[flagged]

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

#258

Post by johncolanduoni »

pron wrote: post #243
johncolanduoni wrote: post #220

Earlier quoted context omitted.

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

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 spend time/money on memory safety in CPython or on making CSRF in whatever Python library I use harder. My understanding is that the proportions of the budget for different areas of vulnerability research at any tech giant would in fact vindicate this logic.

However, if I’m on the V8 team or a CPython contributor and I’m trying to reduce vulnerabilities, I don’t have any levers to pull for CSRF or SQL injection without just instead working on a totally different project that happens to be built on the relevant language. 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.

Similarly, if I’m choosing a language to (re)write my software in and Zig is on the table, I am probably not super worried about CSRF and SQL injection - most likely I’m not writing an API accessed by a browser or interfacing with a SQL database at all! Also I have faith that almost all developers who know what Zig is in the first place would not write code with a SQL injection vulnerability in any language. That those are still on the top ten list is a condemnation of our entire species, in my book.

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

#259

Post by charcircuit »

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…

>Safety is less ergonomic.

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

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

#260

Post by scoopdewoop »

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…

> 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 accomplish my goals, and I'm sure you wouldn't understand my goals. I've been making code creatively for almost 30 years. You might as well tell an origami artist that folding paper is a bad way to accomplish their goals.

The attitude among _some_ Rust devs (or armchair coders) that there is no place for non-rust manual-memory languages is insanely disconnected with reality. Games exist, Rust ones hardly do. Synths exist, Rust ones hardly do. Not everything is a high-availability microservice or an OS kernel! Look around!

Edited to add:

> "Safety" is just a shorthand for "my program means what I say". Unsafety is semantic gibberish.

You know this isn't true, right? "Safety" in Rust specifically means memory safety and thread safety: no use-after-free, no data races, no null/dangling pointer dereferences, no buffer overflows. That's it. It doesn't guarantee your program is correct, and it doesn't even prevent memory leaks.

Things being manually managed doesn't make them gibberish, and something being implicit, rather than explicit, doesn't mean its gibberish.

The attitude of Rust being bug-free is _insaaaane_. A "bug" is just code that breaks expectations, I promise we can and will write those in every language forever.

Post reply on HN