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

How safe is Zig?

scattered-thoughts.net

Post reply on HN
Print view View original

241–250 of 259 posts

Re: How safe is Zig?

#241

Post by avgcorrection »

haberman wrote: post #196
avgcorrection wrote: post #118

A meta point to make here but I don’t quite understand the pushback that Rust has gotten. How often does a language come around that flat out eliminates certain errors statically, and at the same time manages to stay in that low-level-capable pocket? And doesn’t require a PhD (or heck, a scholarly stipend) to use? Honestly that might be a once in a lifetime kind of thing. But not requiring a PhD (hyperbole) is not en…

I invested a lot of time porting some parsing code I had written to Rust, with the vision that Rust is the memory-safe future. The code I was porting from used arenas, so I tried to use arenas in Rust also. Using arenas required a bunch of lifetime annotations everywhere, but I was happy to do it if I could get provable memory safety. I got everything working, but the moment I tried to wrap it in Python, it failed. T…

I respect the effort. I won’t argue against such hard-earned experience.

Re: How safe is Zig?

#242

Post by avgcorrection »

Hermitian909 wrote: post #170
avgcorrection wrote: post #134

Earlier quoted context omitted.

> But if Option A has 20 defects and takes a lot of effort to go down to 15 defects, yet Option B has 25 defects and offers a quick path to go down to 10 defects, then which option is superior? Yes. If you change the entire premise of my example then things are indeed different. Rust eliminates some defects entirely. Most other low-level languages do not. You would have to use a language like ATS to even compete. Tha…

I'm not strongly opinionated on Rust specifically but I'm not sure: > Rust eliminates some defects entirely. Is really a true premise, and to the extent it is true, is not a clear to me that it makes Rust better or safer than languages who don't eliminate this class of bugs. Unsafe exists, is widely used, and importantly is used in places where the hairiest versions of these bugs tend to live anyways. For safe code,…

Yes, yes, yes. This was already covered in my original comment.

> you don’t ever have to even think about those kinds of things as long as you trust the compiler and the Unsafe code that you rely on.

Forgive if I don’t give the lawyerly disclaimer in all of my follow-up comments.

Yes, you have to be able to trust the Unsafe code that you depend on.

Re: How safe is Zig?

#243

Post by avgcorrection »

3a2d29 wrote: post #183
avgcorrection wrote: post #134

Earlier quoted context omitted.

> But if Option A has 20 defects and takes a lot of effort to go down to 15 defects, yet Option B has 25 defects and offers a quick path to go down to 10 defects, then which option is superior? Yes. If you change the entire premise of my example then things are indeed different. Rust eliminates some defects entirely. Most other low-level languages do not. You would have to use a language like ATS to even compete. Tha…

Rust does no eliminate memory errors. 200+ memory safety errors were found in rust crates: https://www.infoq.com/news/2021/11/rudra-rust-safety/ I love rust, I think there's a good chance zig in its current state isn't the answer, but saying rust is totally memory safe is wrong. You drop into unsafe and people make the same errors C/C++ devs make.

Give me a break. In my original comment:

> you don’t ever have to even think about those kinds of things as long as you trust the compiler and the Unsafe code that you rely on.

Your comment is not some kind of gotcha. I can’t be bothered to give the long-form disclaimer in all of my follow-up comments. Read the context.

Re: How safe is Zig?

#244

Post by avgcorrection »

coldtea wrote: post #140
avgcorrection wrote: post #125

Earlier quoted context omitted.

Nothing Is Perfect is a common refrain and non-argument. If option A has 20 defects and option B has the superset of 25 defects then option A is better—the fact that option A has defects at all is completely besides the point with regards to relative measurements.

> If option A has 20 defects and option B has the superset of 25 defects then option A is better Only if "defect count" is what you care for. What if you don't give a fuck about defect count, but prefer simplicity to explore/experiment quickly, ease of use, time to market, and so on?

Yeah what if you don’t care about memory safety bugs. Indeed.

Re: How safe is Zig?

#245

Post by avgcorrection »

modeless wrote: post #155
avgcorrection wrote: post #118

A meta point to make here but I don’t quite understand the pushback that Rust has gotten. How often does a language come around that flat out eliminates certain errors statically, and at the same time manages to stay in that low-level-capable pocket? And doesn’t require a PhD (or heck, a scholarly stipend) to use? Honestly that might be a once in a lifetime kind of thing. But not requiring a PhD (hyperbole) is not en…

It's pretty simple. Rust's safety features (and other language choices) have a productivity cost. For me I found the cost surprisingly high, and I'm not alone (though I'm sure I'll get replies from people who say the borrow checker never bothers them anymore and made them a better programmer, let's just agree there's room to disagree). Although I'm a big fan of safety, since experiencing Rust my opinion is that low-p…

Please read the fricking context.

My comment was about preferring other new, low-level languages over Rust when they don’t give the same safety guarantees. If you can deal with a GC then fine—my comment has got nothing to do with that.

So it was much, much more narrow than making a case for Rust in general.

Rust and GC both eliminate certain defects. And if you can use a GC then you don’t need Rust (w.r.t. memory safety).

Admittedly maybe I could have made it more clear that my comment does not make an argument against new low-level capable languages when used with some kind of automatic memory management scheme, like I guess Nim.

Re: How safe is Zig?

#246

Post by avgcorrection »

woodruffw wrote: post #158
avgcorrection wrote: post #120

Earlier quoted context omitted.

