Interview with Zig language creator Andrew Kelley [video] • Hacker News Board

Re: Interview with Zig language creator Andrew Kelley [video]

#131

Post by pron » Thu, Aug 27, 2020, 9:01 PM UTC

littlestymaar wrote: post #121

pron wrote: post #85

Earlier quoted context omitted.

> https://github.com/ziglang/zig/pull/5998 TBD :) But here's one way that's currently being tried: https://github.com/ziglang/zig/pull/5998

(Small copy past error here, you posted the same link twice.) Regarding https://github.com/ziglang/zig/pull/5998 here we're exactly in the realm of C, changing the allocator with a custom one with additional bookkeeping to check for memory management issues. But it tanks performances so you can't generally use it for production (and if you were in a situation were you'd do it anyway, you'd be better off with complete…

No, Zig is not in the realm of C. Zig gives you full memory safety that you can then selectively turn off. Why is it useful? For the same reason tests are useful even if they don't give you sound guarantees, and are still the primary way of achieving correctness, even in Haskell or Rust. C does not and cannot do this the same way as Zig does, because C cannot be made safe (well, it can, but that's a whole other can of worms) while Zig can. So you make Zig safe, test it, and then remove the guardrails from the performance-critical bits after you're satisfied with their correctness.

Does it provide safety in the same manner Rust does? Absolutely not. Does it provide less correctness overall? Maybe, and maybe it provides more correctness, and maybe the same. It's hard to say without an empirical study. The problem is that sound guarantees often come at a cost -- for example, to language complexity and compilation speed -- that can have a negative effect on correctness.

Re: Interview with Zig language creator Andrew Kelley [video]

#132

Post by pron » Thu, Aug 27, 2020, 9:09 PM UTC

fsociety wrote: post #129

pron wrote: post #116

Earlier quoted context omitted.

> I don't think the runtime checks provide the same set of benefits. Of course not, but that doesn't mean Zig is less effective at achieving correctness. It just does so in a different way -- it trades sound guarantees for less sound ones and a simpler language with a faster cycle. Is one better than the other? Hard to say. Only empirical study could settle that.

I’d argue it does mean it is less effective at achieving correctness but the trade-off made is the whole point of Zig. Simple language that is really a better C.

It's hard to make a definitive argument one way or the other because the guarantees Rust makes come at a cost of compilation speed and language complexity that can have a negative effect on correctness. This question is impossible to answer without an empirical study.

Unlike C, Zig is (or will be) memory safe, although its safety can be turned off, and often is -- after testing. Unlike C, it provides powerful abstraction capabilities similar to those of C++. The fact that it can do all that yet be very simple seems to suggest at first glance that it's "like C" but that's because we've never had a language like that before. Zig's simplicity is misleading. It turns out you can do a lot with a very simple language. We knew that to be true for high-level languages like Scheme, but Zig shows it's possible in low-level languages, too.

Re: Interview with Zig language creator Andrew Kelley [video]

#133

Post by littlestymaar » Thu, Aug 27, 2020, 9:13 PM UTC

pron wrote: post #131

littlestymaar wrote: post #121

Earlier quoted context omitted.

(Small copy past error here, you posted the same link twice.) Regarding https://github.com/ziglang/zig/pull/5998 here we're exactly in the realm of C, changing the allocator with a custom one with additional bookkeeping to check for memory management issues. But it tanks performances so you can't generally use it for production (and if you were in a situation were you'd do it anyway, you'd be better off with complete…

No, Zig is not in the realm of C. Zig gives you full memory safety that you can then selectively turn off. Why is it useful? For the same reason tests are useful even if they don't give you sound guarantees, and are still the primary way of achieving correctness, even in Haskell or Rust. C does not and cannot do this the same way as Zig does, because C cannot be made safe (well, it can, but that's a whole other can o…

> C does not and cannot do this the same way as Zig does

Regarding the PR you just sent, I'd like to hear why you think it cannot be applied to C?

> So you make Zig safe, test it, and then remove the guardrails from the performance-critical bits after you're satisfied with their correctness.

This isn't safety… This is “we didn't find any memory issue while fuzzing the software” and you'd get the same guarantee: if your fuzzer didn't cause the memory issue, then it remains in your code in production, waiting to explode one day with some hard to debug Heisenbug that only occurs once in a million…

Re: Interview with Zig language creator Andrew Kelley [video]

#134

Post by klodolph » Thu, Aug 27, 2020, 9:25 PM UTC

