I finally got it working. I had to flush both the encrypted writer and then the stream writer. There was also some issues with reading. Streaming works, but it'll always return 0 on the first read because Writer.Fixed doesn't implement sendFile, and thus after the first call, it internally switches from streaming mode to reading mode (1) and then things magically work.
Currently trying to get compression re-enabled in my websocket library.
I'm not a Zig PM but the first obvious fix for the issues the OP wrote about is to write better documentation, including usage examples (the more the better, almost to a fault). Also doubles as a good time to reflect on whether the user is having to do too much.
If the tradeoff was absolute performance/avoiding introducing load-bearing performance-lowering abstraction I think that goal was achieved, but DX may have gone out the window.
You’re not familiar with Zig’s culture, I guess. Complain about the lack of documentation and be prepared for the flood of “just read the stdlib code” helpful comments by pretty much everyone who writes Zig right now.
Because most APIs are just as hard to use as in this post (check things like HTTP and even basic file system operations) only the strongest survive.
I am just editing docs now that Claude Code writes for me. I am fanatic about developer docs (and I guess an exception as I love writing them) but with a set of concise instructions for CC and some writing style examples I get 90% there, sometimes 99%.
If you believe you don't have time for the last 1--10% you should not be in charge of writing any API used by anyone but yourself. Just my two c.
Ai is great at block comments, there is no excuse. Add to that a small anotated usage example written by a human and this whole post would have not existed.
Lack of docs also cripple AI from understanding, so future adoption becomes even more bleak.
If an api or library developer didnt bother doing even bare minimum docs, my confidence in the library drops aswell.
Did they skip testing aswell? Ran the happy path for a day and called it good?
This post sour my interest in zig. Its now obvious to me now why rust took much of its market.
There's also a fundamental difference in Zig and Rust.
Ever tried reading std code in Rust? If you have, you would notice one thing really quick: it's borderline unreadable. It's a hornet's nest of Generics over constraint generics calling into indirections.
Of course, this isn't meant to be a defense for the lack of documentation on Zig's side, but in my experience, Zig's code definetly is much easier to read, just because for the fact, that Rust's std code is akin to C++'s stl.
One of the personal grimes i have with Zig is, that `anytype` makes the function contract kind of meaningless, because you can't see what is expected purely on the function definition.
I like Zig, but if we look at the numbers, the difference is probably more to do with funding that anything:
Zig (programming language) - First appeared 8 February 2016; 9 years ago
Rust (programming language) - First appeared January 19, 2012; 13 years ago
Also, Zig at this point isn't really a brand new language anymore. I have comments on their issues dating back to 2018, so it's been a very active language since at least then.
So they're gonna just finnish up their standard lib and THEN spend a year doing nothing but docs for everything they made?
Just getting started is an even bigger reason to have good docs to clearly communicate how the libraries and APIs work!
I wouldn't even read a push request containing a new function if the creator didn't bother writing a short description and usage clarification.
Getting started is a good excuse for limited libraries or support (same situationwith rust). But lack of even basic docs is not acceptable if you want user adoption.
As a senior dev I’m also passionate about docs and communication, and actually kind of love the process of agonizing over a bunch of rST files to get the perfect manual that’s both an on-boarding guide and also a reference of all the nooks and crannies.
I think what I’ve come to realize is that when I feel a barrier toward doing that work, it’s a sign that I don’t actually like the underlying API. I don’t want to document it or craft examples or tutorials because in my mind the API sucks, it’s transitional, and documenting it in its current state is going to somehow lock in a bad interface and further increase the effort required to change and fix it up later.
That would hurt adoption. I understand things move fast but if you want people to make the switch other than hello world, it has to be at a minimum cosy. Sending them to hell and find your way out isn't a good move long term.
I tried Zig a couple of times and I got that feeling: very powerful and clever language but not really for me, I don't have the headspace, sorry. I need something I can debug after an 8 hours dayjob, a commute and having put the kids to bed. It better be inviting & fun! (Hi, C).
Yeah, I had the same experience. I had an embedded project where I would need to use C libraries, and it seemed like a great excuse to try Zig, but it spat out a ton of esoteric errors I couldn't be bothered to figure out and I went back to Nim.
The key problem with Zig nowadays is how much of its community and adoption is driven by anti-Rust sentiment. As a result, while Rust puts beginner onboarding and documentation at the center of its culture, as opposed to the “C neckbeard”'s culture, Zig is going the other way around.
(Loris Cro being a key community figure isn't helping in any way, and it's a good remainder that if you don't clear up your community from bullies from the beginning, they will turn your entire community to a miserable place. And that's a shame because from what I've seen, Andrew Kelley seems to be a very cool guy in addition to being very smart).
> The key problem with Zig nowadays is how much of its community and adoption is driven by anti-Rust sentiment. As a result, while Rust puts beginner onboarding and documentation at the center of its culture, as opposed to the “C neckbeard”'s culture, Zig is going the other way around.
Maybe, or maybe the fact that Zig is a small independent project with limited resources has also something to do with it, and this kind of shaming says less about Zig than you'd think.
When I first joined the Zig project, Zig was still using the bootstrap compiler written in C++ that would not free memory (it took more than 4GB to compile the Zig compiler). Some people at the time were asking us to prioritize work on the package manager but Andrew rightfully wanted to prioritize rewriting the compiler instead. In hindsight this was the obviously right decision: a package manager implies that one can very easily add an order of magnitude more code to their project, stressing the performance of the compiler. If we had not prioritized core infrastructure over giving people what they wanted faster, today we would have people complaining that adding a single dependency to their project makes the build impossible to complete.
The Zig project has a huge scope and we are a small independent organization. This makes us extremely nimble and efficient, but it does mean that we need to do things in the order that makes the most sense for the project, not for what the public wants.
The fact that we develop in the open doesn't mean that the language is ready yet.
People that already have the required domain knowledge (and who have a tolerance for breaking changes) will have the opportunity to be early adopters if they wish to do so, others will have to wait for Zig to become more mature. And we do make this clear in releases and all forms of public communication.
We have gone a long way since the bootstrap compiler days, but we are still missing key infrastructure:
- we have a x86_64 custom backend but aarch64 is not complete yet
- incremental compilation is showing that we can get instant rebuilds of large projects, but it has missing features and it doesn't work on all platforms yet
- we need native fuzzing since AFL keeps regressing everytime a new version of LLVM comes out
- for the longest time we haven't had a strong I/O story, now we're finally working on it
The time for paving the road for a new generation of programmers will come (it's in the ZSF mission statement btw), but first we need to finish the plumbing.
> Maybe, or maybe the fact that Zig is a small independent project with limited resources has also something to do with it
Or, maybe it's this kind of redirection and evidence of a victim complex. Part of the reason that there's a patina of anti-Rust sentiment includes the dismissive attitude and swipes you, a the VP of Community at the Zig Software Foundation, take towards Rust and Rust developers by writing about topics you aren't involved in and don't have a solid grasp of.
This Zig victim complex, smells of clear hypocrisy, as can be easily seen by their swipes and harassment of other programming languages, like V (Vlang).
It reflects poorly on any leadership engaging in that kind of bad and unprofessional behavior, and it eventually backfires on any project or person. People eventually notice it and figure out the foul things that have been or is being done, then demand accountability or walk away from the toxicity.
I just wanted to clarify that I point this out to say that there was a real opportunity in this thread to try to push back on the language wars perception. To me, good community management would be taking the opportunity to say:
* Sorry you feel that way, we try not to foster an inclusive environment that avoids language flamewars and negativity towards other languages
* Some specific examples of policies that are enacted in community spaces towards that end (e.g. some large programming language discord servers have specific rules against low effort language bashing content and memes)
* Take the opportunity to link back to positive things that the Zig team has said about Rust and places where folks have recommended it.
Instead, we got a shallow dismissal and redirection, which unfortunately starts to look like a pattern, especially when coming from a person who's in a leadership position in the community being discussed.
> […] Zig was still using the bootstrap compiler written in C++ that would not free memory […]
That sounds strange. Modern C++ requires very little manual memory management, at least when you're writing something high-level like a compiler. C++11 had been out for years when development on Zig started. Were they writing C++ old-school as C-with-classes and malloc() everywhere? Why not use a more appropriate language for the first prototype of a compiler for a brand new language?
IIRC, it was a performance thing, and it's not an uncommon pattern in CLI tools. Freeing memory can actually cost you performance, so why not just let the OS clean up for you at exit(2)?
Not only, the whole handmade movement puts me off.
It is the anti-intelectualism from Go culture, gone wild against C++, Rust, Swift, anything modern, or even tools, using game engines versus doing the whole computer from scratch for a game.
Zig is not really a handmade project, case in point both Andrew and I are blocked on social media by the two gods of the handmade movement (casey and john) and, according to their die hard fans, Andrew gave a talk at the last handmade conference that caused the community to split apart (the reality is a bit more complex than this, but Andrew's talk is certainly one that you wouldn't see at their new "better software" conference).
Depends on the attitude, not using an engine, because one wants to learn the whole stack, makes all sense, after all people need to learn how to make game engines, if nothing else for the next generation.
Not using one out of spite, because we do everything handmade over here attitude, is a completely different matter.
Unfortunately for everyone, people like you tie their entire identity and income to specific technologies, movements, or communities—becoming deeply tribal in the process. When something or someone undermines their sense of security—even with constructive criticism—they react defensively, often to the point of ignorance.
All this, combined with the fact that Zig, at best is still in beta quality and at worst amounts to a massive waste of everyone’s time, makes it unsurprising that people block you and simply refuse to engage with your loud community efforts, endless churn and crust tied to beta quality compiler.
> Zig is not really a handmade project, case in point both Andrew and I are blocked on social media by the two gods of the handmade movement (casey and john) and, according to their die hard fans, Andrew gave a talk at the last handmade conference that caused the community to split apart (the reality is a bit more complex than this, but Andrew's talk is certainly one that you wouldn't see at their new "better software" conference).
In the first, at 2:30:40, Andrew Kelly publicly calls out a specific author of a competing technology in exaggerated, caricatured, and fabricated context.
In the second video, yet another author of a yet another competing technology directly points out this unapologetic and concerning behavior on Andrew Kelly’s part.
And now you—“VP of Community @ Zig Software Foundation”—assert your “righteous” stance by sharing these videos, while ironically pointing out that some of those same individuals (of competing technologies fame) block you on social media.
Too bad that doing your job probably means being as loud and visible online as possible to spread the molecules of Zig no matter what.
If you didn't know, Casey has made comments on a YouTube video, that he does not like Zig. His review of Zig, was that it's a language that he rather not use and would not recommend.
The anti rust sentiment in large part is dissatisfaction with rust itself. Ziglang.org lists 3 principles of zig: no hidden control flow, no hidden memory allocations, no macros. This is not anti rust for the sake of being anti rust, this is anti lots of popular languages, and I personally like it.
That isn't “anti Rust” at all, it's just a different set of trade offs, and it's fine that it attracts developers who don't like the set of trade offs Rust make.
What's not very good are the people who don't like Rust, who are uneasy with Rust is eating the system programming world, and are now pushing Zig as the champion of the resistance about Rust.
That is actually a valid point on expectation given the attracted people's demographic.
I will hopefully wait for comments from Ghostty, Bun or Tigerbeetle Devs.
On another point that is wroth mentioning, I hope Andrew will at least put it out publicly, IMO Zig isn't Anti-Rust. But it did attract the type of people who are not too happy with Rust. I dont remember a single time Zig came out to bash anything about Rust. It isn't Anti anything at all. Its goal is to be a decent C replacement as very high level assembly languages, aiming at Data Oriented Design with some interesting features, and extremely fast compilation speed. ( Which was the reason why I was interested in it in the first place. I miss Turbo Pascal )
Zig reminds me of the old school, traditional projects. It isn't perfect for everything, it never claims to be, if you like it, use it. If not, there are plenty of options out there.
At least Ghostty Dev seems to be enjoying it almost every day.
I don't think Andrew is anti-Rust. But Loris, whose hn profile says he's “vp of community of the zig software foundation” is as anti-Rust as you can get: he's pathologically obsessed by Rust and spent significant amount of energy outright insulting Rust maintainers here or on Twitter (when he's not buzzy writing anti-Rust rant on his blog).
But as you say, there's no reason why Zig ought to be anti-Rust, both language are are fresh attempts at low level programming, both highly opinionated and with very different philosophies and trade offs and both language can cohabit peacefully (I've heard good things about using the Zig toolchain for cross compilation of C dependencies in rust projects, so the existence of Zig already has had a positive impact on the Rust ecosystem).
Huh, it all started with a Rust developer ceaselessly picking on Zig been memory-unsafe on social media. It would be one thing to write some technical post and be done with it but this obsession with Zig by Rust dev was infuriating to put it mildly. The same dev was very anti-Go in past and would post endless comments on Go here and elsewhere.
I have not seen much of any anti-Rust sentiment in the community. There's a lot of people in the community who do Rust, like rust, and work on rust projects. If the Zig community has an anti-anything sentiment, it's against C++.
Tell that to the “VP of community @ zig software foundation” who spend a significant fraction of its time insulting Rust maintainers or mere users here or on Twitter when he's not busy writing anti-Rust rants on his blog.
(You won't have to seek long in his HN history to find an instance of such behavior)
Yeah, thinking about this attitude positively, maybe it’s a feature — if only hard core people can comfortably figure it out, you get higher quality contributions?
Not trying to imply that’s an explicit goal (probably instead just a resource problem), but an observation
I think it is a trade off for between zig's development speed and documentation. It is Pre 1.0, extreme beta mode with lots of breaking changes.
Generally speaking I think it is the right trade off for now. Purely inferring from Andrew and the Zig's team online character as I don't know them in person, I think they do care a lot of DX, things like compiling speed and tools. So I think once 1.0 come I won't be surprised if it will have extremely good documentation as well.
And I would argue, writing good, simple, clear, detailed documentation is actually harder than writing code itself.
I've written many APIs. Never have I got it right without first writing lots of tests, finding the rough corners, improving it... and so on. Writing documentation after that is absolutely mandatory for the end result to be a high quality API. As you write how it is meant to work, you will definitely find things that don't really make sense, or that should not be as hard ( I think this post shows just such an API that hasn't gone through this process ). IMHO documentation is NOT optional. The implementation is NOT how you mean for the API to be used.
On the one hand, I totally get that pre 1.0 is the wild west (somewhat) and should be. The team is right in jealously guarding their ability to make changes.
That said, others have pointed out that writing documentation and tests helps improve quality quite a bit, and in this case it would also increase usability. I think I'd agree with this stance, but there is no way I could make the statement that even most of the code I've written for public consumption had excellent documentation or examples. So I've got no leg to stand on there, just the armchair.
> And I would argue, writing good, simple, clear, detailed documentation is actually harder than writing code itself.
All the more reason why it must be done! A little silly but from my armchair maybe it's one of those "start with the interface you want and work backwards", but the problem is that approach can be at odds with mechanical sympathy and we know which side Zig lands on (and arguably should land on based on it's values).
My quick skim of Wikipedia may not be telling the complete story, but it says the initial release was 9 years ago (February 2016). After nearly a decade, I would hope that things would be out of "extreme beta mode," but I guess this isn't the case?
Contributions to the Zig language or contributions to software using Zig (the latter is the one the post is about as I understand)?
If so, I believe Zig will stay within a niche. Lower entry barriers allow "script kiddies" to easily start withe language, and they eventually will become leading engineers. Only a few people tend to go straight for the highest practice without "playing around". IMHO the reason, why PHP got so popular (it was not good back then, just very very easy to start with).
> Contributions to the Zig language or contributions to software using Zig (the latter is the one the post is about as I understand)?
Yes.
I think a contributor that really wanted to help the ecosystem would start in the stdlib and then start moving outwards. Even if it was LLM-assisted, I think it could be high value.
IIRC Loris already has an engine for building websites with Zig, but making sure that every Zig library has docs (similar to rustdocs) might be a great start. It is incredibly useful to have a resource like rustdocs, both the tooling and the web sites that are easily browsable.
Again, maybe everyone in the Zig ecosystem just has amazing editor setups and massive brains, but I personally really like the ease of browsing rustdoc.
> If so, I believe Zig will stay within a niche. Lower entry barriers allow "script kiddies" to easily start withe language, and they eventually will become leading engineers. Only a few people tend to go straight for the highest practice without "playing around". IMHO the reason, why PHP got so popular (it was not good back then, just very very easy to start with).
I agree, but I'd add that the niche they're aiming for is systems programming, so they're probably fine :). The average hacker there is expecting C/C++ or to be near the metal, and I think Zig is a great fit there. They're likely not going to convince people who write Ruby, but it feels reasonable for C hackers.
Also I want to just be clear that I think Zig has a lot of motivating factors! They're doing amazing things like zig cc, unbelievably easy, "can't believe it's not butter" cross-compilation, their new explicit/managed I/O mechanism, explicit allocators as a default, comptime, better type ergonomics. It's a pretty impressive language.
> already has an engine for building websites with Zig, but making sure that every Zig library has docs
Tbh, this sort of auto-generated docs from source code is not all that useful, since you get that same information right in the IDE via the language server.
The important documentation part that's currently missing is how everything is supposed to work together in the stdlib, not the 'micro-documentation' of what a single type or function does. And for this sort of information it's currently indeed better to look at example code (e.g. the stdlib's testing code).
IMHO it's way too early for this type of high-level documentation, since things change all the time in the stdlib. Putting much work into documenting concepts that are discarded again anyway doesn't make much sense.
I think it is intentional. They don't want to attract low-commitment beginners while the language is heavily changing (and explicitly in beta). Such people will ask questions and ask for documentation but contribute nothing.
More likely you get people who have the same groupthink, which has both ups and downs. Their contribution quality is probably not that well correlated.
There is a cost to writing documentation - it takes time, which could be used to improve Zig in other areas. For code that is work-in-progress, it can make sense to not document until things are more settled.
Of course documentation is good. But if you have to prioritize either a new feature, or a critical bugfix, or documentation, you often can't have it all
I tend to actually disagree with this attitude, because I see writing documentation as really effective "rubber-ducking". If it's hard and time-consuming to properly document, it's probably hard to use, so extra effort should be spent to actually justify the design, not least to yourself in 6 months. If you can't justify it, it's probably wrong.
This really struck a chord with me. Writing documentation is an act of explaining something to others. Explaining something to others is a great way to test your own understanding. If it's hard to explain to someone else, then maybe it's the wrong design.
If you don't through that exercise, you're much more likely to build confusing, difficult-to-use APIs.
> you're much more likely to build confusing, difficult-to-use APIs.
have not found this to be the case with zig in general. you could easily make the opposite argument, that documenting things (especially quirks) can give you license to build confusing APIs.
I think some documentation and a handful of examples would have helped the author of the article. How is the experience when porting to the new standard library improved by not including documentation?
On the other hand, not writing documentation also has a cost.
Code is rarely written from start to finish in a single session. Would you rather spend 5 minutes before you do a git commit to write down some very basic documentation, or spend an hour rediscovering it when you pick up development two weeks later?
Nobody is expecting extensive and well-polished documentation here, but is a "Flags X, Y, and Z are mandatory, buffer A is required: I tested with 10MB, smaller might be fine too" really too much to ask for?
Is the time you saved by not writing that one line worth someone else spending several hours figuring out how to do a "hello world"?
Your argument implies that good documentation is not an improvement, which of course is wrong. It also belongs to the task of improving code. Why would you move away after half-assing the API, when you can add the docs and whole-ass it instead?
Breaking changes and limited support is one thing. But docs is not something you add at at the end. Lacking docs and Lacking tests is code that should not be released.
They target embedded c market. Limited support and features is expected and common. But being lax with docs and testing is not acceptable.
> But being lax with docs and testing is not acceptable.
First: Those two things are not the same. The Zig stdlib and compiler have tons of tests, and it's actually quite rare to stumble over implementation bugs.
Second: I'd rather take no docs at all than per-function or per-type doc-headers which just repeat what the code does in natural language (and then may quickly get stale). Some parent wrote about generating docs with an LLM which is just a laughably bad idea, since even with perfect results you'll just get a redundant reiteration of what the code below does, just in imprecise human language, it would literally just be redundant noise.
Documentation mostly makes sense up on the systems level to explain high level concepts, not as 'this function does this and that...' level, this information already exists in much more precise form in the source code below the doc header.
But this sort of high level documentation doesn't make sense as long as a project is in the experimentation phase, and Zig is still one big experiment.
Because the language is not stable at this point and hasn't reached 1.0?
Are you saying one should never make anything half finished available to the public? This post proves why it is valuable to do so, they are getting valuable feedback and a discussion on hacker news for free.
There's an alternative of being much more up front about the status. For example the project page doesn't really say it's unstable/experimental. It only says "Zig has not yet reached v1.0" on the "getting started" page, which doesn't really mean that much - for example Putty is still at 0.83 after 26 years.
If the project invites me to use it "for maintaining robust, optimal and reusable software." without putting "super unstable, we don't even care about docs" on the same page... that's also saying something.
I'm not a Zig developer, but I imagine one reason why the Zig documentation is so spartan is because the language is still young and constantly evolving. It's really hard to devote the time and energy to writing documentation when you know that what you've written will just be wrong at some uncertain point in the future.
Many would argue that Zig is not to be considered a young language anymore. It's been out for 9 plus years already.
A different answer to that question, could be that its still unstable and making breaking changes (not 1.0), thus a reluctancy to focus on documentation to a level many consider satisfactory.
i find that zig is too oriented at doling out directives for what not to do instead of just collecting and teaching variants of how and what to do. the lack of documentation on this interface is a sore case in point.
That's ok. "It's an unstable, experimental, early version." is a valid explanation. GP put the lack of docs and the new interface together, which... isn't an excuse.
You absolutely should expect documentation this early. The chances of quality documentation being added as an afterthought are not good. If proper documentation isn't part of the original goals after that time, things aren't looking well. Nobody is going to come and just write docs for months.
Only in a world where features are made without thought.
Documentation is not just for your users.
Writing the development documentation helps you make better features in the first place.
The zig users on this thread seem to not understand this, and all seem to think documentation is a thing you write later for users when everything settles down. Or is somehow otherwise "in the way" of feature and API development speed.
That is a very strange view.
If writing developer documentation is having serious affect on your language feature velocity, you are doing something very wrong. Instead, writing it should make things move faster, becuase, at a minimum, others understand what you are trying to do, how it is going to work, and can help. Also, it helps you think through it yourself and whether what you are writing makes any sense, etc.
Yes there are people who can do this all without documentation, but there are 100x as many who can't, but will still give high quality contributions that will move you along faster if you enable them to help you. Throwing out the ability to have these folks help you is, at a minimum, self-defeating.
I learned this the hard way, because i'm one of those folks who can just stare at random undocumented messy code and know what it actually does, what the author was probably trying to do, etc, and it took years till i learned most people were not like this.
That's a false dichotomy, I'll take minimal bitrotten docs in a community wiki over no docs. There's no excuse not to at least have a stub that says "these features are evolving quickly but here are 10 open source projects that should serve as good references".
Something - anything. As much as I like Zig, I dread returning to it after a few months of being out of the loop.
"No documentation" and "Core devs 'wasting' time on writing high quality documentation" aren't the only two options, that's what a false dichotomy means.
Other options include but are not limited to providing minimal, low effort examples, high-level overview, linking to projects using these features, linking to relevant tests, commits, or source code, setting up an official community wiki and encouraging people to contribute.
"No documentation" was never presented as an option. Documentation exists. By treating "insufficient docs" as "no docs", you're the one making the false equivalency.
The Zig's language is really good, but the standard library is really a big work in progress, constantly shifting, missing a lot of bits, overly abstracted at some places and too low level at other places.
I would say just stay away from the standard library for now and use your OS API, unless you're willing to be a beta tester.
From my perspective, Zig is trying to do far too many things to ever reach a baseline of goodness that I consider acceptable. They are in my view quite disrespectful to their users who they force to endure churn at the whims of their dictator. Now that enough people have bought in and accepted that a broken tool is ok so long as it hasn't been blessed with a 1.0 all of its clear flaws can be overlooked in the hope of the coming utopia (spoiler alert: that day will never arrive).
Personally, I think it is wrong to inflict your experiments on other people and when you pull the rug out from underneath say, well, we told you it was unstable, you should't have depended on us in the first place.
I don't even understand what zig is supposed to be. Matklad seems to think it is a machine level language: https://lobste.rs/s/ntruuu/lobsters_interview_with_matklad. This contrasts with the official language landing page: Zig is a general-purpose programming language and toolchain for maintaining robust, optimal and reusable software. These two definitions are mutually incompatible. Moreover, zig is clearly not a general purpose language because there are plenty of programming problems where manual memory management is neither needed nor desirable.
All of this confusion is manifest in zig's instability and bloated standard library. Indeed a huge standard library is incompatible with the claims of simplicity and generality they frequently make. Async is not a feature that can be implemented universally without adding overhead and indirection because of the fundamental differences in capabilities exposed by the various platforms. Again, they are promising a silver bullet even though their prior attempt, in which they publicly proclaimed function coloring to be solved, has been abandoned. Why would we trust them to get it right a second time?
There are a very small number of assembly primitives that every platform provides that are necessary to implement a compiler. Load/store/mov/inc/jeq/jump and perhaps a few others. Luajit implements its parser in pure assembly and I am not aware of an important platform that luajit runs on that zig goes. I do the vast majority of my programming in lua and _never_ run into bugs in the interpreter. I truly cannot think of a single problem that I think zig would solve better than luajit. Even if that did exist, I could embed the zig code in my lua file and use lua to drive the zig compiler and then call into the specialized code using the lua ffi. But the vast majority of code does not need to be optimized to the level of machine code where it is worth putting up with all of the other headaches that adopting zig will create.
The hype around zig is truly reaching llm levels of disconnection from reality. Again, to believe in zig, one has to believe it will magically develop capacities that it does not presently have and for which there is no plan to actually execute besides vague plans of just wait.
I have never understood libraries or imterfaces that want me to allocate buffers for their type. I can't parse them (no need for the lib then) or write to them (would probably break the exchange).
The weird interface of go is probably due the fact that some interfaces can be used to extemd the writer like the hijacker interface (ResponseWriter.(http.Hijacker)) and the request object is used multiple times with different middlewares interacting with it.
In short: request does not need to be extended, but the response can be an websocket, an wrapped tcp connection or something else.
> I have never understood libraries or imterfaces that want me to allocate buffers for their type.
That doesn't seem that odd to me. It's a trade off: more flexibility, but more manual work. Maybe I have a buffer that I've allocated that I'm not using anymore (say I have a buffer pool) and want to use it again. If the type allocates its own behind the scenes, I can't do that. Or maybe I'm working in an environment where I need to statically allocate all of my resources up-front, and can't allocate later.
The big downside is that if 90% of people are just going to allocate a buffer and pass it in, it sucks that 90% of people need to do more work and understand more minutiae when only 10% of the people actually need to. The holy grail is to give lots of flexibility, but make the simple/common case easy.
A simple improvement to this interface might be to allow the caller to pass a zero-length buffer (or Zig's version of null), and then the type will allocate its own buffer. Of course, there's still a documentation burden so people know they can do that. Another option could be to have second constructor function that takes no buffer arguments at all, which allocates the buffers and passes them to the fully-flexible constructor function.
> If the type allocates its own behind the scenes, I can't do that.
Isn't that the reason why Zig passes around allocators everywhere? If you're using a buffer pool, you should probably be handing out some kind of buffer pool allocator.
Requiring all allocation to have happened before execution is still a good reason to pass buffers around, but I feel like the other situations you describe can be solved by just passing the right allocators.
Only if use after free story actually gets fixed, and not by repurposing what has already existed in the C and C++ ecosystems for the last 30 years, like PurifyPlus or VC++ debug allocator.
If you mean running clang-tidy as a separate build step or ASAN in a different category than other soundness checks?
Compute is getting tight, lots of trends, the age of C++ is winding down gracefully. The age of Zig is emerging delibetately, and the stuff in the middle will end up in the same historical trash bin as everything else in the Altman Era: the misfortunes of losing sight of the technology.
I mean those and other ones, we already have enough unsafe languages as it is.
The age of C++ is going great, despite all its warts and unsafety, thanks to compiler frameworks like GCC and LLVM, games industry, GPGPU and Khronos APIs.
Even if C++ loses everywhere else, it has enough industry mindshare to keep being relevant.
Same applies to C, in the context of UNIX clones, POSIX, Khronos, embedded.
Being like Modula-2 or Object Pascal in safety, in C like syntax, isn't enough.
> we already have enough unsafe languages as it is
By that logic, we definitely have enough safe languages as it is, as there are many more. But this safe/unsafe dichotomy is silly, and is coloured by languages that are unsafe in some particular ways.
1. Memory safety is important because memory-safety violations are a common cause of dangerous security vulnerabilities. But once you remove out-of-bounds access, as Zig does, memory safety doesn't even make it to the top 5: https://cwe.mitre.org/top25/archive/2024/2024_cwe_top25.html I.e. the same logic that says we should focus on safety would lead us to conclude we should focus on something else.
2. Memory safety has a cost. To get it, you have to give up something else (there could even be a cost to correctness). That means that you have to consider what you're getting and what you're losing in the context of the domain you're targeting, which is not the same for all languages. C++, with its "zero-cost abstractions", believed it could be everything for everyone. That turned out not to be the case at all, and Zig is a very different language, with different goals, than C++ originally had.
Given Zig's safety guarantees (which are stronger than C++'s), and given its goals (which are different from C++'s), the question should be what should we be willing to give up to gain safety from use-after-free given the language's goals. Would more safety be better if it cost nothing? Of course, but that's not an option. Even Java and Rust could prevent many more dangerous bugs - including those that are higher risk than use-after-free - if they had more facilities like those of ATS or Idris. But they don't because their designers think that the gains wouldn't be worth the cost.
If you don't say what Zig programmers should give up to gain more safety, saying "all new languages should be memory-safe" is about as meaningful as saying we should write fewer bugs. That's a nice sentiment, but how and at what cost?
Haskell makes guarantees. Modern C++ makes predictions to within a quantifiable epsilon.
Rust makes false promises in practical situations. It invented a notion of safety that is neither well posed, nor particularly useful, nor compatible with ergonomic and efficient computing.
It's speciality is marketing and we already know the bounding box on its impact or relevance. "Vibe coding" will be a more colorful and better remembered mile marker of this lousy decade in computers than Rust, which will be an obscurity in an appendix in 100 years.
The future is many things, but a love letter to C is definitely not it.
Zig is cute and a fun hobby project that might see above average success for a hobby project. But that's about it. It doesn't address the problems people actually have with C++, not like Rust or Swift do, and it certainly isn't going to attract any attention from the Java, JavaScript, C#, Python, etc... of the world.
> It doesn't address the problems people actually have with C++, not like Rust or Swift do
Speak for yourself. Zig addresses pretty much all of my problems with C++:
- terrible compile times
- overly complex and still underpowered template/meta programming
- fragmented/ancient build tools
- actually good enums/tagged unions
- exceptions
- outdated OOP baggage
I don’t actually mind C++ that much, but Zig checks pretty much all of my boxes. Rust/swift check some of these but not all and add a few of their own.
> and it certainly isn't going to attract any attention from the Java, JavaScript, C#, Python, etc... of the world.
Yeah of course. Zig isn’t trying to be a max ergonomics scripting language…
I… will not update my zig side projects to 0.15.x. I can see why Andrew wanted to release this, and I can appreciate getting the new Io in people’s hands… but it’s merely a few weeks after merging massive amounts of breaking changes on readers and writers.
For those working on the standard library, it’s a great thing. For one like me who casually uses zig, it feels like waiting for 0.16.0 for most of the IO dust to settle is the right thing to do.
Even Loris Cro one of the Zig core members, mentioned in a very recent interview that he’ll wait for all the fallout of the IO changes to settle before updating and continuing work on his project using Zig.
The future looks bright after that though. Both Andrew and Loris seem to think this is the last major breaking change, so I hope we can see a 1.0 not too long after. The biggest uncertainty now is what the consequences of (re-)introducing stack-less coroutines will be.
> Both Andrew and Loris seem to think this is the last major breaking change, so I hope we can see a 1.0 not too long after.
Well I mean the standard library still needs a _lot_ of work IMHO. Process management for instance is at a stage where it's barely usable for simple use cases.
Having seen the posts about the new IO interface, I decided to steer clear from Zig. Looks like that fortuitious instinct was proven valid as this looks more and more like the verbosity from pre C++11 for different reasons but with a similar result.
This pattern (new language evolves to be as complex as the languages it was supposed to replace) seems familiar.
As being one of the post authors you mentioned, I don't think such posts should scare people from trying it out. Zig team is eager to discuss and break things if a better solution is found.
Such approach is not a great fit for those who treat Zig as a future job opportunity, but for personal and small-team projects it's _already_ a neat language with clear goals and great tooling.
The new I/O interface makes printing a simple “Hello, world!” more complicated, but once you get used to it, the design is actually very clean, versatile, and future-proof.
Since 0.15, though, I feel too dumb for Zig’s ArrayList.
Is it future-proof though? Last I saw, it relied on some yet-to-be-determined design for compiling async variants of everything that uses IO, and it was still unclear whether it was possible at all to support dynamic dispatch.
My info could be outdated - I don't follow Zig very closely, but I am curious.
The Reader/Writer changes are perfectly compatible with the upcoming async I/O stuff and you won't need to change any code that just deals with streams.
No promises about potential future changes though :^)
> To convert the Stream.Reader to an std.Io.Reader, we need to call its interface() method. To get a std.io.Writer from an Stream.Writer, we need the address of its &interface field. This doesn't seem particularly consistent.
That made me think of how that change would be received in Go (probably would be discarded). They way they approach changes in extremely deep analysis and taking as much time as it needs to avoid mistakes and reach a consistent solution (or as close as possible).
4 years to decide on something relatively minor, that right now can be done with a bit of a one-liner extra work. But things need to be well thought out. Inconsistencies are pointed out. Design concerns are raised. Actual code usage in the real world are taken into account... too slow for some people, but I think it's just as slow as it needs to be. The final decision is shaping out to be very nice.
Rust is the same. It grinds my goat a little how many useful features are implemented - but only available in nightly rust. Things like generators.
But when rust ships features to stable, they’re usually pretty well thought through. I’m impatient. But the rust language & compiler teams probably have the right idea.
I beg to differ. Rust async implementation is contentious and criticized often. Sometimes you just miss the mark despite pondering about it for a while. Same with Go.
Yeah async rust is definitely the exception. That and Pin, which in my opinion totally missed the mark. The feature rust needs is the ability to have self reference in a struct. Pin is a hacky, inadequate half solution.
Can we all please stop complaining about async Rust and just acknowledge that the problem they were solving was both really hard and urgent for the success of the language (particularly given priorities among the most well-resourced tech companies in the late 2010s)? All things considered, I think they did a good job. I certainly wouldn't have done any better. And the feature was well thought through, with years of work before it shipped.
The problem is really hard. But I think bringing it up is useful, because it motivates people to think about how they would solve it better. It’s certainly a question I’ve asked myself a bunch of times.
If we all stopped complaining about memory safety in C and C++, we would never have gotten rust in the first place. Rob pike would never have let generics make it into Go if people didn’t spend years pestering him about it.
I think I fail by taking for granted all the work that’s gone into languages like rust. Lots of smart people have poured themselves into these discussions and designs. Thankyou. I don’t say that enough.
But yeah, async rust seems like one of those places where people arguing it out on github didn’t converge at a great design. It’s a really hard problem - really, combining a borrow checker with stack suspension is a CS research problem. I think it’s interesting and important to acknowledge that committees don’t always do great research. Sometimes you need a bunch of iterations of an idea. And a bright cookie or two who can work without justifying their designs.
So no, I don’t think I’ll stop talking about it. Making async rust v1 was an incredible amount of work and I’m very grateful. But I also really want to seed the idea space so some bright sparks can think about what async rust v2 might look like.
This wasn't exactly the case before Go 1.0 -- it changed quite rapidly, although in a less fundamental way (for example, removing semicolons, changing error types, etc.), and they usually provided an option to transform code automatically.
It works now that way because they promised it to be stable after 1.0.
Because of how many parts of Zig change every other month, writing documentation doesn't seem to be a priority with Zig. The same way the Zig tutorial is just "here's a bunch of examples of Zig code" (that doesn't always compile on the latest version of the compiler), you're expected to read the source code for a lot of Zig standard library definitions.
For a lot of simple calls, that works out pretty well, once you know all the tricks to Zig's syntax. A lot of requirements and implications are generally written out in very simple and short functions that are often logically named. Things like Allocators are pretty easy conceptually even if you probably don't want to write one yourself.
It all breaks down when you start dealing with complex concepts. Zig's new I/O system looks a lot like Java's streams and wrappers and readers and writers, all wrapping around each other to make sending encrypted text over a secure channel as simple as output.write("hello").
I think the new I/O system combined with the lack of documentation about how to use it was a mistake. I'm not even sure if expressing a typing system as complicated as this in the Zig standard library is a good idea. The entire language runs on clear, concise, short and readable methods, and the new system doesn't seem idiomatic in that way.
its bad because they are mixing what was supposed to just be execution boundaries into the overall runtime engine without making it explicit how to bridge between one and another.
I’m sorry, but any non-trivial Zig code gives me PTSD flashbacks of C. I don’t understand who Zig is targeting: with pervasive mutability, manual allocation, and a lack of proper sum types, it feels like a step back from languages such as Rust. If it is indeed a different way to write code, one that embraces default memory unsafety, why would I choose it over C, which has decades of work behind it?
I love Zig precisely because it is so similar to C. Honestly, if you don't like C, I can totally understand why you wouldn't like Zig. But I love C, and I love Zig.
Zig has become my go-to for projects where I would previously have reached for C, largely because Zig has such good compatibility with other C projects.
Rust, on the other hand, is a completely different beast. It is very different from C, and it is far more complicated. That makes it harder to justify using, whereas Zig is a very easy choice as an alternative to using C itself.
C is entirely as complicated as Rust, if your goal is to write correct software that doesn't crash all the time. It's only a syntactically simple language. Actually making anything interesting with it is _not_ simple.
Quite right. I have 35 years of C under my belt. I can write it in my sleep.
But even so, I can't for the life of me write C code that's as safe as Rust. There are just too many ways to make subtle little mistakes here and there, incrementing a typed pointer by a sizeof by mistake thinking it's a uintptr_t, losing track of ownership and getting a use-after-free, messing up atomic access, mutex deadlocks oh my...
And that's with ALL warnings enabled in CLANG. It's even worse with the default warnings.
It depends on the project. Most of the projects I write in C are very simple, and getting them to work reliably is really not a problem at all.
If you are writing more complicated or "interesting" programs, then I agree, C doesn't give you a good set of tools. But if all you are writing is small libraries or utility programs, C is just fine. In these cases, Rust feels like pulling out a sniper rifle to shoot a target a meter in front of your face (i.e., overkill).
If you are writing complex, large, or very mission-critical programs, then Rust is great to have as a tool as well. But we don't have to take such a black and white view to think that Rust is always the best tool for the job. Or C or Zig or whatever languages for that matter.
I also write C all the time, and it does not crash. There are certainly memory safety concerns with C, but there are also certainly many programmers that can write C code that does not crash all the time.
I don't think a 100-line function signature is representative, but I will point out that the alternative is at least 100 lines of runtime checks instead. In both cases, what a nightmare.
To me that's more an indictment of Diesel than of Rust. I've been using sea-orm for a project I'm working on, and my (generic) pagination function is a hell of a lot simpler and readable than that one.
Typing code from hell for sure, but how would you write an API with the same guarantees in C? Some kind of method specific struct that composes all other kinds of structs/unions to satisfy these requirements?
This is an extremely generic interface to some meta magic DSL. It's complex but not really that complicated and yeah, it's going to be a bit long. But that's going to happen in every language where you rely on types for early validation.
Yuck. I thought some of the signatures you end up with when building “Modern C++” in the Andrei Alexandrescu style were hairy, but this looks sick. Not in a good way.
Probably does something cool for all that crazy though?
Every requirement on the types is commented on why it's necessary.
This is a generic method in the middle of some database DSL code that does a bunch of SQL operations on a type safe manner. Code like this takes "SELECT ?+* FROM ?+* WHERE ? ORDER BY ?+* LIMIT ? OFFSET ?", specifically the limit and offset part, and returns a type that will always map to the database column. If the query is selecting a count of how many Foo each Baz references, this will map to a paginated Foo to Baz count type.
The alternative is to manually write this stuff out in SQL, then manually cast the right types into the basic primitives, which is what a language like Zig probably does.
You'll find similar (though sometimes less type-safe) complex code in just about any ORM/DSL, whether it's written in Java or PHP.
I don't think you can accomplish this in C without some kind of recursive macro parser generating either structs or maybe function pointers on the fly. It'd be hell to make that stuff not leak or double free memory, though.
Better default integer type casting, ability to choose between releaseSafe/releaseFast
And probably other things.
As for comparison to Rust, you do want very low level memory handling for writing databases as an example. It is extremely difficult to write low level libraries in Rust
I think the argument is that it is also extremely difficult to write low level libraries in Zig, just as it is in C. You will just only notice the difficulty at some later point after writing the code, potentially in production.
Did you write any Zig code yet? In terms of enforced correctness in the language (e.g. no integer promotion, no implicit 'dangerous' casts, null-safety, enforced error handling, etc...) and runtime safety (range-, nullptr-, integer-overflow-checks etc...), Zig is much closer to Rust than it is to C and C++.
It "just" doesn't solve static memory safety and some (admittedly important) temporal memory safety issues (aka "use-after-free"), but it still makes it much harder to accidentially trigger memory corruption as a side effect in most situations that C and C++ let slip through via a mix of compile errors and runtime checks (and you get ASAN/UBSAN automatically enabled in debug builds, a debug allocator which detects memory leaks and use-after-free for heap-allocations (unfortunately not for stack allocations), and proper runtime stack traces - things that many C/C++ toolchains are still missing or don't enable by default).
There is still one notable issue: returning a reference to stack memory from a function - this is something that many unexperienced Zig programmers seem to stumble into, especially since Zig's slice syntax looks so 'innocent' (slices look too similar to arrays, but arrays are values, while slices are references - e.g. 'fat pointers') - and which IMHO needs some sort of solution (either a compile time error via watertight escape analysis, or at least some sort runtime check which panics when trying to access 'stale' data on the stack) - and maybe giving slices their own distinct syntax that doesn't overlap with arrays might also help a bit.
I mean, there's no question that Zig, also in its current state, is vast improvement over C or even C++ - for the "small stuff". It is much more pleasant to use.
But there is still the "big stuff" - the things that have a fundamental, architectural impact. Things like: Will my program be multithreaded? Will I have many systems that interact? Will my program be maximally memory-efficient? Do I have the capacity (or money) to ensure correctness if I say "yes" to any of that?
The most important consideration in any software project is managing architectural complexity. Zig is better, yes, but not a paradigm shift. If you say "yes" to any of the above, you are in the same world of pain (or expenses) as you would be in C or C++. This is the reason that Rust is interesting: It makes things feasible/cheap that were previously very hard/expensive, at a fundamental level.
But it doesn't have to be and it shouldn't. Rust also isn't a paradigm shift, it "just" solved static memory safety (admittedly a great engineering feat) but other languages solved memory safety too decades ago, just with more of it happening at runtime.
But in many other areas Rust copied too many bad ideas from C++ (and many of those "other things" Zig already does much better than Rust - but different people will have vastly different opinions about whether one solution is actually better than another - so discussions about those features usually run in circles).
There shouldn't be a single language that solves all problems - this will just result in stagnation, it's much better to have many languages to pick from - and even if they just differ in personal opinions of the language author of how to do things or entirely subjective 'syntax sugar' features. Competition is good, monocultures are bad.
> The most important consideration in any software project is managing architectural complexity
No language will help you managing "architectural complexity" in any meaningful way except by imposing tons of arbitrary restrictions which then get in the way for smaller projects that don't need much "architecture". We have plenty of "Enterprise-scale languages" already (Java, C#, Rust, C++, ...), what we need is more languages for small teams that don't get in the way of just getting shit done, since the really interesting and innovative stuff doesn't happen in enterprise environments but in small 'basement and bedroom teams' :)
> I think the argument is that it is also extremely difficult to write low level libraries in Zig, just as it is in C.
This has been not my experience at all in the ~6 years I've been writing Zig. I started having very little experience writing C (<1000, lines all written while in university) and since day 1 Zig has been a tremendous improvement over it, even back when it was at version 0.4.0.
I'm informed by having shipped a lot of C++ code in my time, which has taught me a lot about actually delivering stable software. Being better than C is a very low bar here.
For me it was very difficult to make an io library on io_uring that is properly safe.
Also using arena and other special allocators in different sections of the program. While maintaining hard memory limits for different sections of the program.
These are possible to do in rust but it is very difficult for me so I decided to just not do it. Otherwise I have to spend 5x the normal amount of time to make sure the library cannot be misused by the user ever.
This is pretty pointless since I’m the only one who is going to use that code anyway.
Could be skill issue or w/e but I just find zig easier to make progress in
Zig is for people who want to write C, that's really it. It's not a replacement for C++ or Rust or Go or Swift or anything "serious".
As for why you would choose it over C, because C has too many problems for even the C lovers to ignore. Zig fixes a tiny amount of them, just enough to pretend it's not problematic, but not enough to be useful in any non-hobby capacity. Which is fine, very few languages do achieve non-hobby status after all.
Zig is a systems programming language. I think that's probably who it's targeting.
People do systems programming in rust, but that's not really what most of the community is doing. And it's DEFINITELY not what the standard library is designed for.
Web servers, games, and applications, that sort of thing.
Some people definitely do systems programming in, but it's a minority. The std library is not set up for it at all, you need something like rustix, but even that results in very unidiomatic ("unsafe") rust code.
In Zig it's all in the std library by default. Because it's a systems programming language, first and foremost.
Actually I was also under OPs impression... can you tell me few specific problems with using rust for systems programming? BTW, I have only ever done something that resembles systems programming in C.
Because Rust's standard library doesn't provide memory mapping you will need to use platform specific APIs.
In Zig it's exactly the same except that they decided to provide the POSIX platform specific APIs, which if you're using a POSIX system is I guess useful and otherwise it's dead weight.
It's a choice. I don't think it's a good choice but it's a choice.
Your question might hint at a questionable presumption. So let me answer your question with a question - Does one have to memory map in Rust? Perhaps there are alternatives available in Rust, that you are not considering.
I think you are moving the goal posts. You use the `memmap2` crate, or the `libc` crate if you want to be reckless about it. The question was how the standard library gets in your way, not whether it includes everything you need.
And I don't think that including every feature of every possible OS is a sensible position to have for a standard library. Or would you argue that it should also include things like `CreateWindowExW()`?
If all you use is the Rust standard library, you can be reasonably sure that your program works on all platforms, and memory mapping is something that is highly platform specific, even among POSIX-likes. I would not like to attempt designing a singular cross-platform API for it that has to be maintained in perpetuity.
(There are a few OS-specific APIs in the Rust standard library, mostly because they are required anyway for things like I/O and process management. But the limit has to be set somewhere.)
I finally got it working. I had to flush both the encrypted writer and then the stream writer. There was also some issues with reading. Streaming works, but it'll always return 0 on the first read because Writer.Fixed doesn't implement sendFile, and thus after the first call, it internally switches from streaming mode to reading mode (1) and then things magically work.
Currently trying to get compression re-enabled in my websocket library.
(1) https://github.com/ziglang/zig/blob/47a2f2ddae9cc47ff6df7a71...