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

How (memory) safe is Zig? (2021)

scattered-thoughts.net

Post reply on HN
Print view View original

51–60 of 88 posts

Re: How (memory) safe is Zig? (2021)

#51

Post by throwawaymaths »

josephg wrote: post #50
alpaca128 wrote: post #44

Earlier quoted context omitted.

There's also no reason to have a separate borrow checker if it could just be integrated in the compiler. When a compiler has a borrow checker that means the language was already designed to enable borrow checking in the first place. And if a language can let you do borrow checking why would you use a separate tool?

Also it’s a great way to make sure every library in the ecosystem passes the borrow checker.

why do you expect compile time static analysis to fail at this? unless youre loading a precompiled asset?

Re: How (memory) safe is Zig? (2021)

#52

Post by throwawaymaths »

saagarjha wrote: post #46
throwawaymaths wrote: post #41

Earlier quoted context omitted.

static code analysis tools can also do it. there's no reason why the borrow checker must be in the compiler proper.

Because you're always going to write some code that the tools can't reason about.

thats true for rust too (hence "unsafe")

Re: How (memory) safe is Zig? (2021)

#53

Post by pizlonator »

Rusky wrote: post #39
pizlonator wrote: post #36

Earlier quoted context omitted.

Rust attempts to enforce guarantees statically, but in practice fails, because of pervasive use of `unsafe`. Fil-C doesn't "add a runtime". C already has a runtime (loader, crt, compiler runtime, libc, etc)

The stuff Fil-C adds is on the same footing as `unsafe` code in Rust- its implementation isn't checked, but its surface area is designed so that (if the implementation is correct) the rest of the program can't break it. Whether the amount and quality of this kind of code is comparable between the two approaches depends on the specific programs you're writing. Static checking, which can also be applied in more fine-gr…

> The stuff Fil-C adds is on the same footing as `unsafe` code in Rust- its implementation isn't checked, but its surface area is designed so that (if the implementation is correct) the rest of the program can't break it.

It’s not the same.

The Fil-C runtime is the same runtime in every client of Fil-C. It’s a single common trusted compute base and there’s no reason for it to grow.

On the other hand Rust programmers use unsafe all over the place, not just in some core libraries.

Re: How (memory) safe is Zig? (2021)

#54

Post by throwawaymaths »

alpaca128 wrote: post #44
throwawaymaths wrote: post #41

Earlier quoted context omitted.

static code analysis tools can also do it. there's no reason why the borrow checker must be in the compiler proper.

There's also no reason to have a separate borrow checker if it could just be integrated in the compiler. When a compiler has a borrow checker that means the language was already designed to enable borrow checking in the first place. And if a language can let you do borrow checking why would you use a separate tool?

because it gets it out of the fast path compile cycle. do you need a borrow checker for `ls`? Probably not. don't use it. do you need it every time you work through intermediate ideas in a refactor? probably not. just turn it on in CI.

Re: How (memory) safe is Zig? (2021)

#55

Post by pizlonator »

comex wrote: post #43
pizlonator wrote: post #31

Earlier quoted context omitted.

> It makes it a lot less performant and there is no avoiding or mitigating that downside. You can’t possibly know that. > C++ is often selected as a language instead of safer options for its unusual performance characteristics even among systems languages in practice. Is that why sudo, bash, coreutils, and ssh are written in C? Of course not. C and C++ are often chosen because they make systems programming possible a…

> C and C++ are often chosen because they make systems programming possible at all due to their direct access to syscall ABI. Surely Fil-C cannot provide direct access to syscalls without violating the safety guarantee. There must be something ensuring that what the kernel interprets as a pointer is actually a valid pointer. > Fil-C means you cannot claim - as TFA claims - that it’s impossible to make C and C++ safe.…

> Surely Fil-C cannot provide direct access to syscalls without violating the safety guarantee. There must be something ensuring that what the kernel interprets as a pointer is actually a valid pointer.

This is exactly what Fil-C does.

> all the known disadvantages of C and C++

The main disadvantage of C and C++ is unsafety and fil-C comprehensively fixes that.

> edit: I feel bad writing such a dismissive comment, but it's hard to avoid reacting that way when I see unrealistically rosy portrayals of projects.

How is my portrayal unrealistically rosy?

Even the fact that you know what the current perf costs are is the result of me being brutally honest about its perf.

I suspect something else is going on.

Re: How (memory) safe is Zig? (2021)

#56

Post by throwawaymaths »

tialaramex wrote: post #45
throwawaymaths wrote: post #41

Earlier quoted context omitted.

static code analysis tools can also do it. there's no reason why the borrow checker must be in the compiler proper.

