Live data from Hacker News

Interview with Zig language creator Andrew Kelley [video]

youtube.com

31–40 of 210 posts

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

#31
post #28
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 th…

[deleted]

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

#32
post #3

I hope that we're not stuck writing piles of low-level code for all eternity. We don't need more than a few pages of each low-level language, and while I do really like Zig's qualities compared to C, I'd still like to minimize the amount of Zig or C total that has to be written. I think that our community's equivalent of "where's my flying car?" is "where's my higher-level language?"

There are situations where precise control over what the machine is doing is very important and a few of the problems that we experience in high-level contexts are caused by the inadequacy of our lower level tools.

Give it a few years and everybody is going to benefit from better implemented "lower-level" applications, thanks to Zig and other languages attempting to do the same.

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

#33
post #22

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…

That is the same approach used in many C++ projects

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

#34
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 is the same approach used in many C++ projects

Then I guess the obvious question is: has it worked well for those projects?

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

#35

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?

Nit pick: On modern systems malloc isn't a syscall, it's implemented in userspace. (Sorry, I couldn't help it)

That's not to say you're safe to call other syscalls, many of them either require memory allocations in-kernel (see ENOMEM) or can block indefinitely.

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

#36
post #28
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 th…

> Are there features that Nim implements which go against this premise? if so, what are they? :)

Nim has generics (plus concepts), templates, and macros. Zig has just comptime, through which it achieves all those goals (minus some macro capabilities that it deems harmful anyway) with just one, very simple, cohesive construct. You could argue on whether you like this or not, but you can't argue that Zig's approach isn't fundamentally more minimal. Zig is a language you can reasonably fully learn in one day; I don't think you could say the same about Nim.

---

Also, note another remarkable feature. One could define a language called Zig' with the following properties:

1. Every well-formed Zig program is a well-formed Zig' program (i.e. Zig' accepts all Zig programs, potentially more).

2. Every Zig program has the same semantics as the identical program when interpreted in Zig'.

This means that to analyse the semantics of a Zig program you can pretend it's a Zig' program; in fact, you don't need to create an interpreter for Zig', you can just pretend it exists. Why would you want to do that? Because Zig' is simpler. How? Here's the kicker: Zig' ignores comptime completely. It is a very simple, optionally-typed, dynamic language with reflection.

In other words, to analyse the semantics of a Zig program you can forget about comptime and pretend it can do everything at runtime (and treat comptime as a pure semantics-preserving optimisation).

This is not true for languages with macros, as they are not "erasable".

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

#37
post #25

Zig is appealing to me, but I wonder whether time spent mastering Zig would be better spent mastering C.

Why not both? Zig and C are both very simple languages, and there's not much to "master" TBH (at least not many language-specific things, so what you learn mostly transfers to other programming languages as well).

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

#38
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…

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

It means that there's a complex tradeoff between making sound guarantees and providing correctness in other ways, a tradeoff that all languages make anyway, each finding its own preferred sweet spot, and that we don't know if, say, Rust's sweet spot yields better correctness than Zig's.

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

#39

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

Can you explain how this is a problem in modern C++? I was under the impression that all the STL containers (string, vector, list, map, etc.) worked the same and have an allocator parameter. Are there other areas where these are missing? Or is the issue that STL implementations almost always default to an allocator that uses malloc? I'm not trying to dog on Zig here (it's a nice little language) but this just doesn't seem to be something that only Zig can do.

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

#40
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 is the same approach used in many C++ projects

But to do that you can only use a subset of C++ (e.g. you can't use arrays nor pointer arithmetic). This works for all of Zig, except for some very specific, clearly marked, "unsafe" operations.
Post reply on HN