43 Likes
really cool conference, makes it more personal to see everyone involved closely, and surprisingly optimistic about the 1.0 roadmap, given what they already achieved and what they list as “requirements” it seems closer than I thought, in my mind Zig would probably get 1.0 further than 2030, but it seems like it might happen sooner, the incremental compilation is already very much working, the language specification is being written, the aarch64 backend if I remember is pretty advanced, the dependency on LLVM is thinner by the minute, and there’s already plenty of documentation for both the stdlib and the build system, so there’s a chance 1.0 could land in 2030 or even before, at least from this list it doesn’t seem far fetched. In any case great presentation Andrew! and thanks to every member of the team involved in the development of Zig.
6 Likes
Thanks for the very informative talk, I loved the core team presentation.
2 Likes
As always, great talk, very interesting to dive deeper into the team dynamics. Also I really like the more social/political/economic ideas behind the ZFS.
I have a question for Andrew if he stubles upon this:
Is there anything you wanted to add regarding the current git forge situation? I am currently revolving around how the general idea of a git forge can be improved on, and the actual implementation. It seemed like you got lost there for a second, but wanted to add something. It would be very valuable to share if there is more to it. 
3 Likes
I’ll join you on the question, I’m curious to hear more. I think what could be really cool with git/forge and even more with things like CI/CD for example, is if there was a system akin to the peer to peer torrent, where everything is basically distributed and decentralized, where everyone can dedicate resources to host part of it. I remember of a program on windows for scientific computing where you could if i recall correctly participate by installing the program and basically computing stuff for them.
1 Like
two things i’m excited for in this space are Radicle (mentioned in the talk, but briefly; I believe Andrew says Zig is “Radicle-curious”) and Manganin, which is a good deal earlier on, but for which I can put a face to the name in a way that I can’t with Radicle.
5 Likes
I think you mean folding@home.
And it still exists (and not just for Windows).
2 Likes
I’m gonna hijack this thread to thank the Zig Core team and all the people who make up this community. In Boston, after this talk, I already told Andrew and Loris this, but I think Zig is a really special project and this talk really highlights it, I love how human-centered Zig is and how open everyone is to just exchange ideas and learn from each other.
I’m really happy to see how far Zig has gotten since I first came into contact with it. There’s a lot of work ahead, but we’re closer than I thought! I’m looking so much forward to the aarch64 backend!
7 Likes
I loved the human aspect of this talk, though for the other half of the talk, I’m having trouble pairing some these ideas together:
- ziglang.org: favor centralized, single instance, low complexity, “just a server in the closet”, by building systems which do not strictly require high uptime (community mirrors?)
- forge: favor decentralized, high complexity system, questionable / high # of dependencies. burdon of new protocols is high, impleemntation burdon there, specification burdon, compatibility burdon.
- package manager: favor decentralized, but not exactly finished, considering torrenting, something missing perhaps? (As a corperate user, transitive dependencies are difficult to guarantee uptime for ci due to no way for me to define some artfiactory-like registry to pull from for everything)
What makes the ziglang.org approach not appropriate for forge, and similarly for package manager? Is there a solution which fits all three? Ipfs? Torrenting?
I am reminded of this blog: No one actually wants simplicity - lukeplant.me.uk
The question of the blog is “do we actually want simplicity, and what are we willing to sacrifice for it”?
I think this question is still unanswered by the zig community and zsf.
For example, package manager includes git, tar, tar.gz support, it’s in awkward middle ground between has more than 1 feature and thus is moderately complex but not enough features to be “game changing” (download from some content addressible sources)
I understand all of these things are unfinished, just having trouble seeing the vision. Do we want higher reliability self hosting or decentralized, high uptime or not care about uptime, complexity or simplicity, low dependency count or high dependency count?
2 Likes
Plus one on that, as a corporate user too, in the defense industry, what I can tell, is that there’s a clear need for self hosting registry to pull everything from. We have our own docker registry, our own python registry, and generally wee have a registry of approved software/packages for about everything. And this is an important feature, for reproducibility and security.
2 Likes
Radicle is certainly complex, and that may have contributed to the disasterous bug they’re dealing with now. However, in-repo (local first) issues and patches definitely do make uptime less critical for a git forge, and that sounded like Andrew’s main point. If you can view and edit your issues and reply to comments completely offline, temporary outages aren’t as painful because you can keep working. We can achieve that without including the complexity of decentralized p2p (I’m working on it!).
10 Likes
One critique here:
Ziglang.org does favor decentralization with community mirrors. It also favors decentralization because the documentation is shipped with the compiler so it is not necessary to have that up for standard library docs. The only think that’s really centralized about it is DNS for the domain which is out of their control.
I see it as following some of the same patterns: allow the community to help decentralize and support the ecosystem
2 Likes
Loved the talk, so wholesome. What a great team and team management, this is why I love software development.
1 Like
From the link:
This is such a basic oversight (how do you have an unencrypted protocol in 2026?) that I’m a lot less “Radicle-curious” now. In the “wt actual f” sense.
7 Likes
Hah, it’s even better than that. They do setup an encrypted connection!
The person who found it has a much more detailed description: Vulnerability disclosure: Radicle nodes send private repositories in cleartext | Kostis Maninakis
The handshake itself works and leaves both nodes holding a pair of session keys, but
radicle-nodenever uses them beyond that point. Once the handshake is done, the node’s own connection code passes every message straight to the plain TCP socket, so everything the two nodes say to each other goes out unencrypted: gossip, repository ids, the addresses of other nodes, and the Git objects themselves, private repositories included.
The thing that really gets me is that this isn’t some rare bug, it happens every single time! One look with wireshark is all it takes to see the problem:
My encrypted transport couldn’t hold a connection to a real node. The handshake would complete and then everything fell apart. The Noise code was mine, so I assumed the bug was mine too, and hunted it there for a good while. Eventually I put Wireshark on the connection to see what the other side was actually sending me.
rad, in ASCII, right after the handshake. I didn’t believe it at first. The other node wasn’t encrypting anything.
This is a good reminder that if you seriously care about security (physical or digital), there is no substitute for penetration testing.
7 Likes
How do I view the docs locally?
zig std --port 43903 --no-open-browser
Something similar to this.
6 Likes
HO LEE COW! This is great!
Loved the talk, but I was a little confused when Andrew said Zig did not have any company dependency on AI companies at 28:59. It’s a verifiable fact that Zig does take sponsors from AI companies, even if it’s not The Big Ones. At least according to the very bottom of the 0.17.0 release notes. Two of the three thanked sponsors (and two of the five ZSF corporate sponsors) make AI products.
2 Likes
They are referring to technologies the actual compiler, and other projects depend on in some fashion, including developer workflow.
Sponsors are no strings attached, so they don’t count. Like bun gave them a lot of money, but Zig didn’t fall apart when they left because Zig was not dependent on bun.
3 Likes