nextaccountic wrote: post #115

klodolph wrote: post #109

Earlier quoted context omitted.

I also wish that Rust had linear types, it would make a lot of FFI easier without resorting to unsafe{}. With linear types you can guarantee that a destructor is run, so you can create objects with lifetimes that are not only bounded from below, but bounded by above. There are some common patterns in e.g. C libraries that rely on this--for example, you might register a callback on an object, and you want to assert th…

What about making the object borrow from the closure? This can be accomplished by a method that consumes the object and returns the closure (which now owns the object), and a closure method's that borrows the object back from it.

> What about making the object borrow from the closure?

That doesn't actually guarantee that the closure will outlive the object. You would need linear types in order to do that, and Rust does not have linear types.

In the particular API I'm working with, you pass the closure in to an object when you create it, and you have to make sure that the closure outlives the object. The only way to do that within the Rust type system is by making the closure 'static, which is... less than ideal. So you use unsafe{} instead.

This is because any object may outlive its specified lifetime. Lifetimes are only lower bounds. So if I have lifetimes 'b and 'a, and 'b : 'a, this only means that the LIFETIME 'b must be at least as long as the LIFETIME 'a, but any particular object with lifetime 'b may live arbitrarily long, as long as it lasts at least as long as 'b. And any object which is 'a may last arbitrarily long, but at least as long as 'a.

Re: Interview with Zig language creator Andrew Kelley [video]

#135

Post by pron » Thu, Aug 27, 2020, 9:29 PM UTC

littlestymaar wrote: post #133

pron wrote: post #131

Earlier quoted context omitted.

No, Zig is not in the realm of C. Zig gives you full memory safety that you can then selectively turn off. Why is it useful? For the same reason tests are useful even if they don't give you sound guarantees, and are still the primary way of achieving correctness, even in Haskell or Rust. C does not and cannot do this the same way as Zig does, because C cannot be made safe (well, it can, but that's a whole other can o…

> C does not and cannot do this the same way as Zig does Regarding the PR you just sent, I'd like to hear why you think it cannot be applied to C? > So you make Zig safe, test it, and then remove the guardrails from the performance-critical bits after you're satisfied with their correctness. This isn't safety… This is “we didn't find any memory issue while fuzzing the software” and you'd get the same guarantee: if yo…

> Regarding the PR you just sent, I'd like to hear why you think it cannot be applied to C?

I didn't mean that a safe allocator cannot be used in C; I meant that C cannot be made memory safe in its entirety as simply as Zig can. Why? Because C has pointer arithmetic while (safe) Zig doesn't, Zig has slices while C doesn't, and C has non-typesafe casts while safe Zig doesn't.

> This isn't safety… This is “we didn't find any memory issue while fuzzing the software” and you'd get the same guarantee:

No, it's not the same guarantee. Fuzzing a C program will not find all the undefined behaviour that fuzzing a Zig program can, for the reasons I mentioned.

It is true that if you use unsafe Zig, i.e. turn off safety for a whole program or some sections of it, you lose the guarantees that safe Zig gives you, and unsafe Zig is indeed not safe (neither is unsafe Rust). But because of the way it's designed, Zig has a way of improving correctness even when safety is removed. This is a tradeoff for sure, but so are sound guarantees, that can have other negative effects on correctness.

Re: Interview with Zig language creator Andrew Kelley [video]

#136

Post by rightbyte » Thu, Aug 27, 2020, 9:38 PM UTC

littlestymaar wrote: post #87

pron wrote: post #77

Earlier quoted context omitted.

> and rust is taking inspiration from it already But C++/Rust can never have Zig's primary feature -- simplicity. Zig's power is not that it has comptime, but that it has little else . > I can't wait before Zig2 comes and eventually adds generics… No need. Zig gives you the same capabilities as generics do, only through a separate feature that other languages also have in addition to generics. In other words, it has…

> But C++/Rust can never have Zig's primary feature -- simplicity Sounds like a Go pitch, except Zig ain't Go. And while comptime is a cool feature, it's also a really complex one! > In other words, it has generics, but without having generics as a special construct. Zig recognises that once you have that other feature (compile-time introspection) you don't need generics as a separate construct, but they can be just…

"C is also simple, for instance it has no concept of [...] arrays (only pointers)"

That is a confusing part with C. C do have a concept of arrays, but not as function arguments. You notice it first with multidimensional arrays.

Re: Interview with Zig language creator Andrew Kelley [video]

#137

