11 ms·

Zig 0.8.0 Release Notes

268 points by kristoff_it 5y ago

skybrian 5y ago
I’m wondering if Zig is useful for targeting microcontrollers? (For example the Raspberry Pi Pico.)
- daurnimator 5y ago
  Yes it is.
- txdv 5y ago
  here is a guy who wrote his keyboard firmware in zig https://kevinlynagh.com/rust-zig/ https://kevinlynagh.com/rust-zig/
kristoff_it 5y ago
Also, for those that are interested, we’re going to have a release party tomorrow live on Twitch. Andrew will demo some highlights from the release and answer some questions from the audience. https://twitter.com/zigshowtime/status/1399634302833471491?s=20 https://twitter.com/zigshowtime/status/1399634302833471491?s...
acrispino 5y ago
This was a rough release cycle for downstream users of LLVM. During testing of the release candidates, we found and reported 7 regressions from LLVM 11. However, despite having reproducible regressions reported as release blockers, the LLVM project tagged release 12.0.0. Not only were there open regressions at this time, but the 12.0.0 tag did not even tag the tip of the release/12.x branch - so there were fixes already committed into the release branch that did not make it into the tag. I don't follow LLVM development. Is this normal for the project?
- coldtea 5y ago
  >we found and reported 7 regressions from LLVM 11. However, despite having reproducible regressions reported as release blockers Well, this says that zig team reported those bugs as "release blockers". Doesn't mean the LLVM release team also considered them release blockers (or that it had too).
  - mkishi 5y ago
    Could you elaborate on when they wouldn't treat regressions as blockers? I'm not very familiar with LLVM and couldn't gather that from the "How To Release LLVM To The Public" docs [1]. [1] https://llvm.org/docs/HowToReleaseLLVM.html https://llvm.org/docs/HowToReleaseLLVM.html
    - coldtea 5y ago
      Well, e.g. they say: "Only critical bugs found during this testing phase will be fixed." - so e.g. not all regressions are necessarily release blockers. Besides, whatever the "process" says, isn't it ultimate up to the release manager?
- slimsag 5y ago
  Accidents happen, and LLVM is a really large complex project with tons of downstream users (like Zig and Rust) discovering issues not caught by LLVM's test suite / clang. It's definitely a real problem[0][1][2][3], I would argue LLVM needs a longer release-candidate cycle before a release is cut - to give downstream users more to pick up and report regressions, as well as LLVM contributors to fix them. A higher quality bar would be great. [0] https://twitter.com/andy_kelley/status/1365186310088974336 https://twitter.com/andy_kelley/status/1365186310088974336 [1] https://twitter.com/andy_kelley/status/1303046926430908416 https://twitter.com/andy_kelley/status/1303046926430908416 [2] https://www.reddit.com/r/rust/comments/gh3thc/llvm_10_has_performance_regressions_with_rust/ https://www.reddit.com/r/rust/comments/gh3thc/llvm_10_has_pe... [3] https://www.reddit.com/r/rust/comments/n5ne5i/regression_miscompilation_due_to_bug_in_mutable/ https://www.reddit.com/r/rust/comments/n5ne5i/regression_mis...
  - tialaramex 5y ago
    It's definitely a problem that LLVM has features which are in practice not really exercised by C++ (because the ISO C++ standard says something is Undefined Behaviour) and so clang doesn't need to use those features yet LLVM developers too often act as though only C++ matters. Rust spent a while with trivial crashes if you have an infinite loop. Here's how that happened as I understand it: From Rust's point of view infinite loops are well formed. Sure, your program never exits but that's what you told it to do, so it's your problem not Rust's. However in C++ that isn't a thing. In C++ an infinite loop is Undefined Behaviour. And so LLVM just didn't have working infinite loop code. If your C++ program has an infinite loop, too bad the ISO Standard says your program is wrong, clang is behaving as intended. Sure that's crazy but C++ programmers have a sort of Stockholm Syndrome. So LLVM had a bug, but because the most important customer of LLVM is clang, and clang didn't care about this hideous bug while its users had just become numbed to the consequences, the bug lived on for ages.
    - duped 5y ago
      If we're throwing stones at LLVM features that don't work let's toss one at noalias
    - 5y ago