> This was a great read, with an important point: there's always a tradeoff to be made, and we can make it (e.g. never freeing memory to obtain temporal memory safety without static lifetime checking). I.e. we can choose to risk running out of memory? I don’t understand how this is a viable strategy unless you know you only will process a certain input size.

Yes. There are many domains where you know exactly how much memory you’ll need (even independent of input size), so just “leaking” everything is a perfectly valid technique.

You will have to explain this to me. From the original mention (article) it seems that they mean that compilers in general can be written in this way. Is that what they mean? Or do they mean that compilers can be written in that way if they know something about the inputs that it will be fed?

Re: How safe is Zig?

#247

Post by Klonoar »

Measter wrote: post #226
Klonoar wrote: post #147

Earlier quoted context omitted.

>Zigs solution is hands down better for actually getting work done Rust has seen significant usage in large companies; they wouldn't be using it unless it was usable for "real work". >Full disclaimer, I'm pretty bad at systems programming. Zig is the only one I've used where I didn't feel like memory management was a massive headache. I'd say this about Rust, though. Rust's mental model is very straightforward if you…

> Can you show me a "valid program" that Rust rejects? #[derive(Debug)] struct Foo { a: i32 } fn thing(foo: &mut Foo) { match foo { f @ Foo { a } if *a > 5 => { println!("{:?}", f) } _ => {} } } There's no reason it should reject that, as the use of the `a` reference doesn't interleave with the use of `f`.

By creating `f` you're in essence trying to borrow something that's mutably borrowed already, which the borrow checker doesn't allow. I guess I could see some logic for this being possible, but in practice I've never encountered this in any Rust codebase I've gone through.

The trivial example fix is just to... ensure it can copy, and tweak the match line:

    #[derive(Copy, Clone, Debug)]
    struct Foo {
        a: i32
    }
    
    fn thing(foo: &mut Foo) {
        match *foo {
            f @ Foo { a } if a > 5 => {
                println!("{:?}", f)
            }
        
            _ => {}
        }
    }
      

    fn main() {
        let mut x = Foo { a: 1 };
        thing(&mut x);
    }
If the struct was bigger and/or had types that couldn't copy, I'd refrain from trying to shoehorn matching like that entirely.

Re: How safe is Zig?

#248

Post by avgcorrection »

galangalalgol wrote: post #185
longrod wrote: post #182

I think Zig has a lot more footguns due to it's explicit nature. When you don't hide away the details from the human, you are increasing the risk of writing bad code and it becomes increasingly harder to make the compiler detect each potentially bad decision. Rust did it but they had to rethink the whole problem from the ground up. Rust is safe but that safety had quite the learning cost as compared to, say, Zig or G…

why does go always get brought up when talking about rust or nim or now zig? Its got gc, a large std lib, less latency than java but noticably slower, and its not suited for embedded or drivers. Its a completely different language for a completely different niche than zig or rist, though maybe I could see a comparison to nim... Maybe. I do like go for what it is, batteries included back end language with syntax nicer…

Go vs. Rust: the false rivalry that will simply. never. die.

Re: How safe is Zig?

#249

Post by igouy »

hndc wrote: post #238
galangalalgol wrote: post #232

Earlier quoted context omitted.

A very good point about rust (and c++ and c) being used outside embedded and systems. That's fair. But when people do that, they do it for performance, and go is easily 5x slower in my experience. It feels faster than java because the lower latency makes it feel more responsive, but its takes half again as long to finish the same tasks. And c# absolutely blows its doors off, closer to twice as long as c#. And c# feel…

> "in my experience" Here's some data: https://benchmarksgame-team.pages.debian.net/benchmarksgame/... Ignoring the programs using x86 intrinsics to do vectorized math, the top-performing Rust, Go, Java, and C# programs are all written in a simple, straightforward style; each is practically a direct translation from the other. The Rust program is fastest, but the others come in at 1.6x, 1.7x, and 1.7x the Rust progra…

> … Java, C#, or Go … all roughly in the same performance class.

As-in "Notice which box plot IQRs overlap."

https://benchmarksgame-team.pages.debian.net/benchmarksgame/...

Re: How safe is Zig?

#250

Post by Measter »

Klonoar wrote: post #247
Measter wrote: post #226

Earlier quoted context omitted.

> Can you show me a "valid program" that Rust rejects? #[derive(Debug)] struct Foo { a: i32 } fn thing(foo: &mut Foo) { match foo { f @ Foo { a } if *a > 5 => { println!("{:?}", f) } _ => {} } } There's no reason it should reject that, as the use of the `a` reference doesn't interleave with the use of `f`.

By creating `f` you're in essence trying to borrow something that's mutably borrowed already, which the borrow checker doesn't allow. I guess I could see some logic for this being possible, but in practice I've never encountered this in any Rust codebase I've gone through. The trivial example fix is just to... ensure it can copy, and tweak the match line: #[derive(Copy, Clone, Debug)] struct Foo { a: i32 } fn thing(f…

The borrow checker does allow that, though, as long the uses don't interleave and the references created correctly. As long as `f` is not used between `a`'s creation and last use, and `a` comes from `f`, it's valid for that alias to exist. You can see that with this code example, which is accepted:

    #[derive(Debug)]
    pub struct Foo {
        a: i32
    }
    
    impl Foo {
        fn get_a(&mut self) -> &mut i32 {
            &mut self.a
        }
    }
    
    pub fn thing(mut foo: &mut Foo) {
        let f = &mut foo;
        let a = f.get_a();
        if *a > 5 {
            println!("{:?}", f);
        }
    }
That's why I was so surprised the compiler rejected it.
Post reply on HN