←back to thread

Interview with Zig language creator Andrew Kelley [video]

(www.youtube.com)
200 points jorangreef | 6 comments | 27 Aug 20 11:10 UTC | HN request time: 1.836s | source | bottom
Show context
logicchains ◴[27 Aug 20 12:40 UTC] No.24293046[source]▶
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 over C++ and Rust, because it makes it much harder for e.g. the intern to write code that repeatedly creates a vector or dynamically allocated string in a loop. Or to use something like std::unordered_map or std::deque that allocates wantonly.

replies(8): >>24293328 #>>24293382 #>>24293469 #>>24293919 #>>24293952 #>>24294403 #>>24294507 #>>24298257 #
AsyncAwait ◴[27 Aug 20 13:13 UTC] No.24293328[source]▶
> This is a huge advantage over C++ and Rust, because it makes it much harder for e.g. the intern to write code that repeatedly creates a vector or dynamically allocated string in a loop. Or to use something like std::unordered_map or std::deque that allocates wantonly.

True. On the other hand, Zig makes a deliberate decision not to bother itself with memory safety too much, so its a win some, loose some sort of situation.

replies(1): >>24293466 #
pron ◴[27 Aug 20 13:29 UTC] No.24293466[source]▶
> On the other hand, Zig makes a deliberate decision not to bother itself with memory safety too much

This is not true. Zig places a strong emphasis on memory safety, it just does so in a way that's very different from either Java's or Rust's. I wrote more about this here: https://news.ycombinator.com/item?id=24293329

replies(2): >>24293966 #>>24295336 #
1. AsyncAwait ◴[27 Aug 20 16:30 UTC] No.24295336[source]▶
I meant a borrow checker, which I assumed was clear from what I was replying to. Yes, Zig does do runtime checks in dev builds and I did not mean to imply otherwise, I don't think the runtime checks provide the same set of benefits.

Just so we're clear, I like Zig :-)

replies(1): >>24297283 #
2. pron ◴[27 Aug 20 18:59 UTC] No.24297283[source]▶
> 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.

replies(1): >>24298562 #
3. fsociety ◴[27 Aug 20 20:55 UTC] No.24298562[source]▶
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.
replies(1): >>24298692 #
4. pron ◴[27 Aug 20 21:09 UTC] No.24298692{3}[source]▶
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.

replies(1): >>24299620 #
5. AsyncAwait ◴[27 Aug 20 23:00 UTC] No.24299620{4}[source]▶
> 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

I don't think this is actually true. The compiler is slow but not due to memory safety; the 'cargo check' command is rather quick and the compiler itself doesn't seem to spend a lot of time in the frontend, most of the time in spent in the backend, past the borrow checking phrase.

replies(1): >>24305338 #
6. pron ◴[28 Aug 20 14:34 UTC] No.24305338{5}[source]▶
https://news.ycombinator.com/item?id=24302711