- bla3 5y ago
  It's the first release by a new release manager as far as I can tell: https://www.phoronix.com/scan.php?page=news_item&px=Tom-Stellard-LLVM-RM https://www.phoronix.com/scan.php?page=news_item&px=Tom-Stel... So hopefully just temporary transition pain while the new manager learns the ropes.
  - pyler 5y ago
    Same failures https://lists.llvm.org/pipermail/llvm-dev/2021-June/150839.html https://lists.llvm.org/pipermail/llvm-dev/2021-June/150839.h... Quality really went down with that RH guy.. :/
slimsag 5y ago
I've been working with Zig almost 8h/day since Sept. of last year[0], and am super excited about the ideas it is bringing to low-level programming - even to C/C++/Rust. I hope folks outside of the Zig community give it a glance even if just for the ideas it brings around cross-compilation and being a nice out-of-the-box experience. Some of my favorite highlights from this release: > With the advent of the Self-Hosted Linker, Zig is now able to generate well-formed and codesigned binaries on arm64 macOS (aka the Apple Silicon). It is also able to cross-compile C, C++, and Zig code to an arm64 and x86_64 macOS. Additionally, arm64 nightly binaries of Zig are automatically generated by our Continuous Integration service, meaning both arm64 and x86_64 macOS are now Tier 1 targets. From what I know, with existing cross-compilation for C/C++/Rust, code-signed MacOS binaries are not possible. This new Zig linker makes it possible and works for C/C++/Rust as well[1]. > Finally, as a side experiment, Jakub added in Zig Build System integration with Darling (#8760), a translation layer of macOS syscalls to Linux, with the intention of being able to cross test MachO binaries and macOS specific tests directly on Linux simply by passing in an additional flag -Denable-darling to zig build test. This line of thinking - not only "how do I cross-compile", but "how do I test my cross-compiled code?" is super interesting to me. I hope it is explored further. Finally, it's just incredibly cool to see how quickly Zig is developing and how financially stable it is[2], supporting handfuls of core team members to work on Zig. I haven't seen any other language community achieve this, let alone without corporate backing. Truly beautiful. [0] https://devlog.hexops.com/2021/increasing-my-contribution-to-zig-to-200-a-month https://devlog.hexops.com/2021/increasing-my-contribution-to... [1] https://www.reddit.com/r/rust/comments/nii64t/zig_makes_rust_crosscompilation_just_work/ https://www.reddit.com/r/rust/comments/nii64t/zig_makes_rust... [2] https://github.com/sponsors/ziglang https://github.com/sponsors/ziglang
- lhorie 5y ago
  Yeah, what's really compelling to me is how much effort zig puts on "plumbing" work as opposed to tacking more and more language features. It speaks volumes that zig can provide toolchain-level benefits to other low level languages like Rust.
- bla3 5y ago
  > code-signed MacOS binaries are not possible As far as I know, this is possible with clang and the new mach-o lld port as well. While it's possible with clang/lld in C++, it looks like it is much easier with zig.