"But seatbelts would also work if everybody was just choosing to use them rather than us mandating their fitment and use, so I don't understand why facts are true" Amusingly this is even true for the linter, nobody ran the C linter, more or less everybody runs the Rust linter, the resulting improvement in code quality is everything you'd hope. All humans love to believe they're above average, most are not and average…

what the hell are you talking about. if you are writing security conscious software you should turn on a static checker and proudly show a badge that says "this code is memory safe". if youre writing a custom data pipeline to be used in a niche scientific field where the consumers are you and anyone that wants to repro your pipeline, and everything is in arenas, who the fuck cares. don't bother with static analysis.

Re: How (memory) safe is Zig? (2021)

#57

Post by Zambyte »

saagarjha wrote: post #49
BrouteMinou wrote: post #40

I don't know why we are still having this topic going on. Zig is not safe, period. Zig gives you the control you need if that is what you want, safety isn't something Zig is chasing. Safer than C, yeah, but not safe. Rust = safe Zig = control Pick your weapon for the foe in front of you.

I don't think Zig gives you significantly more control than Rust.

Maybe not Zig the language, but the fact that all allocating functions in the standard library accept an allocator (and community libraries follow this precedent) does give you much more control in practice.

For example, how would you use a Vec using stack memory for elements, instead of the heap? For the equivalent data structure in Zig (std.ArrayList), it's just a matter of using a stack allocator instead of using a heap allocator, which is an explicit decision either way.

Re: How (memory) safe is Zig? (2021)

#58

Post by josephg »

throwawaymaths wrote: post #51
josephg wrote: post #50

Earlier quoted context omitted.

Also it’s a great way to make sure every library in the ecosystem passes the borrow checker.

why do you expect compile time static analysis to fail at this? unless youre loading a precompiled asset?

I don't. I think compile time static analysis is great. Upthread you said this:

> there's no reason why the borrow checker must be in the compiler proper.

On a technical front, I completely agree. But there's an ecosystem benefit to having the borrow checker as part of the compiler. If the borrow checker wasn't in the compiler proper, lots of people would "accidentally forget" to run it. As a result, lots of libraries would end up on crates.io which fail the borrow checker's checks. And that would be a knock on disaster for the ecosystem.

But yes, there's nothing stopping you writing a rust compiler without a borrow checker. It wouldn't change the resulting binaries at all.

Re: How (memory) safe is Zig? (2021)

#59

Post by josephg »

throwawaymaths wrote: post #56
tialaramex wrote: post #45

Earlier quoted context omitted.

"But seatbelts would also work if everybody was just choosing to use them rather than us mandating their fitment and use, so I don't understand why facts are true" Amusingly this is even true for the linter, nobody ran the C linter, more or less everybody runs the Rust linter, the resulting improvement in code quality is everything you'd hope. All humans love to believe they're above average, most are not and average…

what the hell are you talking about. if you are writing security conscious software you should turn on a static checker and proudly show a badge that says "this code is memory safe". if youre writing a custom data pipeline to be used in a niche scientific field where the consumers are you and anyone that wants to repro your pipeline, and everything is in arenas, who the fuck cares. don't bother with static analysis.

If everything is in arenas, lifetimes get much easier.

But, the borrow checker doesn't just check lifetimes. It also checks ownership, and that variables either have a single mutable reference or immutable references. The optimizer assumes those invariants are maintained in the code. Many of its optimizations wouldn't be sound otherwise.

So, if you could compile code which fails the borrow checker, there's all sorts of weird and wonderful sources of UB eagerly waiting to give you a really bad day - from aliasing issues to thread safety problems to use-after-free bugs. The borrow checker has been around forever in rust. So I don't think anyone has any idea what the implications would be of compiling "bad" code.

Re: How (memory) safe is Zig? (2021)

#60

Post by throwawaymaths »

josephg wrote: post #59
throwawaymaths wrote: post #56

Earlier quoted context omitted.

what the hell are you talking about. if you are writing security conscious software you should turn on a static checker and proudly show a badge that says "this code is memory safe". if youre writing a custom data pipeline to be used in a niche scientific field where the consumers are you and anyone that wants to repro your pipeline, and everything is in arenas, who the fuck cares. don't bother with static analysis.

If everything is in arenas, lifetimes get much easier. But, the borrow checker doesn't just check lifetimes. It also checks ownership, and that variables either have a single mutable reference or immutable references. The optimizer assumes those invariants are maintained in the code. Many of its optimizations wouldn't be sound otherwise. So, if you could compile code which fails the borrow checker, there's all sorts…

Point being, there are many many individual programs where none of those things you talk about exist. So why not have a programming system where you can actually turn those things off for development velocity.

I'm rejecting the idea that "opt-in" is bad. Opt-out is of course better, but "no choice" is not good.

Post reply on HN