00:27 <tjpalmer> Hey y'all. I have a question about zig compiler speed. Other than compile-time code execution, the grammar and language seem like it ought to be fast. And mostly it seems to be.

00:27 <tjpalmer> But I was wondering if there are any benchmarks or large code bases for quantifying the speed.

00:28 <tjpalmer> And I've seen the docs on debug, release-safe, and release-fast, but I'm curious about more specifics than that.

01:07 <andrewrk> tjpalmer, there is not a large codebase to quantify the speed yet

01:07 <andrewrk> what exists is not implemented yet plans to have the compiler handle object caching and compile speed optimizations

01:13 <andrewrk> tjpalmer, did you get my messages?

01:14 <tjpalmer> Got them from the log. I'm only sort of online right now. Thanks for the info!

01:15 <andrewrk> somewhere in 0.3.0 and 0.4.0 I'll do a proof of concept on compile/linking speed

01:16 <andrewrk> fundamentally, we have the power to compile very quickly. because we carefully make no guarantee about certain things, zig is free to split a compilation up into any number of .o files it wants to, add padding, cache intermediate values, etc

01:21 <tjpalmer> Glad to hear the plans. Compile speed is one of my top concerns in programming, so I was curious.

01:22 <tjpalmer> Mostly unrelated, if Jai ever comes out, do you see that as competition in Zig space?

03:26 <tjpalmer> I searched and found old discussions on Jai, by the way. No need to worry at the moment.

06:37 <andrewrk> tjpalmer, I do see Jai as (friendly) competition, but there are quite a few design decisions of Jai that are not harmonious with zig

06:40 <andrewrk> compared to zig, I would characterize Jai as less concerned with (debug) safety, less concerned with the open source community, more concerned with metaprogramming

06:42 <andrewrk> jai's compilation speed is inspiring. I plan to take a different approach to get there which 1. scales to millions of lines of code rather than jai's target of 50,000 lines, and 2. maintains integration with the LLVM toolchain

06:45 <GitHub89> [zig] andrewrk pushed 1 new commit to master: https://git.io/vN737

06:45 <GitHub89> zig/master 40ca39d Andrew Kelley: fix error message mentioning unreachable instead of noreturn

16:14 <GitHub150> [zig] andrewrk pushed 1 new commit to master: https://git.io/vN5L8

16:14 <GitHub150> zig/master 44f38b0 Andrew Kelley: fix assertion fail when using global var number literal...

16:48 <GitHub185> [zig] andrewrk pushed 1 new commit to master: https://git.io/vN5Op

16:48 <GitHub185> zig/master a795e4c Andrew Kelley: add some docs for reflection

20:53 <MajorLag_> New reflection docs make me curious, does 'type' contain other fields? Could it be used to do some interesting compile-time metaprogramming like, I don't know, automatically generating a compact on-wire version of a struct?

20:57 <andrewrk> I think it's planned to support that

20:58 <MajorLag_> Sweet. Though that particular example wouldn't work so well without some kind of annotation system to tell it which fields to ignore or treat specially I suppose.

20:58 <MajorLag_> Which is getting into Jai-level metaprogramming.

21:20 <andrewrk> I do think we should have some way to provide metadata for struct fields

21:21 <andrewrk> go has that ` ` thing, but in zig it would be some arbitrary comptime value

22:33 <jfo> hey is there a way to jump backwards in a for conditionally?

22:33 <jfo> like I'm looping over a "string" and if I see a particular characted I jump back to somewhere in particular

22:35 <jfo> I know I can do this with a while loop but was wondering if it's possible just in a for

22:37 <zesterer> Hello all. I'm new here. I discovered Zig about an hour ago. I've been in the market for a new language: I have a pretty good understanding of C++ & C and an amateur understanding of Rust. I tend to work on low-level stuff, but I've been frustrated by the lack of safety checks that C provides and the absurd complexity that C++ provides (I understand the language, but it's always difficult to forsee issues when programmi

22:38 <zesterer> ng with it).

22:38 <zesterer> What I've seen so far of Zig has me really impressed, but I have a few questions before I start seriously consider using it for my next project.

22:40 <zesterer> Firstly, how do you handle the whole dynamic-memory-management-with-dangling-pointers problem? C doesn't, C++ has ridiculous runtime features like std::shared_ptr, and Rust has a prohibitively strict syntax to evade the problem. I've not yet seen any example code of this kind in Zig. What does it have?

22:41 <zesterer> Secondly, how does Zig deal with the destruction of complex types? C (again) doesn't, C++ has destructors, and Rust has the Drop trait. What does Zig have?

22:42 <zesterer> I'd be really thankful for answers on these :-)

23:13 <MajorLag_> Zester: Zig is like C. There is no native memory management, and no constructors or destructors. There is defer.

23:18 <andrewrk> jfo, yeah there is, you make a while loop inside the for loop

23:18 <andrewrk> oh, you mean you want to decrement the index

23:19 <jfo> yes

23:19 <andrewrk> jfo, a for loop really is just sugar over var i: usize = 0; while (i < thing.len) : (i += 1) { const item = thing[i]; ... }

23:19 <andrewrk> so if the sugar is too restricting, unsugar it and use the while

23:20 <jfo> that's what I've been doing just wanted to see if there was another shorthand in for :)

23:20 <andrewrk> I think we won't have that, because part of the benefit of `for` is that you know the index never goes backwards

23:20 <andrewrk> when reading code

23:21 <andrewrk> zesterer, greetings

23:21 <andrewrk> we have defer and errdefer, and that's it

23:22 <andrewrk> there are proposals to have some kind of compiler-enforced handling of cleanup, but no proposal has been accepted yet

23:29 <zesterer> andrewrk, MajorLag_: Thanks for the response

23:31 <andrewrk> zesterer, there is still the danger of forgetting to clean up a resource, but correct code that handles all resource cleanup avoids nesting and is simple to reason about

23:32 <andrewrk> essentially every resource allocation will have either a defer or an errdefer after it, depending on if the resource should be unconditionally cleaned up, or cleaned up only if the function returns with an error

23:32 <andrewrk> s/function/scope/

23:33 <andrewrk> if you insert into the middle of a function code that can return an error, resource cleanup will continue to work correctly, you can't forget to update the cleanup code

23:34 <andrewrk> and spotting resource mismanagement is trivial. it looks like an "allocate" or "open" without a "defer" on the following line

23:48 <zesterer> andrewrk: Fair enough. I'm definitely interested by Zig, but I must use Rust instead for my next project. Thanks for clarifying!