luxurytent 5y ago
I've been developing a CHIP-8 emulator as a means of learning Zig, it's been very fun! The community seems quite small and tight-knit, and with that, comes a lot of helpful individuals. Having never worked with a language that is particular about memory, Zig has felt like a nice balance. Dealing with the allocator is clear and being intentional about the bit-width of things like integers helps articulate what is expected, which can be important in an emulation project. The built-in WASM compilation seems like something I will explore with this project too. That part is a nice touch
Rusky 5y ago
The changes to the IR data structures in this release are really neat- whole trees and graphs fit in a small fixed number of flat arrays. This saves on allocations, saves on total memory usage, and makes them trivial to serialize because there are no pointers. I recently arrived at a similar design for manipulating NFAs as adjacency matrices, as a replacement for more pointer-y adjacency lists, by way of sparse matrix data structures. Rather than Zig's performance angle, I found that it made whole-graph operations much easier to implement and reuse. I've also seen similar approaches from array languages like APL, for example this project for running this kind of stuff on GPUs: https://github.com/Co-dfns/Co-dfns https://github.com/Co-dfns/Co-dfns And, I've seen it in Rust as a "workaround" for the borrow checker, where that framing tends to make it feel like cheating or settling, which IMO is unfortunate since when people arrive at it for other reasons it seems to have a lot of other benefits! There are probably more contexts I'm not familiar with- anyone have any good examples from domains they've worked in?
- gnuvince 5y ago
  > And, I've seen it in Rust as a "workaround" for the borrow checker, where that framing tends to make it feel like cheating or settling, which IMO is unfortunate since when people arrive at it for other reasons it seems to have a lot of other benefits! Great point! I've been using Rust for 4–5 years now and putting objects in Vecs and using integers as "pointers" felt a lot like cheating (i.e., "I'm doing the wrong™ thing!"), but every time I tried to "fix" things to use references my code ended up uglier, harder to understand, and sometimes slower. In time, I've learned that it's perfectly fine way to structure data. And as you point out, it makes it easier to work on a large structure structure itself rather than having to go through its individual components (e.g., you can manipulate all the nodes in a graph with a simple for loop rather than having to do a DFS/BFS traversal).
  - oconnor663 5y ago
    This is basically what an Entity Component System is, right? I always find myself linking back to this talk: https://youtu.be/aKLntZcp27M https://youtu.be/aKLntZcp27M
- 5y ago
smeenai 5y ago
I was curious about this bit from https://ziglang.org/download/0.8.0/release-notes.html#Self-Hosted-Linker https://ziglang.org/download/0.8.0/release-notes.html#Self-H..., since I work on the new LLD for Mach-O backend: > Additionally, it is doubtful that the new backend will allow for seamless cross-compilation to macOS since every macOS binary is required to be a PIE and link dynamically against libSystem dylib, which will require the lib's presence on the host for the lld to reference and link against. This is true, but it's a platform requirement, not a linker requirement. How does zig's linker get around this? Does it produce static binaries (LC_UNIXTHREAD instead of LC_MAIN)?
- kubkon 5y ago
  Hey smeenai! I am the author of the MachO linker in Zig. First of, I am closely following your work in LLVM and I am really delighted that someone of your aptitude took over the backend - I definitely intend to take it for a spin soon! As far as cross-linking is concerned, we do the same thing we do for macOS libc headers - we ship the definitions. You can think of it as effectively shipping a preprocessed version of libSystem.tbd with Zig. This is still early days though, so currently as a workaround for not having a functional yaml parser (so that `zig ld` can link against tbds), every unresolved proxy symbol is simply assumed to come from libSystem. This is of course not ideal since then unresolved symbols are flagged only at runtime rather than at link time. Anyhow, shipping preprocessed libSystem.tbd makes it possible to cross-compile valid PIE binaries (which is a strict requirement on Apple Silicon anyway). If you wanna discuss it more, feel free to DM me in Zig's Discord - I'm always game to discuss linkers!
ncmncm 5y ago
The energy in this project is amazing! The idea of including a C++ and a C compiler gratis is brilliant, and solves a big interoperability headache very elegantly. For my own purposes, IIUIC it is fatally flawed, lacking destructors, but as a raw C replacement it has legs. Compile-time execution and types as regular compile-time values makes it actually powerful.
- pjmlp 5y ago
  > The idea of including a C++ and a C compiler gratis is brilliant, and solves a big interoperability headache very elegantly. C++ did it first, having been born at same place as UNIX and C, all major C compiler vendors quickly added it into the box.
  - ncmncm 5y ago
    It would be better if a C or C++ header sufficed to declare things so they may be called directly from Zig, without need for matching declarations in Zig. Or, do they? For it to be useful, types would need to be imported, too. That would need destructor and overloading support. Which is doable.
    - pjmlp 5y ago
      Depends how much modern C and C++ Zig wants to implement in order to understand the types. Generics, lambdas, concepts, templates, exceptions, ....
      - ncmncm 5y ago
        If Zig doesn't have lambdas yet, that is a clear omission. It would be wise to reserve syntax for it early.
    - somethingor 5y ago
      That is how Zig works with C code: - https://ziglang.org/learn/overview/#integration-with-c-libraries-without-ffibindings https://ziglang.org/learn/overview/#integration-with-c-libra... - https://ziglang.org/documentation/master/#Import-from-C-Header-File https://ziglang.org/documentation/master/#Import-from-C-Head...
