><i>I’m not on Twitter anymore - my goal is to instead channel that micro-blogging energy into regular blogging energy on my personal website as well as posting Zig project news here on ziglang.org.</i><p>Cool, I like this!<p>I realized last year that I was investing too much time into sharing things on Twitter that I'd subsequently forget about or be unable to find.<p>Instead, I created a separate section on my personal blog for "notes" where the idea is to house content that I'd otherwise post to Twitter. It's been working well, and I like owning my own content rather than contributing it to another platform.<p>I'm especially glad for this change after seeing what's happened in the past few months with Twitter and Reddit. It's been unfortunate to see those platforms become so much more possessive of the content that their users generated. If you publish to your own platform, you're safe from that. At least until LLMs bury your platform in noise.
An engineer being overly optimistic with a time estimate? Say it ain't so!<p>"A delayed game is eventually good, but a rushed game is forever bad." - Shigeru Miyamoto<p>The same goes for features. I'd rather Zig have a delayed/good async next year and forever after, instead of a rushed/bad async right this moment and forever after.
I really appreciate the honesty. It is not the end of the world to delay a highly anticipated feature, especially when the delay was a consequence of prioritizing the long-term stability of the codebase over the promised delivery date.
I have yet to try Zig, but I approve of the idea of taking extra time and reducing scope to make sure that what you do ship is solid, especially in something like a programming language that may end up being a foundational piece of many other projects.
I hope Andrew does a Stream of preparing the 0.11.0 migration documentation like he did for 0.10.0. It gives a good insight on the new features in a conversational manner.
Is there a reason async/await is being implemented specifically, rather than some more generally-useful primitive (like delimited continuations, algebraic effect handling, functor/applicative/monad, etc.[0])?<p>When it comes to e.g. memory management, Zig tries to be unopinionated and allow different implementations to be implemented as desired; so it seems odd to bake-in something like async/await (even if the execution strategy of those computations is up to the user).<p>I've seen this happen in many high-level languages (JS, Python, PHP, etc.), which I mostly attribute to (a) ignorance of those generalisations, and (b) a band-wagon effect. The unfortunate result in those languages is a bloated mess of try/catch, async/await, for/yield, apply/return, etc. and all of their O(n!) possible interactions; which could have instead been implemented as libraries on top of a single primitive (e.g. shift/reset, or whatever)<p>[0]: AFAIK these are all equivalently expressive, and given one it's easy enough to write the others as libraries.<p>PS: I recall asking this question when PHP added generators; I can't seem to find a bug report or mailing list post though...