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

41–50 of 88 posts

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

#41

Post by throwawaymaths »

josephg wrote: post #28
90s_dev wrote: post #2

> But it does not nearly approach the level of systematic prevention of memory unsafety that rust achieves. Unless I gravely misunderstood Zig when I learned it, the Zig approach to memory safety is to just write a ton of tests fully exercising your functions and let the test allocators find and log all your bugs for you. Not my favorite approach, but your article doesn't seem to take into account this entirely diffe…

Yes, testing is Zig's answer. But that quote is right. Testing doesn't achieve the same kind of systematic prevention of memory bugs that rust does. (Or GC based languages like Go, Java, JS, etc.). You can write tests to find bugs in any language. C + Valgrind will do most of the same thing for C that the debug allocator will do for zig. But that doesn't stop the avalanche of memory safety bugs in production C code.…

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

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

#43

Post by comex »

pizlonator wrote: post #31
jandrewrogers wrote: post #26

Earlier quoted context omitted.

It makes it a lot less performant and there is no avoiding or mitigating that downside. C++ is often selected as a language instead of safer options for its unusual performance characteristics even among systems languages in practice. Fil-C is not a replacement for C++ generally, that oversells it. It might be a replacement for some C++ software without stringent performance requirements or a rigorously performance-e…

> 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. You have to now hedge that claim with additional caveats about performance. And even then you’re on thin ice since the top perf problems in Fil-C are due to immaturity of its implementation (like the fact that linking is hella cheesy and the ABI is even cheesier).

The world of compilers is littered with corpses of projects that spent years claiming faster performance was right around the corner.

I believe you can make it faster, but how much faster? We'll see.

I think these types of compatibility layers will be a great option moving forward for legacy software. But I have a hard time seeing the case for using Fil-C for new code: all the known disadvantages of C and C++, now combined with performance closer to Java than Rust (if not worse), and high difficulty interoperating with other native code (normally C and C++'s strength!), in exchange for marginal safety improvements over Rust (minus Rust's more general safety culture).

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.

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

#44

Post by alpaca128 »

throwawaymaths wrote: post #41
josephg wrote: post #28

Earlier quoted context omitted.

Yes, testing is Zig's answer. But that quote is right. Testing doesn't achieve the same kind of systematic prevention of memory bugs that rust does. (Or GC based languages like Go, Java, JS, etc.). You can write tests to find bugs in any language. C + Valgrind will do most of the same thing for C that the debug allocator will do for zig. But that doesn't stop the avalanche of memory safety bugs in production C code.…

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?

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

#45

Post by tialaramex »

throwawaymaths wrote: post #41
josephg wrote: post #28

Earlier quoted context omitted.

Yes, testing is Zig's answer. But that quote is right. Testing doesn't achieve the same kind of systematic prevention of memory bugs that rust does. (Or GC based languages like Go, Java, JS, etc.). You can write tests to find bugs in any language. C + Valgrind will do most of the same thing for C that the debug allocator will do for zig. But that doesn't stop the avalanche of memory safety bugs in production C code.…

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 is by definition a mediocre aspiration. Do better.

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

#46

Post by saagarjha »

throwawaymaths wrote: post #41
josephg wrote: post #28

Earlier quoted context omitted.

Yes, testing is Zig's answer. But that quote is right. Testing doesn't achieve the same kind of systematic prevention of memory bugs that rust does. (Or GC based languages like Go, Java, JS, etc.). You can write tests to find bugs in any language. C + Valgrind will do most of the same thing for C that the debug allocator will do for zig. But that doesn't stop the avalanche of memory safety bugs in production C code.…

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.

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

#47

Post by saagarjha »

ajross wrote: post #14
KerrAvon wrote: post #6

Earlier quoted context omitted.

What that means, though, is that you have a choice between defining memory unsafely away completely with Rust or Swift, or trying to catch memory problems by a writing a bunch of additional code in Zig.

Weird that Swift is your totem for "managed/collected runtime" and not Java (or C#/.NET, or Go, or even Javascript). I mean, it fits the bill, but it's hardly the best didactic choice.

I don't think they said anything about that?

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

#48

Post by saagarjha »

90s_dev wrote: post #17
KerrAvon wrote: post #6

Earlier quoted context omitted.

What that means, though, is that you have a choice between defining memory unsafely away completely with Rust or Swift, or trying to catch memory problems by a writing a bunch of additional code in Zig.

What if -- stay with me now -- what if we solved it by just writing vastly less code , and having actually reusable code, instead of reinventing every type of wheel in every project? Maybe that's the real secret to sound code. Actual code reuse. I know it's a pipedream, but a man can dream, can't he?

No, this doesn't solve the problem. Libraries have security issues like every other codebase.

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

#49

Post by saagarjha »

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.

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

#50

Post by josephg »

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?

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