rajandatta 5y ago
Congratulations to the Zig team. Zig's a very interesting project for language mavens. A question - what does the Zig ecosystem look like? Are there strong products and parsers, services, actor models, interfacing with Middleware written in Zig? Or is the theme - drop to C based interfaces to those products? What's the zen of Zig say? What are some notable wide use applications, solutions written in Zig?
- defen 5y ago
  It's still pretty early for a significant ecosystem to exist, but in general interfacing with C (or C++ `extern "C"` stuff) in either direction - calling C from Zig or Zig from C - is extremely simple. You can tell Zig functions / structs to use the C ABI with the `extern` keyword, and you can use C headers (structs, prototypes, enums, #define's, etc) via `@cImport` or `translate-c`
losvedir 5y ago
This is an astounding amount of work for such a small project. Looks like the 0.7.0 release was about a year and a half ago. I've been sponsoring for a couple months now. I love the passion here and want to support a smart, dedicated guy leading a project in the open. I'm curious just to see what happens and where the project goes. Watching Andy brainstorm, experiment, and triage in GitHub issues has been worth the $5/mo, in project management tips alone! One of these days I'll have to actually give Zig a try...
- AndyKelley 5y ago
  0.7.0 was 7 months ago. Thanks for your support :)
  - vanderZwan 5y ago
    Which in Covid years is both 1.5 years ago and last week at the same time
Jarred 5y ago
I’ve been using Zig for a new JavaScript build tool and I really like it. It’s great for writing performance-critical code. It took me about two weeks to feel comfortable & productive in it.
- heldrida 5y ago
  I've been following your Twitter since! You started with only two weeks of experience, that's incredible!!! I'm literally smiling!
- txdv 5y ago
  Can you link to the github repo?
- ksec 5y ago
  Any timeline when that would be released to the public? Cant wait to see that insanely fast build time.
pabs3 5y ago
Does anyone know if Zig is bootstrappable in the "Bootstrappable Builds" sense? i.e. You can take the source code without any pre-generated binaries or code and build Zig solely using external tools. https://bootstrappable.org/ https://bootstrappable.org/ https://bootstrapping.miraheze.org/ https://bootstrapping.miraheze.org/
- wavesquid 5y ago
  Yes. There is a repo containing exactly that: https://github.com/ziglang/zig-bootstrap https://github.com/ziglang/zig-bootstrap
geodel 5y ago
As the military aphorism go "Amateurs talk strategy. Professionals talk logistics." I like that Zig seems to talk about compiler/linker logistics in great details as opposed to just endless list of new language features and APIs that so many languages do.
- vanderZwan 5y ago
  (tangent) Huh, I wonder how well that ahorism maps to Linus Torvalds' code/data structures quote: > git actually has a simple design, with stable and reasonably well-documented data structures. In fact, I'm a huge proponent of designing your code around the data, rather than the other way around, and I think it's one of the reasons git has been fairly successful […] I will, in fact, claim that the difference between a bad programmer and a good one is whether he considers his code or his data structures more important.
  - jorangreef 5y ago
    I love that quote from Linus. In fact, we had it in mind when we designed TigerBeetle [1][2], a financial accounting database to do a million financial transactions a second. We started with the data structures, made sure that these were one or two cache lines to reduce cache misses and perfectly aligned to eliminate false sharing, and then we added built-in accounting primitives to move the code to the data, instead of the data back and forth across the network to the code, which is how these kinds of balance tracking systems that we were working with before were typically implemented. The result is much simpler, a perfect replicated state machine, and also much safer, because the business logic and data are executed within the state machine, protected by the distributed consensus protocol (Viewstamped Replication Revisited by Liskov and Cowling), rather than a mess of SQL transactions spanning multiple distributed systems, all with different clocks. [1] https://github.com/coilhq/tigerbeetle https://github.com/coilhq/tigerbeetle [2] Guess what language we wrote it in? And this is making more and more sense, like a secret weapon. The community is amazing, deeply talented, with great taste, and at the vanguard of where things are going for these kinds of systems.

