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

Interview with Zig language creator Andrew Kelley [video]

youtube.com

Post reply on HN
Print view View original

21–30 of 210 posts

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

#21

Post by AsyncAwait »

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…

> 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.

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

#22

Post by pron »

tobz1000 wrote: post #17

Some of Zig's ideas fascinate me, both the great low-level concepts (e.g. arbitrary-sized ints), but much more than that, the high level concepts. Particularly great is Zig's handling of both macros and generic types, the answer to both of which seems to be: just evaluate them at compile-time with regular functions, no special DSL or extra syntax. Andrew mentions in the video a big drawback of this system - implicati…

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 have sound guarantees for functional correctness, anyway, and given that Zig makes testing very easy, it's unclear whether a particular approach dominates the other in terms of correctness.

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

#23

Post by notacoward »

logicchains wrote: post #20
notacoward wrote: post #18

Earlier quoted context omitted.

I have a lot of sympathy for that position. The thing that drives me nuts about the codebase I work in now is that it has idioms that involve "promiscuous" memory allocation and then more idioms to fix/cover it up. I'm fine with languages that require completely manual memory allocation (spent most of my career in C). I'm also fine with languages that totally take that burden away. There are tradeoffs either way, but…

>STL-heavy C++17 and beyond is, of course, the salient example. I've seen "clever" code in that style, but never great code. Maybe the authors of that code just had different priorities, such as maximising compilation time.

Hah! Yeah, that does seem sometimes like it must have been a deliberate goal, doesn't it? Got a good laugh out of that. The number of cycles wasted by C++ compilers fumbling toward solutions that would have been obvious in a better language (thousands of server-years per day where I work) is a legitimate ecological concern.

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

#24

Post by petr_tik »

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…

how often does it happen that your interns work on the hot path of your trading systems, which is where I assume you care the most about avoid syscalls like malloc?

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

#26

Post by pron »

AsyncAwait wrote: post #21
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…

> 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 situ…

> 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

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

#27

Post by voldacar »

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

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

#28

Post by dom96 »

pron wrote: post #2

I think that Zig's simplicity hides how revolutionary it is, both in design and in potential. It reminded me of my impression of Scheme when I first learned it over twenty years ago. You can learn the language in a day, but it takes a while to realize how exceptionally powerful it is. But it's not just its radical design that's interesting from an academic perspective; I also think that its practical goals align with…

> Other languages -- like Nim, D, C++ and Rust also have a feature similar to Zig's comptime or are gradually getting there -- but what Zig noticed was that this simple feature makes several other complex and/or potentially harmful features redundant.

I'm curious where this impression of Zig comes from, as this is precisely what Nim has set out to do: a small core extensible via metaprogramming. Are there features that Nim implements which go against this premise? if so, what are they? :)

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

#29

Post by kristoff_it »

andi999 wrote: post #14

What is the best way to start with zig, if you know C by heart? I had a look a while ago, but I feel I miss out how the concepts are to be used in practice.

If you want to be eased into the language, start by checking out https://ziglearn.org. Otherwise just take a look at the overview on the homepage of https://ziglang.org, then the docs.

After that you should already be in great shape and you can read the standard library for examples of useful patterns.

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

#30

Post by renaicirc »

pron wrote: post #22
tobz1000 wrote: post #17

Some of Zig's ideas fascinate me, both the great low-level concepts (e.g. arbitrary-sized ints), but much more than that, the high level concepts. Particularly great is Zig's handling of both macros and generic types, the answer to both of which seems to be: just evaluate them at compile-time with regular functions, no special DSL or extra syntax. Andrew mentions in the video a big drawback of this system - implicati…

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…

> You lose soundness, but we don't have sound guarantees for functional correctness, anyway

This sounds like "we can't guarantee the most important thing, so it's unclear whether it's useful to guarantee this other thing," but that's a bizarre statement, so am I misinterpreting?

Post reply on HN