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

151–160 of 210 posts

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

#151

Post by aw1621107 »

pron wrote: post #137
the_duke wrote: post #125

Earlier quoted context omitted.

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) i…

> but those guarantees come at a significant cost -- to language complexity and compilation time

Aren't Rust's compilation time woes more due to the amount of IR the front/middle-end give to LLVM? I was under the impression that the type system-related stuff isn't that expensive.

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

#152

Post by pron »

edflsafoiewq wrote: post #127
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…

Does zig have an answer to RAII yet?

RAII is not a question. Zig prefers explicitness, i.e. by looking at a subroutine you know exactly which code is called, its approach to releasing resource uses defer.

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

#153

Post by edflsafoiewq »

pron wrote: post #152
edflsafoiewq wrote: post #127

Earlier quoted context omitted.

Does zig have an answer to RAII yet?

RAII is not a question. Zig prefers explicitness, i.e. by looking at a subroutine you know exactly which code is called, its approach to releasing resource uses defer.

The question is how to do automatic resource management. There are no checks of any sort, runtime or not, to help you here (correct me if I'm wrong).

RAII is not precluded by explicitness, you could require all values that require cleanup to be syntactically marked in some way and it would still be RAII. defer also cannot handle resources whose lifetimes do not correspond to nested scopes (eg. the elements of an ArrayList) like RAII or a GC can.

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

#154

Post by rhodysurf »

dcolkitt wrote: post #53
petr_tik wrote: post #24

Earlier quoted context omitted.

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?

To be honest, I'd be a lot more worried about physics PhDs then I would interns. I've seen plenty of 20 year-old engineering students write solid low-latency code. I can't say the same thing about string theorists. It'd be pretty unusual for junior or non-technical people to write code in "core" components of the system. Things like datafeed parsers, order handlers, inventory management, safety checks, networking lib…

This is exactly my experience working on CFD software with hydrodynamics phds haha they don’t care about the “little” things and will allocate and copy shit everywhere

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

#155

Post by vips7L »

dnautics wrote: post #68
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…

It's pretty easy to use Zig as the low level for languages which can take a C FFI. Self-promotion: I wrote zigler which integrates zig as inline code in elixir.

I've been slowly replacing the C files of xv6 with some zig. It was surprisingly easy with the generated header files to use zig from within the C part.

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

#156

Post by gautamcgoel »

samatman wrote: post #122
nextaccountic wrote: post #115

Earlier quoted context omitted.

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.

I'm not 100% confident I follow, but this sounds like one of those backflips Rust programmers do to satisfy the borrow checker. As in, you wouldn't write the code this way if you didn't have to. You do get memory safety in return... but you can see where the desire for a more eloquent approach might arise.

For a moment I thought Sam Altman was spending his time reading random HN forums and commenting on the intricacies of Rust coding. Took me a minute to catch the missing "l" in your handle ;)

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

#157

Post by gautamcgoel »

HourglassFR wrote: post #59

I've stumbled upon the Zig language a while back and have been checking in regularly to follow its progress. Recently I took the time to write a very small program to get a feeling for it. My thoughts : - It's a very low level language. Having written mostly Python for the past few years, it is quite the contrast. I had to force myself to think in C to get the train going - Getting my head around the error handling t…

Can you elaborate a bit more about what your found lacking in Zig strings?

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

#158

Post by logicchains »

PaulDavisThe1st wrote: post #113
notacoward wrote: post #23

Earlier quoted context omitted.

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.

Frankly I find HN more of an impediment to rapid development than C++ compile times.

I know personally I'd spend a lot less time on HN if C++ compiled quickly enough that I didn't have time to context switch to something else while waiting for it to compile.

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

#159

Post by vvanders »

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…

Yeah, I've been using no_std for this use case and pretty happy with it.

If you want a full blown container you can use heapless, building a custom container is really straightforward and requires a minimal amount of unsafe.

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

#160

Post by littlestymaar »

pron wrote: post #135
littlestymaar wrote: post #133

Earlier quoted context omitted.

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

> 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

Their is no such things as unsafe and safe Zig. All Zig is unsafe, but you can add additional runtime checks (disabled by default in optimized builds) that will slow down your program when used. Using a specific allocator to detect UAF is something you may do in development, but almost surely never in production. And without it your code isn't memory-safe.

> Fuzzing a C program will not find all the undefined behaviour that fuzzing a Zig program can, for the reasons I mentioned.

Zig will have less UB than C, but there will still be lurking UB in your programs no matter how long you test it. Consider the following snippet (on mobile, so this may have stupid syntax errors):

  test "this is UB, but the test won't show it" {
    const allocator = std.heap.page_allocator;
    var buf = try allocator.alloc(u8, 10);
    ohNo(allocator, 42, buf);
    allocator.free(bar);
  }

  fn ohNo(allocator: *Allocator, foo: const u8, bar: *u8) void {
    if (foo == 1337) {
        // double free awaiting to happen in production
        allocator.free(bar);
    }
  }
If you never explicitly test the value “1337” during you debug session, you won't trigger the UB and you won't know it's here, then when you ship your optimized build in production, you'll ship a program with UB in it.
Post reply on HN