268 points by kristoff_it 5y ago

skybrian 5y ago

I’m wondering if Zig is useful for targeting microcontrollers? (For example the Raspberry Pi Pico.)

daurnimator 5y ago
Yes it is.
txdv 5y ago
here is a guy who wrote his keyboard firmware in zig https://kevinlynagh.com/rust-zig/ https://kevinlynagh.com/rust-zig/

kristoff_it 5y ago

Also, for those that are interested, we’re going to have a release party tomorrow live on Twitch. Andrew will demo some highlights from the release and answer some questions from the audience. https://twitter.com/zigshowtime/status/1399634302833471491?s=20 https://twitter.com/zigshowtime/status/1399634302833471491?s...

acrispino 5y ago

This was a rough release cycle for downstream users of LLVM. During testing of the release candidates, we found and reported 7 regressions from LLVM 11. However, despite having reproducible regressions reported as release blockers, the LLVM project tagged release 12.0.0. Not only were there open regressions at this time, but the 12.0.0 tag did not even tag the tip of the release/12.x branch - so there were fixes already committed into the release branch that did not make it into the tag. I don't follow LLVM development. Is this normal for the project?

coldtea 5y ago
>we found and reported 7 regressions from LLVM 11. However, despite having reproducible regressions reported as release blockers Well, this says that zig team reported those bugs as "release blockers". Doesn't mean the LLVM release team also considered them release blockers (or that it had too).
- mkishi 5y ago
  Could you elaborate on when they wouldn't treat regressions as blockers? I'm not very familiar with LLVM and couldn't gather that from the "How To Release LLVM To The Public" docs [1]. [1] https://llvm.org/docs/HowToReleaseLLVM.html https://llvm.org/docs/HowToReleaseLLVM.html
  - coldtea 5y ago
    Well, e.g. they say: "Only critical bugs found during this testing phase will be fixed." - so e.g. not all regressions are necessarily release blockers. Besides, whatever the "process" says, isn't it ultimate up to the release manager?
slimsag 5y ago
Accidents happen, and LLVM is a really large complex project with tons of downstream users (like Zig and Rust) discovering issues not caught by LLVM's test suite / clang. It's definitely a real problem[0][1][2][3], I would argue LLVM needs a longer release-candidate cycle before a release is cut - to give downstream users more to pick up and report regressions, as well as LLVM contributors to fix them. A higher quality bar would be great. [0] https://twitter.com/andy_kelley/status/1365186310088974336 https://twitter.com/andy_kelley/status/1365186310088974336 [1] https://twitter.com/andy_kelley/status/1303046926430908416 https://twitter.com/andy_kelley/status/1303046926430908416 [2] https://www.reddit.com/r/rust/comments/gh3thc/llvm_10_has_performance_regressions_with_rust/ https://www.reddit.com/r/rust/comments/gh3thc/llvm_10_has_pe... [3] https://www.reddit.com/r/rust/comments/n5ne5i/regression_miscompilation_due_to_bug_in_mutable/ https://www.reddit.com/r/rust/comments/n5ne5i/regression_mis...
- tialaramex 5y ago
  It's definitely a problem that LLVM has features which are in practice not really exercised by C++ (because the ISO C++ standard says something is Undefined Behaviour) and so clang doesn't need to use those features yet LLVM developers too often act as though only C++ matters. Rust spent a while with trivial crashes if you have an infinite loop. Here's how that happened as I understand it: From Rust's point of view infinite loops are well formed. Sure, your program never exits but that's what you told it to do, so it's your problem not Rust's. However in C++ that isn't a thing. In C++ an infinite loop is Undefined Behaviour. And so LLVM just didn't have working infinite loop code. If your C++ program has an infinite loop, too bad the ISO Standard says your program is wrong, clang is behaving as intended. Sure that's crazy but C++ programmers have a sort of Stockholm Syndrome. So LLVM had a bug, but because the most important customer of LLVM is clang, and clang didn't care about this hideous bug while its users had just become numbed to the consequences, the bug lived on for ages.
  - duped 5y ago
    If we're throwing stones at LLVM features that don't work let's toss one at noalias
  - 5y ago
