I’m new to Zig and needed some helpful references. The docs were ok but could have better so I made this in a few hours with the help of Claude ![]()
Examples, clear language and clear terminology, no jargon.
I’m new to Zig and needed some helpful references. The docs were ok but could have better so I made this in a few hours with the help of Claude ![]()
Examples, clear language and clear terminology, no jargon.
I would recommend either prominently disclosing the use of LLMs on the website itself, or otherwise proofreading the result to make sure there are no hallucinations. There are hallucinations right now (spotted one in five minutes of browsing), so, as it stands, the website might cause confusion. Given that many people object to LLMs on non-functional grounds, it’s probably nice to disclose LLM usage even if the content is indistinguishable from human-authored.
Good idea. Can you point out the mistake, I will make the adjustments. The site is basically just a shell to display markdown files.
I haven’t looked at the resources, as the domain is blocked on my work network. I have to say that this is an example of why Ziggit has put into place an “AI/LLM Policy”. One of the purposes of this forum is to give new users access to humans who write and use zig. The purpose is not to generate more confusion, which is what using LLM’s to generate AI documentation about a language you don’t understand is doing. It would be far better for you to write a blog post about the language with your own understanding and share it here asking for feedback. Indeed that is something that happens regularly here.
Don’t take this as a reprimand to not learn zig or participate, but understand that if you lack the knowledge about zig at this level, then you also lack the understanding to judge an LLM’s output. Like I said, rather than resorting to sharing AI, write a blog post and ask for reviews. I can guarantee it will help improve your understanding at a deeper level than an LLM.
Thanks for taking the time to share your thoughts on this.
You’re right about validation. I’ve now implemented a testing process - every code example is compiled and tested against Zig 0.16. All 23 test cases pass, with only 2 minor syntax updates needed for the latest version.
I want to clarify something: I’ve been programming for quite a while and do understand these concepts. I used AI as a tool to help structure and explain things, not to generate content about a language I don’t know.
The goal was to cut through jargon and make Zig more accessible “for dummies” is the approach, not my skill level.
That said, your point about community review is well taken. I’d genuinely appreciate specific technical feedback on anything that could be improved. If anyone spots actual technical issues, I’ll fix them immediately. Vague “there re errors” without specifics doesn’t really help anyone learn or improve.
The Zig community has been welcoming, I’m just trying to give back by helping newcomers get started. But validated, working code examples that compile and run correctly - that’s the standard now.
Thanks for the push to validate everything systematically.
I will push the updates to the site later today, I will also include the validation report and a Documentation generated by a LLM label displayed prominently as suggested.
The new front page, with a report of all the code validated to be correct. Thank you everyone for your feedback, will be going live with the update within the hour
the changes are live!
How does that testing work?
At least your website has a completely obvious escaping issue where it turns \n within strings within print statements into an actual newline within the code display, producing code that doesn’t run for the reader:
const std = @import("std");
pub fn main() void {
std.debug.print("Hello, World!
", .{});
}
Output:
helloworld.zig:4:35: error: string literal contains invalid byte: '\n'
std.debug.print("Hello, World!
^
This sort of over-confidence in LLMs output is my main issue with people using it too casually, you can’t just trust a LLM to actually do what you tell it to, you need to double and triple check its work and when you don’t do that, you create more work for other people.
In this case it is pretty harmless, but add some more hidden text, prompt-injections and LLM poisioning and you have a not so unlikely attack of users copying code that was injected with other code, especially if you think about showing one version of the text and the website inserting a slightly altered version of the text into your clipboard when you copy&paste the example.
I guess tell your LLM it messed up, maybe it will find my post, read it and then replicate it, like that other story where an LLM just copied the solution from a git branch it wasn’t supposed to have knowledge of (because the people that tested its capabilities messed up and allowed it to cheat, by using the solution in another branch; some AI models are pretty good at finding ways to cheat and appear smarter than they are…)
tl;dr
I don’t really care, but please double check what the LLM is doing
ps: maybe people should watch some more of Robert Miles videos about AI safety to be a little less enthusiastic and more distrusting towards AI (which I think would benefit us)
ya, that was fixed in the update, it wasn’t an error with the md file, it was the render engine interpreting \n as a literal return, that issue has been addressed in the recent update.
I think it would be good if you had something to collect user feedback like a link to an issue tracker or something similar, so that if a user finds that something doesn’t work you will know.
you can now use the contact form to suggest edit / changes. At the bottom of the main page, good idea
The section on Zig’s pointer types completely omits both C pointers ([*c]T) and sentinel types.
Given that these types are fundamental building blocks of the language (i.e. literal strings, C-interop, etc), it seems worth at least mentioning their existence. The LLM seemed to devolve into an elementary and language-agnostic lesson on pointers instead of explaining Zig-specific idiosyncrasies with them, which I assume is the primary goal.
What is the point of publishing a bunch of AI noise like this? There are many well written human articles that already cover the same material in a much better way. Anyone could already ask an LLM if they want to go that route, and then they will understand what they are getting into and be able to interact and question the output. Sharing slop like this only has a negative impact on the world, I’ve been learning Linux Kernel development and it’s so annoying to have to sift through search results to find real articles and documentation.
Good point - the pointer chapter is missing critical Zig-specific pointer types. C pointers ([*c]T) and sentinel types.
This is genuinely helpful feedback!
If you have specific examples or use cases you’d like to see covered, I’d love to hear about them.
I agree that the pollution of search results with AI-generated ‘slop’ is a real and growing problem that makes finding reliable information difficult.
However, I believe this characterization misrepresents the nature of this project. This resource consists of eleven short tutorial chapters, each featuring simple, working code examples (approximately 10 lines each).
Crucially, all the code is validated against Zig 0.16 as shown in the validation report.
This is not auto-generated API documentation or a massive codebase churned out for SEO purposes.
It is a beginner-focused tutorial offering fundamental examples, such as ‘how pointers work,’ supported by minimal, working code.
I have added to the pointers section, please let me know what you think or if you have any more good ideas!
You have ignored my original point and have kept perusing this. Here is a blatant example of code that is just wrong:
// Fields must be in order if you omit names
const bob = Person{ "Bob", 25 }; // name="Bob", age=25
While I left this thread open to give some benefit of the doubt, I strongly feel that continued promotion of this project on ziggit violates our AI/LLM policy.