31–40 of 115 posts
Very exciting. Are there plans to maintain the bootstrap path over the longer term? It always makes me sad when I hear about compilers which must bootstrap from magic binary blobs.
I hope so, but it seems like even if they didn't maintain it you could build today's stage1 using LLVM 14 and then work from the resulting binary instead of a binary you downloaded from online.
Earlier quoted context omitted.
> having better debug tooling What debug tooling are you referring to? It seems like people just use lldb to debug zig programs? I'm honestly interested, and searching doesn't turn up good tools as far as I can tell.
Maybe the runtime safety in debug builds? Like for out of bounds, int overflows, etc. In my zig projects those checks have saved me from using a debugger or valgrind in many cases.
Earlier quoted context omitted.
Is there any IDE support? Any debugger?
I found this IntelliJ IDEA plugin, the list of features looks pretty good already: https://plugins.jetbrains.com/plugin/10560-zig
Earlier quoted context omitted.
I believe the goal is to replace the C++ with a C bootstrap that is initially auto generated from the zig code by zig but manually cleaned up and maintained to match
Starting from auto-generated code isn't considered a proper bootstrap process by the Bootstrappable Builds project. You need to be able to start without any binaries or auto-generated code from the project itself. Usually that would mean starting with a basic implementation in another language, but starting with an older version of the same project that was written in another language and then going through several o…
Is there a reason we should weigh the Bootstrappable Builds project's opinion highly here?
There's nothing on their benefits page that is subverted by an auto-generated compiler that's hand maintained.
Actually, there's no mention of auto-generated code in their best-practices section. Do you have a link to where they even say this?
Earlier quoted context omitted.
I believe the goal is to replace the C++ with a C bootstrap that is initially auto generated from the zig code by zig but manually cleaned up and maintained to match
Starting from auto-generated code isn't considered a proper bootstrap process by the Bootstrappable Builds project. You need to be able to start without any binaries or auto-generated code from the project itself. Usually that would mean starting with a basic implementation in another language, but starting with an older version of the same project that was written in another language and then going through several o…
To clarify what this means, since things can get confusing with subtle differences in wordings: * stage1 is when zig is built from C++ code[1] (the "bootstrap" compiler) using system C/C++ compiler toolchain. * stage2 is when zig is built from Zig code[2] using stage1. * stage3 is when zig is rebuilt from the same Zig code[2] using stage2. Before today, zig would give you stage1 by default, and you could opt in to st…
I think elaborating on this could make for a very interesting article. :-)
(I have a guess already at one item, which is MultiArrayList, something that kind of blew my mind when I first learned about it, and is in my opinion a very impressive testament to both the power and ease of use of Zig's approach to compile-time computation.)
Very exciting. Are there plans to maintain the bootstrap path over the longer term? It always makes me sad when I hear about compilers which must bootstrap from magic binary blobs.
Earlier quoted context omitted.
Maybe the runtime safety in debug builds? Like for out of bounds, int overflows, etc. In my zig projects those checks have saved me from using a debugger or valgrind in many cases.
I guess I don't call runtime safety features "debug tooling"? But maybe that's the disconnect here
Very exciting. Are there plans to maintain the bootstrap path over the longer term? It always makes me sad when I hear about compilers which must bootstrap from magic binary blobs.
C++ stage1 compiler is a magic binary blob :)