bla3 5y ago
It's the first release by a new release manager as far as I can tell: https://www.phoronix.com/scan.php?page=news_item&px=Tom-Stellard-LLVM-RM https://www.phoronix.com/scan.php?page=news_item&px=Tom-Stel... So hopefully just temporary transition pain while the new manager learns the ropes.
- pyler 5y ago
  Same failures https://lists.llvm.org/pipermail/llvm-dev/2021-June/150839.html https://lists.llvm.org/pipermail/llvm-dev/2021-June/150839.h... Quality really went down with that RH guy.. :/

slimsag 5y ago

I've been working with Zig almost 8h/day since Sept. of last year[0], and am super excited about the ideas it is bringing to low-level programming - even to C/C++/Rust. I hope folks outside of the Zig community give it a glance even if just for the ideas it brings around cross-compilation and being a nice out-of-the-box experience. Some of my favorite highlights from this release: > With the advent of the Self-Hosted Linker, Zig is now able to generate well-formed and codesigned binaries on arm64 macOS (aka the Apple Silicon). It is also able to cross-compile C, C++, and Zig code to an arm64 and x86_64 macOS. Additionally, arm64 nightly binaries of Zig are automatically generated by our Continuous Integration service, meaning both arm64 and x86_64 macOS are now Tier 1 targets. From what I know, with existing cross-compilation for C/C++/Rust, code-signed MacOS binaries are not possible. This new Zig linker makes it possible and works for C/C++/Rust as well[1]. > Finally, as a side experiment, Jakub added in Zig Build System integration with Darling (#8760), a translation layer of macOS syscalls to Linux, with the intention of being able to cross test MachO binaries and macOS specific tests directly on Linux simply by passing in an additional flag -Denable-darling to zig build test. This line of thinking - not only "how do I cross-compile", but "how do I test my cross-compiled code?" is super interesting to me. I hope it is explored further. Finally, it's just incredibly cool to see how quickly Zig is developing and how financially stable it is[2], supporting handfuls of core team members to work on Zig. I haven't seen any other language community achieve this, let alone without corporate backing. Truly beautiful. [0] https://devlog.hexops.com/2021/increasing-my-contribution-to-zig-to-200-a-month https://devlog.hexops.com/2021/increasing-my-contribution-to... [1] https://www.reddit.com/r/rust/comments/nii64t/zig_makes_rust_crosscompilation_just_work/ https://www.reddit.com/r/rust/comments/nii64t/zig_makes_rust... [2] https://github.com/sponsors/ziglang https://github.com/sponsors/ziglang

lhorie 5y ago
Yeah, what's really compelling to me is how much effort zig puts on "plumbing" work as opposed to tacking more and more language features. It speaks volumes that zig can provide toolchain-level benefits to other low level languages like Rust.
bla3 5y ago
> code-signed MacOS binaries are not possible As far as I know, this is possible with clang and the new mach-o lld port as well. While it's possible with clang/lld in C++, it looks like it is much easier with zig.

luxurytent 5y ago

I've been developing a CHIP-8 emulator as a means of learning Zig, it's been very fun! The community seems quite small and tight-knit, and with that, comes a lot of helpful individuals. Having never worked with a language that is particular about memory, Zig has felt like a nice balance. Dealing with the allocator is clear and being intentional about the bit-width of things like integers helps articulate what is expected, which can be important in an emulation project. The built-in WASM compilation seems like something I will explore with this project too. That part is a nice touch

Rusky 5y ago

The changes to the IR data structures in this release are really neat- whole trees and graphs fit in a small fixed number of flat arrays. This saves on allocations, saves on total memory usage, and makes them trivial to serialize because there are no pointers. I recently arrived at a similar design for manipulating NFAs as adjacency matrices, as a replacement for more pointer-y adjacency lists, by way of sparse matrix data structures. Rather than Zig's performance angle, I found that it made whole-graph operations much easier to implement and reuse. I've also seen similar approaches from array languages like APL, for example this project for running this kind of stuff on GPUs: https://github.com/Co-dfns/Co-dfns https://github.com/Co-dfns/Co-dfns And, I've seen it in Rust as a "workaround" for the borrow checker, where that framing tends to make it feel like cheating or settling, which IMO is unfortunate since when people arrive at it for other reasons it seems to have a lot of other benefits! There are probably more contexts I'm not familiar with- anyone have any good examples from domains they've worked in?

