Live data from Hacker News

Interview with Zig language creator Andrew Kelley [video]

youtube.com

81–90 of 210 posts

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

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

> What a truly inspiring language It's indeed an inspiring language, and rust is taking inspiration from it already: https://github.com/jswrenn/project-safe-transmute/blob/rfc/r... > lack of generics I can't wait before Zig2 comes and eventually adds generics…

Looks like comptime is what they already have instead:

https://ziglang.org/documentation/master/#Introducing-the-Co...

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

#82
post #75

Earlier quoted context omitted.

> full memory safety enforced through runtime checks [disabled in production] Which means you cannot guaranty your program doesn't exhibit memory unsafely unless you stumble upon it during testing. Yes there are fewer footguns in Zig[1] than in C (which is the opposite of C++), but dangling pointer dereferences, double free and race conditions will still be lurking in any reasonably-sized codebase. Calling it “memory…

> Which means you cannot guaranty your program doesn't exhibit memory unsafely unless you stumble upon it during testing. Right, if you disable those checks. > Calling it “memory-safe”, is dishonest. The language is (or will be) memory safe, at least its safe parts -- C/C++ aren't. True, that safety can be disabled selectively. Yes, there can then be undefined behaviour if you disable that safety, but so can Rust whe…

> The language is (or will be) memory safe.

We've been going full cicle here, so I'm not interested in spending more time in this conversation.

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

#83

Earlier quoted context omitted.

To 'master' C is actually realizing C itself is not as simple as it looks from its syntax. It's an old language and the implementations are by no means straightforward. I'm by no means a C master but I have worked with people who are, and they know nuances of the language and the way it compiles down to various platforms in ways that shame me. But in general I have gone for for generalist not specialist in my career.

Well yes, but in the end all languages have this sort of fractal nature. But there is diminishing value in how deep you want to go into the rabbit hole. Of course there's always more to learn, but with C you're fairly quickly leaving the language and move into the layers of compiler- and hardware-trivia (good to know nonetheless, but often not really relevant for being productive in C) where in other higher-level lan…

C exposes a lot of things, and also hides a lot of things about the underlying system that can get confusing. What's an "int"? Or a "long" You need to know for your platform what the bit width is on your platform, because it's not explicit in the name, and the language is willing to do a bunch of implicit stuff behind the scenes with only a warning or two. Should you really be using 'char'? Is yours a legit use of it or did you mean uint8_t? Other high level languages generally tend to have more sensible default patterns for these things, C ... it gives you all kinds of ammo to shoot yourself with.

It's not as big of a problem these days with things becoming less heterogeneous; almost everything is little endian now, much of it 64-bit but at least 32-bit, and we can kind of rely on POSIX being there most of the time. Most new code uses stdint.h and is explicit about word lengths by using int32_t, etc. and follows good conventions there.

But venture off the beaten path into odd microcontrollers or into retro machines or port older code or whatever ... and there's glass hidden in the grass all over.

C also exposes a model of the machine that looks low level but behind the scenes a modern processor does all sorts of branch prediction and pipelining and so on that can blow up your assumptions.

What looks like optimized clever C code can actually end up running really slow on a modern machine, and vice versa.

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

#84

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…

D uses a garbage collector by default, but it has a @nogc annotation to mark blocks of code that get statically verified not to allocate through the garbage collector.

Is there any way to mark "this code does not call malloc"? Or maybe more generally, "this code does not use anything from libc"?

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

#85
post #72
post #61

Earlier quoted context omitted.

No, this is full memory safety enforced through runtime checks. ASAN does not give you that. Zig has only arrays and slices with known sizes and no pointer arithmetic (unless you explicitly appeal to unsafe operations).

I thought after Intel MPX we can all agree "memory safety" in modern languages is more about temporal stuff (i.e. use-after-free, etc) than bounds check, but maybe I'm wrong. How does those runtime checks kill UAF?

> 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

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

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

> What a truly inspiring language It's indeed an inspiring language, and rust is taking inspiration from it already: https://github.com/jswrenn/project-safe-transmute/blob/rfc/r... > lack of generics I can't wait before Zig2 comes and eventually adds generics…

In Zig types are values (same as any other value.) This lets you do generics without the need for any special syntax; you can simply pass types as parameters and return types.

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

#87
post #77

Earlier quoted context omitted.

> What a truly inspiring language It's indeed an inspiring language, and rust is taking inspiration from it already: https://github.com/jswrenn/project-safe-transmute/blob/rfc/r... > lack of generics I can't wait before Zig2 comes and eventually adds generics…

> 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 an instance of that single construct.

This has advantages (only one feature to know), but it also has a big drawback: the lack of orthogonality. C is also simple, for instance it has no concept of errors (only return values) or arrays (only pointers), but most people won't consider this a good idea (and Zig didn't follow C on either of those two design points)

Zig is cool, but I hoped the “generics are too complex of a feature” meme would die now that Go is getting generics, and I'd be really sad to see come back…

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

#88
post #25

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

The first rule of C is that no one masters C, but you could try anyway and still have time to master Zig in a matter of weeks, which is a rounding error. Given that both offer a C compatible ABI, what would serve your projects better?

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

#89

Earlier quoted context omitted.

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…

A concrete example is std::stable_sort. As far as I'm aware there's no way to pass it a custom allocator/buffer to avoid it allocating memory.

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

#90
post #88
post #25

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

The first rule of C is that no one masters C, but you could try anyway and still have time to master Zig in a matter of weeks, which is a rounding error. Given that both offer a C compatible ABI, what would serve your projects better?

I can't help but feel like in our industry C is successful (vs its 80s competition of Pascal/Modula-2, or Ada etc.) partially because of some of the same reasons that Git is successful now. Yes, it is powerful and flexible; but also in some ways unnecessarily arcane and 'dangerous' and _this gives the user a feeling of cleverness_ that is seductive to software engineers.

Put another way: Most of us enjoy the mental stimulation of programming, and we enjoy the mental challenges (in general). C makes us feel clever. Witness the "obfuscated C programming contest" etc.

Same thing that has led to nonsense 'brain teaser' whiteboard-algorithm tests at job interviews. IMHO it's in many cases for the benefit of the interviewer's ego, not the company or the interviewee ("gotcha! no job for you!").

Post reply on HN