Post by pron » Thu, Aug 27, 2020, 9:46 PM UTC

the_duke wrote: post #125

logicchains wrote: post #10

I work in HFT, and one of the key concerns when writing low-latency code is "is this code allocating memory, and if so, how can I stop it?" Zig is the perfect language for this use case as none of the standard library implicitly allocates, rather for anything that allocates, the caller must pass in an allocator. The stdlib also provides a handy arena allocator, which is often the best choice. This is a huge advantage…

There is some ongoing work towards custom allocators for containers in Rust std. [1] Right now you could also go no_std (you still get the core library, which does not contain any allocating data structures) and use custom containers with a passed in allocator. Zig is definitely a cool language, and it will be interesting if they can come up with good solutions to memory management! But sentences like these in the do…

> But sentences like these in the documentation [2] would make me prefer Rust for most low level domains

While such use-after-free issues are not prevented at compile time, the plan is to ultimately have safe Zig catch them (and panic) at runtime, i.e. safe Zig shouldn't have undefined behaviour. Because this is done with runtime checks, the expectation is that those checks will be turned off (selectively, perhaps) in production, after testing has satisfied you. In that case, the guarantees aren't as strong as Rusts, but those guarantees come at a significant cost -- to language complexity and compilation time -- that can also have a negative effect on correctness. So while Zig's approach to safety/correctness is certainly very different from Rust's, I don't think it is necessarily weaker (perhaps it could even be stronger, but the question is hard to settle).

Re: Interview with Zig language creator Andrew Kelley [video]

#138

Post by pron » Thu, Aug 27, 2020, 9:51 PM UTC

vmchale wrote: post #110

pron wrote: post #22

Earlier quoted context omitted.

Zig gives you memory safety (or, rather, will ultimately do that), but it does so in a way that's different from both languages with garbage collection (whether tracing or reference-counting) or with sound type-system guarantees a-la Rust. It does so with runtime checks that are turned on in development and testing and turned off -- either globally or per code unit -- in production. You lose soundness, but we don't h…

That's not on par with linear or affine types.

When compared in isolation, yes. But such mechanisms aren't free; they add to both language complexity and compilation time, two things that can have a negative impact on correctness. So it's impossible to say which approach leads to more correct programs overall without empirical study.

We see similar tradeoffs of soundness in formal verification as well. We're not talking about exactly the same thing here (because affine type safety is compositional) but the general principle is the same: soundness has a cost, and it is not necessarily the most efficient way of achieving a required level of correctness.

Anyway, I think that both Rust and Zig have very interesting approaches to safety, but I don't think we know enough to claim one is more effective than the other at this time.

Re: Interview with Zig language creator Andrew Kelley [video]

#139

Post by nyanpasu64 » Thu, Aug 27, 2020, 10:29 PM UTC

voldacar wrote: post #27

logicchains wrote: post #10

I work in HFT, and one of the key concerns when writing low-latency code is "is this code allocating memory, and if so, how can I stop it?" Zig is the perfect language for this use case as none of the standard library implicitly allocates, rather for anything that allocates, the caller must pass in an allocator. The stdlib also provides a handy arena allocator, which is often the best choice. This is a huge advantage…

Yeah when I heard about this I instantly thought of game engines, but it makes total sense for HFT too. "Modern C++", with all its constant little mallocs and frees is so awful for anything that requires ultra low latency

std::span is a modern C++ class designed to act like an array or vector, by viewing the memory of an existing array/vector without allocating anything. In my experience writing audio code, C++'s implicit copy constructors are what makes it too easy to accidentally allocate memory.

Re: Interview with Zig language creator Andrew Kelley [video]

#140

Post by [deleted] » Thu, Aug 27, 2020, 10:45 PM UTC

pron wrote: post #131

littlestymaar wrote: post #121

Earlier quoted context omitted.

(Small copy past error here, you posted the same link twice.) Regarding https://github.com/ziglang/zig/pull/5998 here we're exactly in the realm of C, changing the allocator with a custom one with additional bookkeeping to check for memory management issues. But it tanks performances so you can't generally use it for production (and if you were in a situation were you'd do it anyway, you'd be better off with complete…

No, Zig is not in the realm of C. Zig gives you full memory safety that you can then selectively turn off. Why is it useful? For the same reason tests are useful even if they don't give you sound guarantees, and are still the primary way of achieving correctness, even in Haskell or Rust. C does not and cannot do this the same way as Zig does, because C cannot be made safe (well, it can, but that's a whole other can o…

[deleted]