gnuvince 5y ago
> And, I've seen it in Rust as a "workaround" for the borrow checker, where that framing tends to make it feel like cheating or settling, which IMO is unfortunate since when people arrive at it for other reasons it seems to have a lot of other benefits! Great point! I've been using Rust for 4–5 years now and putting objects in Vecs and using integers as "pointers" felt a lot like cheating (i.e., "I'm doing the wrong™ thing!"), but every time I tried to "fix" things to use references my code ended up uglier, harder to understand, and sometimes slower. In time, I've learned that it's perfectly fine way to structure data. And as you point out, it makes it easier to work on a large structure structure itself rather than having to go through its individual components (e.g., you can manipulate all the nodes in a graph with a simple for loop rather than having to do a DFS/BFS traversal).
- oconnor663 5y ago
  This is basically what an Entity Component System is, right? I always find myself linking back to this talk: https://youtu.be/aKLntZcp27M https://youtu.be/aKLntZcp27M
5y ago

smeenai 5y ago

I was curious about this bit from https://ziglang.org/download/0.8.0/release-notes.html#Self-Hosted-Linker https://ziglang.org/download/0.8.0/release-notes.html#Self-H..., since I work on the new LLD for Mach-O backend: > Additionally, it is doubtful that the new backend will allow for seamless cross-compilation to macOS since every macOS binary is required to be a PIE and link dynamically against libSystem dylib, which will require the lib's presence on the host for the lld to reference and link against. This is true, but it's a platform requirement, not a linker requirement. How does zig's linker get around this? Does it produce static binaries (LC_UNIXTHREAD instead of LC_MAIN)?

kubkon 5y ago
Hey smeenai! I am the author of the MachO linker in Zig. First of, I am closely following your work in LLVM and I am really delighted that someone of your aptitude took over the backend - I definitely intend to take it for a spin soon! As far as cross-linking is concerned, we do the same thing we do for macOS libc headers - we ship the definitions. You can think of it as effectively shipping a preprocessed version of libSystem.tbd with Zig. This is still early days though, so currently as a workaround for not having a functional yaml parser (so that `zig ld` can link against tbds), every unresolved proxy symbol is simply assumed to come from libSystem. This is of course not ideal since then unresolved symbols are flagged only at runtime rather than at link time. Anyhow, shipping preprocessed libSystem.tbd makes it possible to cross-compile valid PIE binaries (which is a strict requirement on Apple Silicon anyway). If you wanna discuss it more, feel free to DM me in Zig's Discord - I'm always game to discuss linkers!

ncmncm 5y ago

The energy in this project is amazing! The idea of including a C++ and a C compiler gratis is brilliant, and solves a big interoperability headache very elegantly. For my own purposes, IIUIC it is fatally flawed, lacking destructors, but as a raw C replacement it has legs. Compile-time execution and types as regular compile-time values makes it actually powerful.

pjmlp 5y ago
> The idea of including a C++ and a C compiler gratis is brilliant, and solves a big interoperability headache very elegantly. C++ did it first, having been born at same place as UNIX and C, all major C compiler vendors quickly added it into the box.
- ncmncm 5y ago
  It would be better if a C or C++ header sufficed to declare things so they may be called directly from Zig, without need for matching declarations in Zig. Or, do they? For it to be useful, types would need to be imported, too. That would need destructor and overloading support. Which is doable.
  - pjmlp 5y ago
    Depends how much modern C and C++ Zig wants to implement in order to understand the types. Generics, lambdas, concepts, templates, exceptions, ....
    - ncmncm 5y ago
      If Zig doesn't have lambdas yet, that is a clear omission. It would be wise to reserve syntax for it early.
  - somethingor 5y ago
    That is how Zig works with C code: - https://ziglang.org/learn/overview/#integration-with-c-libraries-without-ffibindings https://ziglang.org/learn/overview/#integration-with-c-libra... - https://ziglang.org/documentation/master/#Import-from-C-Header-File https://ziglang.org/documentation/master/#Import-from-C-Head...

rajandatta 5y ago

Congratulations to the Zig team. Zig's a very interesting project for language mavens. A question - what does the Zig ecosystem look like? Are there strong products and parsers, services, actor models, interfacing with Middleware written in Zig? Or is the theme - drop to C based interfaces to those products? What's the zen of Zig say? What are some notable wide use applications, solutions written in Zig?

defen 5y ago
It's still pretty early for a significant ecosystem to exist, but in general interfacing with C (or C++ `extern "C"` stuff) in either direction - calling C from Zig or Zig from C - is extremely simple. You can tell Zig functions / structs to use the C ABI with the `extern` keyword, and you can use C headers (structs, prototypes, enums, #define's, etc) via `@cImport` or `translate-c`

losvedir 5y ago

This is an astounding amount of work for such a small project. Looks like the 0.7.0 release was about a year and a half ago. I've been sponsoring for a couple months now. I love the passion here and want to support a smart, dedicated guy leading a project in the open. I'm curious just to see what happens and where the project goes. Watching Andy brainstorm, experiment, and triage in GitHub issues has been worth the $5/mo, in project management tips alone! One of these days I'll have to actually give Zig a try...

AndyKelley 5y ago
0.7.0 was 7 months ago. Thanks for your support :)
- vanderZwan 5y ago
  Which in Covid years is both 1.5 years ago and last week at the same time

Jarred 5y ago

I’ve been using Zig for a new JavaScript build tool and I really like it. It’s great for writing performance-critical code. It took me about two weeks to feel comfortable & productive in it.

heldrida 5y ago
I've been following your Twitter since! You started with only two weeks of experience, that's incredible!!! I'm literally smiling!
txdv 5y ago
Can you link to the github repo?
ksec 5y ago
Any timeline when that would be released to the public? Cant wait to see that insanely fast build time.

pabs3 5y ago

Does anyone know if Zig is bootstrappable in the "Bootstrappable Builds" sense? i.e. You can take the source code without any pre-generated binaries or code and build Zig solely using external tools. https://bootstrappable.org/ https://bootstrappable.org/ https://bootstrapping.miraheze.org/ https://bootstrapping.miraheze.org/

wavesquid 5y ago
Yes. There is a repo containing exactly that: https://github.com/ziglang/zig-bootstrap https://github.com/ziglang/zig-bootstrap

geodel 5y ago

As the military aphorism go "Amateurs talk strategy. Professionals talk logistics." I like that Zig seems to talk about compiler/linker logistics in great details as opposed to just endless list of new language features and APIs that so many languages do.

vanderZwan 5y ago
(tangent) Huh, I wonder how well that ahorism maps to Linus Torvalds' code/data structures quote: > git actually has a simple design, with stable and reasonably well-documented data structures. In fact, I'm a huge proponent of designing your code around the data, rather than the other way around, and I think it's one of the reasons git has been fairly successful […] I will, in fact, claim that the difference between a bad programmer and a good one is whether he considers his code or his data structures more important.
- jorangreef 5y ago
  I love that quote from Linus. In fact, we had it in mind when we designed TigerBeetle [1][2], a financial accounting database to do a million financial transactions a second. We started with the data structures, made sure that these were one or two cache lines to reduce cache misses and perfectly aligned to eliminate false sharing, and then we added built-in accounting primitives to move the code to the data, instead of the data back and forth across the network to the code, which is how these kinds of balance tracking systems that we were working with before were typically implemented. The result is much simpler, a perfect replicated state machine, and also much safer, because the business logic and data are executed within the state machine, protected by the distributed consensus protocol (Viewstamped Replication Revisited by Liskov and Cowling), rather than a mess of SQL transactions spanning multiple distributed systems, all with different clocks. [1] https://github.com/coilhq/tigerbeetle https://github.com/coilhq/tigerbeetle [2] Guess what language we wrote it in? And this is making more and more sense, like a secret weapon. The community is amazing, deeply talented, with great taste, and at the vanguard of where things are going for these kinds of systems.